EulerOS 上 CVE-2026-44605 的处置：一个 NDB 数据库文件引发的本地提权，为什么只升级 rpm 包还不够

10 月底 EulerOS 发布了一条安全公告，CVE-2026-44605，CVSS 5.5，中危，影响 RPM 包管理器：本地用户在解析特制的 NDB 数据库文件时，可以触发堆缓冲区溢出，导致系统不可用。乍一看 CVSS 只有 5.5、且是“本地”漏洞，很多团队会排到低优先级。但如果你的云服务器上跑着多租户环境或者允许低权限用户登录的跳板机/CI 节点，这个漏洞的实际风险远高于评分——一个普通账号就能让整台机器不可用，放在共享构建机上就是一人触发、全员阻塞。

一、 先理解漏洞的触发条件

CVE-2026-44605 的溢出点在 RPM 处理 NDB 数据库文件时的内存分配计算逻辑上。攻击者需要能够让 RPM 进程处理一个精心构造的 NDB 文件。典型的利用路径是：低权限用户在本地放置一个恶意 NDB 文件，然后诱导某个有权限的进程（或通过定时任务、包查询接口）调用 RPM 去解析它。虽然需要一定的交互或触发条件，但在 CI/CD 节点上，构建脚本频繁调用 rpm -qa、rpm -qi 等查询命令，攻击面比想象中更大。

二、 只升级 rpm 包为什么不够

EulerOS 的安全公告给出的修复方式是更新 rpm、rpm-libs、python3-rpm、rpm-build 等包到修复版本。但这里有一个容易漏掉的点：已运行的进程不会自动使用新版本的库。如果有常驻服务（比如某些监控 agent 或包管理守护进程）在升级前已经加载了旧版 librpm，升级 rpm 包本身不会替换进程内存中的旧代码。必须重启所有加载了 librpm 的服务，或者最稳妥地重启节点。

此外，如果节点上存在自编译或第三方来源的 rpm 二进制（比如某些容器镜像里打包了独立版本的 rpm 工具），系统包管理器升级不会覆盖这些路径下的副本。排查时需要确认 which -a rpm 的输出是否只有 /usr/bin/rpm 一个来源。

三、 处置步骤与验证

1. 确认当前版本并升级。

bash
rpm -q rpm rpm-libs python3-rpm
# 对照安全公告确认是否低于修复版本
yum update rpm rpm-libs python3-rpm rpm-build
2. 识别并重启相关进程。

bash
# 查找加载了 librpm 的进程
lsof | grep librpm
# 或使用 fuser
fuser -v /usr/lib64/librpm.so.* 2>/dev/null
对输出中的进程逐一评估，能重启的重启，不能重启的（如关键业务进程）记录并安排窗口期。

3. 收紧 NDB 文件的写入与读取权限。 这个漏洞需要攻击者能够放置恶意 NDB 文件。检查 /var/lib/rpm 及相关目录的权限，确保非 root 用户不可写入。对于允许普通用户登录的节点，限制其对临时目录下 .rpm / .ndb 文件的创建和执行触发能力。

4. 验证修复。 升级并重启后，确认 rpm --version 对应的包版本已更新，且 lsof 中不再有进程持有旧版 librpm 的 inode（对比升级前后的文件 inode 号）。对于无法立即重启的节点，至少确保该节点不承载多租户或低权限用户登录，降低被利用的窗口。

四、 总结

CVE-2026-44605 的 CVSS 评分不高，但“本地”不等于“安全”。在多租户、CI 构建节点、跳板机这类场景下，一个低权限账号能触发的拒绝服务，实际影响可能远超评分暗示的范围。处置链路：升级 rpm 相关包 → 重启加载 librpm 的进程或节点 → 收紧 NDB 文件权限 → 验证旧库 inode 不再被持有。只执行第一步而忽略进程重启，等于补丁打了但没生效。