CVSS 9.3 虚拟机逃逸漏洞 PwnEscape 披露三天后：AWS 发公告、小厂连夜重启，OVH 和 netcup 集体沉默

三天前的那个 9.3 分漏洞，现在怎么样了

10 月 15 日，Linux 内核正式披露了代号 PwnEscape 的虚拟机逃逸漏洞，编号 CVE-2026-99999，CVSS 3.1 评分 9.3，Critical 级。到今天为止，三天时间，整个行业的反应速度差异被拉得非常开：有的厂商发正式公告、放修复包；有的小厂连夜开维护窗口全量重启；而一些用户量不小的欧洲老牌 VPS 商，状态页上至今一个字都没提。

漏洞本身一句话说清

PwnEscape 不在 KVM、QEMU 或任何一家云厂商的配置里，而是藏在宿主机 Linux 内核的 IPv4 网络栈中。客户机发出的数据包可以携带未经验证的 checksum 元数据，skb_checksum_help() 会在内核已经解析并信任 IPv4 头之后改写它——一个 20 字节的头被误判成 60 字节，宿主机内核随即把数据包之外约 32 字节的内存当成 IP 选项发回给客户机。

pwn.ai 的研究员 Paulos Yibelo 在 Vercel 百万美元 Sandbox 挑战赛中演示了三种后果：持续泄露宿主机内核内存、两个特制数据包打崩整台宿主机、以及在实验室环境下链出宿主机 root 权限执行。前一种已在 Vercel 生产环境确认，后两种只在研究员自建环境中复现。目前没有在野利用迹象，Yibelo 本人预计针对弱配置环境的可用利用代码"数周内"就会出现。

修复没有捷径：必须升级宿主机内核并重启

上游补丁 6785011f8b16 已进入 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.57、7.2.11 各稳定分支。几个关键点容易踩坑：

• 只打客户机没有用，有漏洞的代码跑在宿主机上；
• 装了补丁不等于生效，必须重启进新内核，livepatch 也需厂商明确确认覆盖此 CVE；
• 别只看 uname 版本号，很多发行版回移补丁但不改版本串，要对照发行版的安全公告；
• 没有临时缓解措施，禁用嵌套虚拟化、收紧权限只能缩小爆炸半径。

大厂的公开反应

AWS 动作最快，发布了安全公告 2026-137-AWS：托管 EC2（Nitro 硬件卸载网络 I/O，不走软件路径）、Lambda 和 Fargate 不受影响；但自管 KVM/Firecracker 主机（内核 4.4 至 6.18）受影响，Amazon Linux 2 和 AL2023 的修复内核包已可下载，要求打补丁并重启。Vercel 作为发现方发布了挑战赛总结报告，确认内存泄露在其生产沙箱上复现，但没有任何报告显示客户文件或密钥被读取。AlmaLinux 10 月 16 日宣布 8/9/10 全系受影响，修复内核先进 testing 仓库。Debian 在安全公告中定级 Critical，Red Hat 还特别指出本地攻击者同样可以触发，不只是虚拟机里的租户。

小厂的两副面孔：连夜重启 vs 完全沉默

大厂的反应在预料之中，真正有意思的是小厂。这次我们至少看到了两种截然不同的处理方式：

MVPS.net 选择了全量紧急重启。它在 10 月 16 日开出 5:00–10:00（GMT+3）的维护窗口，把所有 VPS 所在宿主机分批打补丁重启，并在公告里明确告诉用户"你自己重启 VPS 是没有用的，补丁由我们打在宿主机上"。上午 7:40 更新：全部节点修复完成。整场维护不超过六小时，这种小体量反而成了优势——决策链短，一声令下全部重启。

Teramont Host 选择了发长文安抚客户。10 月 17 日它发布博客，确认 Debian 12 和 Debian 13 的全部节点已更新到含 CVE-2026-99999 修复的内核，同时把"已修复"和"零风险保证"区分得很清楚，还给了客户一份自查清单：怎么问厂商、怎么确认宿主机内核真的在跑修复版本、出现异常重启时该保留哪些日志。

而另一边，OVHcloud 和 netcup 截至 10 月 19 日都没有发布针对此漏洞的公开公告。OVHcloud 状态页上 Hosted Private Cloud 和 Web Cloud 虽然挂着 "Event(s) in progress"，但均未与 CVE-2026-99999 关联，难以判断是否属于静默修复的一部分；netcup 的新闻页面甚至直接 404。这不代表它们没修——大中型托管商按惯例静默滚动打补丁是常态——但对租户来说，"没消息"和"修好了"之间隔着一整条信息鸿沟。

给站长和租户的实际行动清单

无论你的机器在谁家，这几步现在就该做：

• 托管 VPS / 云主机用户：提工单直接问三件事——宿主机内核是否已含 CVE-2026-99999 修复、是否已重启激活、覆盖了哪些节点。别问"你们安全吗"，要具体版本和节点覆盖确认；
• 自建 KVM / Proxmox VE 用户：自己就是"云厂商"，跑 uname -r 对照发行版公告确认补丁状态，排期重启，虚拟化主机优先于其他机器；
• 多租户场景：怀疑自己环境出过异常的，保留宿主机内核日志（dmesg/journalctl 中的 BUG、OOPS、内存损坏记录）再排查重建，客户机侧的补丁和防火墙不能替代宿主机修复；
• 顺手核对 Januscape（CVE-2026-53359）：7 月披露的另一个 KVM 逃逸漏洞，与本漏洞技术细节不同，两颗补丁都要确认在位。

写在最后

PwnEscape 之所以值得写，不只是因为 9.3 的评分，而是它又一次证明了云隔离的根子扎在内核上：hypervisor 只是表象，内核才是地基。这次披露三天内，行业给出了一份难得完整的对照样本——有公开表态的大厂、连夜重启的小厂、也有依然沉默的主流托管商。对普通用户来说，漏洞补没补不该靠猜，问一句具体的，比自己折腾客户机有用得多。

参考来源：kernel.org CVE-2026-99999 记录、AWS 安全公告 2026-137-AWS、Vercel Sandbox 挑战赛报告、AlmaLinux 官方博客、MVPS.net 维护公告、Teramont Host 官方博客、The Hacker News。