ssh-keysign-pwn（CVE-2026-46333）解读：Linux 本地信息泄露、SSH 主机密钥与 /etc/shadow 风险

Sun, 17 May 2026 09:29:03 +0800

ssh-keysign-pwn 是围绕 Linux kernel __ptrace_may_access() 逻辑问题公开的一组利用路径，CVE 编号为 CVE-2026-46333。它不是远程无认证漏洞，也不是直接拿 root shell 的漏洞，但风险仍然很高：本地低权限用户可能读取本不该访问的 root 敏感文件，例如 SSH 主机私钥或 /etc/shadow。

对运维来说，重点不是复现 PoC，而是尽快判断哪些机器受影响、升级内核、重启生效，并在必要时轮换 SSH host keys 和重置密码。

先说结论

这次漏洞的处置优先级很高，原因有四点：

触发条件是本地低权限用户，不需要 root。
已有公开 PoC，利用门槛明显降低。
影响目标不是普通文件，而可能是 SSH 主机私钥和 /etc/shadow。
修复需要内核补丁并重启，不能只升级包后不重启。

如果你的服务器有多用户、本地 shell、共享主机、CI runner、容器宿主机、学生机房、跳板机或任何“不完全可信本地用户”，应该优先处理。

漏洞是什么

Qualys 在 2026 年 5 月 15 日通过 oss-security 公开说明：他们此前向 security@kernel.org 报告了 Linux kernel __ptrace_may_access() 的逻辑问题，上游修复已经由 Linus 合入。随后社区出现了公开利用代码，因此 Qualys 将信息发到 oss-security。

Linux kernel CVE 团队随后为这个问题分配了 CVE-2026-46333。NVD 页面显示该 CVE 来源为 kernel.org，问题描述对应内核提交 ptrace: slightly saner 'get_dumpable()' logic。

简单说，这个漏洞出现在进程退出路径上。某些特权进程正在退出时，内核里与 ptrace 访问检查相关的逻辑可能因为目标任务已经没有 mm 而绕过本应依赖的 dumpable 检查。攻击者可以在很窄的竞态窗口中，拿到正在退出的特权进程仍然打开着的文件描述符。

这也是为什么它被叫作 ssh-keysign-pwn：公开利用路径之一会围绕 ssh-keysign 读取 SSH host private keys。

为什么能读到 SSH 主机私钥和 /etc/shadow

这个问题本质上是本地信息泄露。它利用的是特权程序在退出过程中“内存描述符已经脱离，但文件描述符还没关闭”的时间窗口。

AlmaLinux 的公告对风险讲得比较清楚：如果特权程序在降权前打开了敏感文件，而攻击者在退出窗口中成功拿到对应文件描述符，就可能读取这些敏感文件。

公开讨论中常见的两个目标是：

ssh-keysign：可能涉及 /etc/ssh/ssh_host_*_key 这类 SSH 主机私钥。
chage：可能涉及 /etc/shadow。

SSH 主机私钥泄露后，攻击者可能伪装成该主机，影响 SSH 主机身份信任。/etc/shadow 泄露后，攻击者可以离线破解密码哈希，进一步扩大影响。

这也是为什么它虽然不是“直接 root shell”，但仍然应按高优先级处理。

影响范围怎么判断

从上游角度看，这是 Linux kernel 的漏洞。NVD 记录显示该问题在 2026 年 5 月 15 日进入 NVD 数据集，NVD 当时还没有给出 CVSS 评分。

发行版层面的状态要以各自公告为准：

AlmaLinux 8、9、10 都发布了处理说明，并在 2026 年 5 月 16 日更新称 patched kernels 已进入生产仓库。
Debian security tracker 已列出 bullseye、bookworm、trixie、sid 等分支的 vulnerable/fixed 状态和固定版本。
其他发行版需要分别查看 Ubuntu、Red Hat、SUSE、Arch、Alpine 等官方安全页面或更新源。

不要只按内核大版本判断是否安全。发行版会 backport 修复，同一个上游版本号在不同发行版中可能代表不同补丁状态。

应该优先处理哪些机器

建议按风险排序处理：

多用户服务器和共享主机。
有普通 shell 账号的跳板机、教学机、开发机。
CI runner、构建机、托管平台宿主机。
容器宿主机和虚拟化宿主机，尤其是不完全可信 workload 共存的环境。
公开服务机器，虽然漏洞需要本地访问，但一旦 Web/RCE/弱口令带来低权限落点，风险会叠加。

纯单用户桌面环境风险相对低一些，但仍建议随系统更新修复。原因很简单：本地低权限代码执行在桌面上并不少见，浏览器、开发工具、脚本和第三方软件都可能成为落点。

修复建议

首选方案是安装发行版提供的修复内核并重启。

不同发行版命令不同，原则相同：

