- PwnEscape(CVE-2026-99999)存在于 Linux 内核中,允许从 KVM 客户机逃逸到宿主机。评级:CVSS 3.1 为 9.8,即严重。
- 内核已有补丁。各发行版跟进的速度不一,Canonical 在消息发布时还没有提供更新。
- 关键在于正在运行的内核,而不是已安装的内核:不重启(或不打 Live-Patch),漏洞依然存在。
虚拟化中最坚固的一道墙,是客户机与宿主机之间的那堵。PwnEscape 展示了当一个带有错误校验和数据的数据包穿过这堵墙时会发生什么。
目前已知的情况
安全研究员 Paulos Yibelo 于 2026 年 10 月 3 日公开表示,他开发出了一个可从 KVM 虚拟机中逃逸的 0-Day 漏洞利用程序。该漏洞是在 Vercel 的一项“Sandbox”挑战中发现的,该挑战旨在检验 KVM 的隔离边界。现在它已有编号 CVE-2026-99999。其他专家已能独立复现这个问题。
错误出在内核的网络部分:如果一个带有错误校验和元数据的数据包进入 IPv4 协议栈,函数 skb_checksum_help 在计算时可能会损坏网络头。在逃逸过程中,这一缺陷会变成对宿主机内存的访问,最终获得宿主机上的 Root 权限。
客户机中的恶意程序可以在宿主机上获得 Root 权限。而这恰恰是 KVM 要防止的。
我们不知道的是:报告中没有提到在野外发生的攻击,但预计很快就会出现。现在正是你该打补丁的阶段,而不是事后。
影响谁
受影响的是运行 KVM 的宿主机内核。在虚拟机里工作的人,通常并不自己管理宿主机。下表对最常见的角色做了归类:
| 角色 | 是否受影响? | 你要做什么 |
|---|---|---|
| 自有 KVM 宿主机(Proxmox、libvirt、QEMU) | 直接受影响 | 安装内核更新,重启宿主机 |
| 自带嵌套虚拟机的 Rootserver | 你的服务器是这些客户机的宿主机 | 按虚拟化主机对待 |
| 没有自有虚拟机的 Rootserver | 宿主机在服务商那里 | 保持自己的内核为最新,并向服务商询问 |
| 没有 KVM 的 Docker 主机 | 所述攻击路径要经过 KVM | 仍然要安装更新 |
你的服务器是否使用了嵌套虚拟化,可以在下面的第 1 步中看到。在 Rootserver 上运行 Docker 并不需要 KVM,因此 Rootserver 上的 Docker 方案并不是这种攻击的常见场景。
分步操作:检查并加固宿主机
- 确认 KVM 是否在运行。如果
/dev/kvm存在且模块已加载,这台机器就是虚拟化主机。ls -l /dev/kvm lsmod | grep kvm virsh list --all # libvirt qm list # Proxmox - 记下正在运行的内核。稍后你要拿这个版本号与已打补丁的版本作比较。
uname -r - 检查你的内核软件包是否提到了该漏洞。Debian 和 Ubuntu 会在 changelog 中显示该 CVE,RHEL 系发行版同样如此。如果没有出现,说明更新还没有到。
apt update apt changelog linux-image-amd64 | grep -i CVE-2026-99999 # RHEL, Alma, Rocky: rpm -q --changelog kernel | grep -i CVE-2026-99999 - 安装更新。对于集群,先通过 Live-Migration 把客户机迁移到另一个节点,再更新宿主机。
apt full-upgrade # Proxmox: 事先迁移客户机 qm migrate 101 pve2 --online - 重启并检查。只有重启才会加载已打补丁的内核。之后
uname -r必须显示比第 2 步更新的版本。reboot uname -r
如何确认已经生效
- 版本对比:重启后
uname -r的输出与第 2 步不同,并且与 changelog 中提到该 CVE 的软件包一致。 - 没有残留的旧内核:用
dpkg --list | grep linux-image可以看到安装了哪些内核。引导程序必须启动最新的那个。 - 客户机重新运行:
virsh list或qm list显示所有虚拟机都处于 running 状态。
unattended-upgrades 在固定时间窗口自动重启,或者每周固定一个补丁日,手动并盯着重启。两种都行,重要的是确实有一个固定节奏。如果补丁还没有到呢?
如果你的发行版还没有提供更新,目前没有经证实、我们能在这里推荐的临时解决办法。不过这段时间仍然可以合理地过渡:
- 宿主机上只运行可信的客户机,把外部的工作负载放到其他节点上
- 严格限制对宿主机和客户机的访问,例如使用密钥代替密码,并配合 fail2ban
- 每天查看软件源,看内核是否已经发布
- 指望更新客户机:据报告,错误出在宿主机内核
- 仅仅因为某个发行版这样评级,就把这个漏洞当作“中危”忽略掉
- 安装了补丁,却不重启宿主机
从以往的案例中可以带走什么
宿主机是个值得攻击的目标,因为它下面的一切都依附于它。我们在管理层面已经见过这种情况:在 Proxmox VE 7 上,攻击者无需密码就以 root 身份登录;而在 Virtualizor 上,损害是通过一个被偷换的更新造成的。PwnEscape 补上了第三个层面,即内核本身。同时盯住这三者——面板、访问权限和内核——的人,在下一次出现类似消息时就不必那么临时应对。
内核更新接连不断,管理员们对此的抱怨不无道理,上面的做法同样适用。本来就有固定补丁日的人,面对这样的消息可以从容应对:一次计划外的重启,而不是恐慌。通过 NetworkManager 的权限提升一事也是类似的过程:检查、更新、验证。
细节的来源有 CVE-2026-99999 的描述、OpenWall 上的帖子,以及 Yibelo 自己的博客文章“PwnEscape: Guest-to-Host KVM Escape”。在转述任何关于确切影响范围的内容之前,请先到那里核对,因为关于这个漏洞的报告仍在不断更新。
你自己运营一台 Rootserver,却不确定是否把它当作虚拟化主机在用?第 1 步中的命令十秒钟就能弄清楚。关于我们服务器的概览,请见我们的 Rootserver。