更新软件源元数据。
安装包含 CVE-2026-46333 修复的 kernel 包。
重启进入新内核。
用 uname -r 和发行版安全公告核对当前运行内核是否已修复。

AlmaLinux 公告中提到，生产仓库已推出修复内核，用户可以执行常规 dnf upgrade 并重启。Debian tracker 也列出了多个分支的 fixed versions。

需要注意：只安装新 kernel 包但不重启，旧内核仍在运行，漏洞仍然存在。

临时缓解：收紧 ptrace_scope

如果暂时不能重启，可以先收紧 Yama 的 ptrace_scope。

Qualys 在 oss-security 后续回复中确认，将 /proc/sys/kernel/yama/ptrace_scope 设置为 2（admin-only attach）或 3（no attach）可以阻止他们已知的公开利用路径。但他们也说明，理论上可能存在其他利用方式，所以这只是缓解，不是修复。

临时设置可以用：

`1`	`sudo sysctl -w kernel.yama.ptrace_scope=3`

持久化可以写入 sysctl 配置：

`1`	`echo 'kernel.yama.ptrace_scope = 3' \| sudo tee /etc/sysctl.d/99-ssh-keysign-pwn.conf`

ptrace_scope=3 会禁用 ptrace attach，可能影响 gdb、strace -p 等调试场景。如果生产环境需要调试，可以评估使用 2。无论选哪一个，都应尽快安排内核升级和重启。

是否需要轮换 SSH 主机密钥

如果机器在漏洞公开前后存在以下情况，建议保守处理：

有不可信本地用户。
有共享主机或容器/CI 多租户环境。
有 Web 漏洞、弱口令、供应链脚本等可能给攻击者本地落点。
日志中出现可疑本地进程、异常调试行为或公开 PoC 文件。
机器在修复前暴露了较长时间。

保守处置包括：

修复并重启后轮换 SSH host keys。
更新已知主机指纹管理系统。
通知依赖该主机指纹的自动化系统。
检查 SSH 连接告警，避免误把合法指纹变化当成中间人攻击或反过来忽略真实风险。

如果怀疑 /etc/shadow 已泄露，还应评估密码重置、禁止弱密码、检查是否存在可离线破解的旧哈希。

需要监控什么

这类漏洞利用窗口很短，传统日志未必能完整记录。但仍可以关注：

普通用户目录下是否出现 ssh-keysign-pwn、chage_pwn 或类似 PoC 文件。
可疑编译行为，例如短时间内编译陌生 C 程序。
异常访问 /etc/ssh/ssh_host_*_key、/etc/shadow 的迹象。
异常 pidfd_getfd、ptrace、调试器相关行为。
SSH 主机指纹被外部系统报告异常。

这些信号不能证明一定被利用，也不能证明没有被利用。真正的优先事项仍然是补丁、重启、凭据轮换和风险隔离。

常见误区

第一个误区：它不是 OpenSSH 远程漏洞。名字里有 ssh-keysign，但根因在 Linux kernel 的 ptrace 访问检查逻辑，不是 sshd 远程认证流程。

第二个误区：没有本地用户就完全没风险。漏洞确实需要本地执行条件，但很多真实攻击链会先通过 Web 服务、CI、脚本、弱口令或容器逃逸前置步骤获得低权限本地落点。

第三个误区：设置 ptrace_scope 就够了。它是临时缓解，不是根本修复。内核更新和重启仍然需要做。

第四个误区：只要没被拿 root 就没事。SSH 主机私钥和 /etc/shadow 的泄露本身就足以导致后续横向移动、主机伪装和离线破解风险。

处置清单

建议按这个顺序执行：

盘点受影响 Linux 主机，特别是多用户和共享环境。
查看发行版官方安全公告，确认 fixed kernel 版本。
安装修复内核并重启。
暂时不能重启的机器，先设置 kernel.yama.ptrace_scope=2 或 3。
修复后核对正在运行的内核版本。
对高风险机器轮换 SSH host keys。
如果怀疑 /etc/shadow 泄露，评估密码重置和账号审计。
检查是否存在公开 PoC、异常编译和可疑本地调试行为。

总结

ssh-keysign-pwn（CVE-2026-46333）是一个本地信息泄露漏洞，根因在 Linux kernel __ptrace_may_access() 相关逻辑。它不需要远程直接打进来，也不直接给 root shell，但可以让低权限本地用户读取高价值敏感文件，这使它在多用户、共享主机、CI 和容器宿主环境中非常值得警惕。

最可靠的修复是升级到发行版提供的修复内核并重启。ptrace_scope=2/3 可以作为临时缓解，但不能替代补丁。已经暴露在风险窗口中的关键主机，还应考虑 SSH 主机密钥轮换和密码风险评估。

参考链接：

OpenSSH on KnightLi的博客