虚拟机也关不住？CVE-2026-99999：一个“稍后再算”的校验和，如何撬开宿主机

“把不可信代码放进虚拟机，总比直接放在宿主机上安全。”这句话仍然成立。但它后面应该再加半句：虚拟机能碰到的宿主机接口，也必须经得起不可信输入。

2026 年 10 月公开的 CVE-2026-99999，研究者称为 PwnEscape。它最反直觉的地方，是漏洞落在 Linux 网络栈：一个原本用于提速、准备“稍后再补”的校验和，可能把已经检查过的 IPv4 包头改掉，进一步跨越客户机与宿主机的边界。

先把证据边界说清：Vercel 确认生产沙箱中验证过宿主机内存泄漏；宿主机崩溃和完整代码执行，来自研究者自有的 KVM、Firecracker 实验环境。本文核查公开资料与补丁，没有在生产系统运行利用程序。

图 1：本文原创示意图。门锁的比方指隔离边界；真正出问题的组件是 Linux 网络栈。

一、先看结论：严重，但别把它读成“互联网任意发包就拿 root”

截至 2026 年 10 月 19 日，CVE 官方记录已发布，分配机构为 Linux，标题是 ipv4: validate checksum_start before completing checksum。记录首次公开于 10 月 15 日，10 月 19 日又有更新。

记录中的 CVSS 3.1 分数为 9.3，向量如下：

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

其中 AV:L 表示本地攻击向量，S:C 表示影响可能跨越原本的安全权限范围。这里的“本地”需要结合云沙箱理解：攻击者可能已经合法拥有一个能运行自己代码的客户机，接下来试图越过隔离边界，影响宿主机。

PR:N 也不能单独拿出来解释成“每一种受限容器都能直接利用”。能否把所需数据与校验和元数据送进对应路径，还取决于虚拟网络接口、权限、内核配置和运行环境。

图 2：真实网页截图，来源 CVE 官方记录，截取于 2026-10-19；仅裁切与压缩。

因此，需要优先盘点的是运行不可信工作负载的 Linux 宿主机、虚拟化平台、CI 执行环境和智能体代码沙箱。普通网站访问者并不会因为打开一个页面，就自动具备研究中那条客户机到宿主机的路径。

同样，9.3 是严重性指标，不是“你这台机器已经被入侵”的检测结果。NVD 在本文核查时仍把条目标为 Received，其显示的评分来自记录提供方，不能包装成 NVD 已完成全部独立分析。

二、百万美元挑战里，到底证明了什么

事情的背景是 Vercel 在 8 月 18 日公布的百万美元 Sandbox 挑战。这里的百万美元是挑战总奖金池，不是给这一个漏洞开出的支票。

研究者 Paulos Yibelo 与 pwn.ai 团队把注意力放在一个问题上：不攻击虚拟机监控器本体，客户机还能通过哪些接口影响宿主机？他们沿虚拟网络进入宿主机的路径，找到这个内核缺陷。

图 3：真实网页截图，来源 PwnEscape 研究原文，截取于 2026-10-19。

把厂商报告和研究者报告放在一起，可以得到下面这张证据表：

研究者提到，最初的受控泄漏每次可观察到 32 字节，后来在自有环境中推进到选定的 64 字节宿主机内核写入，并在四次冷启动中完成受控执行链。这里每上一级，都需要额外的研究和验证；“泄漏 32 字节”不会自己变成“立即拿到所有服务器”。

图 4：真实网页截图，来源 Vercel 挑战复盘，截取于 2026-10-19。生产与实验环境的完整限定请结合上表及原文阅读。

Vercel 的文章发表于 10 月 14 日，所以其中仍有“CVE 待公布、修复协调中”的当时表述；CVE 官方记录在次日发布。两份资料时间不同，不能把较早文章中的状态当作今天的最新状态。

三、先用学校收快递的故事，把漏洞讲明白

想象学校收发室有三个岗位。

安检员先看包裹的箱单，确认这张箱单有多长、东西该送到哪里。装箱工负责最后补写一个校验数字，方便后面的分拣机检查包裹有没有传坏。分拣机再根据箱单，把包裹送出去。

为了提高速度，安检时可以先不算那个校验数字，而是贴一张便条：“稍后从这里开始计算，把结果写到那里。”

麻烦在于，便条的位置来自不可信的一方。如果它把“写到那里”指向箱单本身，装箱工补数字时，就可能改了安检员已经看过的箱单。分拣机接着相信改后的内容，却不知道原先的检查针对的是另一份内容。

图 5：本文原创示意图。KVM 是被跨越的隔离边界之一；缺陷所在的源码属于 Linux 网络栈。

对应到内核，包裹是数据包，箱单是 IPv4 包头，便条是校验和元数据，装箱工则是执行校验和补全的设备或软件函数。

这个比方最想说明的是顺序：检查通过以后，后续操作仍然能修改被检查的内容。安全检查的位置正确，还不够；检查得到的结论必须一直有效到使用那一刻。

四、专业一点：CHECKSUM_PARTIAL 为什么会变成写入权限

Linux 可以让数据包先处于 CHECKSUM_PARTIAL 状态，把一部分校验和工作留到后面完成。这是正常的性能优化，常用于发送路径。

与之相关的两个字段是：

csum_start   从哪里开始计算校验和
csum_offset  从计算起点到结果写入位置的偏移

结果写入位置 = csum_start + csum_offset

注意，这些字段不只是“说明文字”。它们决定未来一次实际的内存写入会落在哪里。

图 6：真实网页截图，来源 Linux Checksum Offloads 文档，截取于 2026-10-19。

元数据还面临一个坐标问题。包刚进来时，前面可能带着以太网或其他链路层头部；进入后续网络处理时，这些头部可能已经被跳过。相对“整个包最前面”的位置检查，并不自动等于相对“当前 IPv4 包头”的位置检查。

还是用收快递的比方：你说“从第三页开始盖章”，如果中途拆掉了两页包装说明书，后面的人再数“第三页”，含义就变了。内存块不一定移动，但数据的当前视图和边界发生了变化。

研究者报告中，早期入口检查与后续网络头边界之间的这种错位，使恶意元数据能够走到某些后续消费者。历史代码在 IPv4 分片等路径调用 skb_checksum_help() 时，缺少针对当前 IPv4 包头的必要约束，可能让补写结果覆盖包头。

图 7：本文原创示意图。对应的是处理顺序和信任关系，不是完整网络包格式。

这里还有一个容易读错的词：校验和不是密码学签名。它主要帮助检测传输错误，不能证明数据由谁发出，也不能把不可信位置说明变成可信授权。

五、从 20 字节变成 60 字节，为什么危险

IPv4 包头里有一个字段叫 IHL，用来表示包头长度，单位是 4 字节。

研究者展示的受控情况中，首字节可以从 0x45 变成 0x4f。高半部分仍表示 IPv4；低半部分的长度解释，却从 5 个单位变成 15 个单位：

之前：IHL = 5，包头长度 = 20 字节
之后：IHL = 15，包头长度 = 60 字节

图 8：本文原创示意图，依据研究者公开的受控案例绘制。

早先的处理只检查了一个 20 字节包头，后续代码却按被修改后的 60 字节继续解释。在特定的数据包布局、分片和内存条件下，检查与使用脱节，最终形成越界读取等内存安全问题。

它有“检查时”和“使用时”不一致的味道，但不一定需要两个线程拼命抢时间。合法处理步骤可以按固定顺序走完，中间那次延迟写入就足以改变前面的安全假设。

泄漏是第一层结果，进一步写入和执行还需要额外条件。本文讲机制和防守验收，不提供构造恶意数据包、读取宿主机内存或拼接逃逸链的操作。

六、补丁没有重写整个网络栈，而是把关卡放到写入之前

Linux 主线修复提交为：

6785011f8b16abf40b1e9d8b2e332232b3e68822
ipv4: validate checksum_start before completing checksum

它在 include/net/ip.h 中加入了一个辅助函数，核心检查如下：

if (unlikely(skb->csum_start <
             skb->network_header + ip_hdrlen(skb)))
    return -EINVAL;

图 9：真实代码网页截图，来源 Linux 主线修复提交，截取于 2026-10-19。

翻译成日常语言：开始计算的位置，不许落在 IPv4 包头里面。由于结果偏移非负，随后补写的位置也就不会倒退到这个包头里。

把网络头起点记为 N、包头长度记为 H、校验和计算起点记为 C、结果偏移记为 O，那么：

C >= N + H
O >= 0
所以 W = C + O >= N + H

图 10：本文原创示意图。保护 IPv4 包头，与证明所有传输层字段正确，是不同的验证范围。

这次提交总计修改六个文件，在五处相关消费者路径中加上保护，涉及 IPv4 分片、桥接连接跟踪、Netfilter 队列、CHECKSUM 目标和 XFRM 输出。

补丁说明明确使用了“纵深防御”的说法，并指出更完整的入口验证仍需继续工作。我们因此可以说它补上了这条已识别路径的重要约束，但不该宣称“整个 virtio 校验和接口的所有安全问题都彻底消失”。

七、该升级到哪一版：上游数字与 Ubuntu 包版本要分开看

CVE 记录在本文核查时列出了这些上游修复基线：

这张表用于读懂上游记录，不是把所有 Linux 发行版按 uname -r 一刀切。发行版可能把安全补丁回移到自己的版本轨道，仍沿用较早的上游版本号。反过来，版本数字看着新，也不能代替具体构建包含补丁的证据。

尤其需要提醒 Ubuntu 26.04 用户：2026 年 10 月 19 日核查时，Ubuntu 官方页面的 linux / 26.04 LTS resolute 行仍为 Needs evaluation，尚未给出这一行的修复包版本。页面同时显示 Ubuntu 优先级为 Medium、CVSS 严重性为 Critical；这是两种判断口径，不能当成互相抵消。

图 11：真实网页截图，来源 Ubuntu CVE 页面，截取于 2026-10-19。状态随厂商后续更新可能变化。

正确做法是保持当前发行版和厂商内核轨道，关注对应安全公告、固定包版本或补丁证据。不要为了让数字“大过表格”，直接把生产机器换成未经验证的其他内核。

八、Windows 11、Ubuntu 26.04、macOS 27，分别该检查哪一层

本 CVE 指向 Linux 内核，不能由此认定 Windows 原生内核或 macOS 的 Darwin 内核存在同一缺陷。Linux 后端是否能被相同方式触达，也必须结合具体产品判断。上表是在确定核查职责，不是在宣布这些产品都已证实可被利用。

如果你在容器里跑 uname -r，通常看到的是它共享的 Linux 内核，不是一份随容器镜像独立升级的内核。更新应用镜像可以修应用漏洞，却不能替宿主机修这一个内核缺陷。

九、三端一键工具：先自动查清楚，再按证据做更新

我把本文的本地工具做成了一个 可下载的离线脚本包，也可以分别下载 Windows PowerShell 脚本、Ubuntu Bash 脚本 和 macOS Zsh 脚本。SHA-256 清单 用于核对下载是否一致。

三个脚本使用系统原生工具，不需要 Python、在线漏洞扫描平台或额外 SaaS 服务。默认一条命令完成本地盘点并生成 JSON，不上传数据、不启动未知虚拟机、不运行漏洞利用。需要更新时，Ubuntu 使用机器已经配置的 APT 仓库，WSL 使用 Microsoft 更新通道；这些联网更新需要对应软件源可达。离线环境仍可完成审计，补丁则应由管理员通过既有离线分发流程提供。

为了避免“自动化假绿灯”，脚本保留了一个很重要的结果：VENDOR_CONFIRMATION_REQUIRED，即仍需厂商证据。Ubuntu 能自动升级已安装、支持识别的内核元包；WSL 可以显式请求更新。macOS 的多个 Linux 后端没有一个通用、可靠的系统自带升级命令，所以这里自动完成盘点，把产品升级交回对应厂商流程。

方法 A：人工发起，脚本自动执行

下载并检查脚本内容，在解压目录运行。Windows 11 使用 PowerShell：

powershell -NoProfile -ExecutionPolicy Bypass -File .\pwnescape-windows.ps1

这里的执行策略仅作用于这个新启动的 PowerShell 进程，不会修改系统的永久执行策略。需要更新 WSL 时，在管理员 PowerShell 中运行：

powershell -NoProfile -ExecutionPolicy Bypass -File .\pwnescape-windows.ps1 -UpdateWSL

更新后仍需确认新内核是否已激活。维护窗口内、保存所有 WSL 工作后，可追加 -RestartWSL；这会停止所有 WSL 工作负载。Docker Desktop 或其他后端继续依据其自己的公告更新，不能把 WSL 更新结果套给全部虚拟机。

Ubuntu 26.04 的离线审计与可选更新分别为：

bash pwnescape-ubuntu.sh --out audit-before.json
sudo bash pwnescape-ubuntu.sh --apply --out audit-after-update.json

--apply 只适用于 Ubuntu 26.04，且要求处在能确定归属的非容器环境。它通过已安装的内核元包识别当前轨道，使用 APT 更新，不增加软件源、不移除软件包，也不自动重启。WSL、无法识别的内核轨道和容器内执行会拒绝更新，避免把修复装错层。

macOS 27 使用：

zsh pwnescape-macos.zsh --out audit-macos.json

它自动记录原生系统版本及能识别的 Docker Desktop、OrbStack、Lima、Colima 安装线索，不读取虚拟机名称、账号、网络地址或环境变量清单。有限的盘点没有发现应用，不代表机器绝对不存在其他 Linux 虚拟机。

脚本完成审计但仍需核实修复证据时，退出码为 2；参数或执行失败为 1，帮助信息为 0。不要把 2 当成“已经安全”的成功信号，也不要仅因为它非零就忽略已经写出的审计报告。

方法 B：让 Agent 自动配置和执行

把 Agent 执行说明 和脚本放在同一工作目录，然后给本地 Agent 这段任务：

先阅读当前目录的 AGENT-INSTRUCTIONS.txt 和对应平台脚本。
离线运行默认审计，把报告仅保存在本地，不上传设备信息。
区分原生系统、Linux 客户机和真正需要修补的宿主机。
核实对应厂商公告、固定包版本或补丁证据；缺证据就保留待核实。
经我授权维护后，执行脚本支持的官方渠道更新。
重启或停止工作负载前确认维护窗口，保存工作。
激活更新后重新审计，并核对正在运行的内核与正常业务。
最后列出已确认、已更新、待激活和仍未知的项目。

这份说明允许 Agent 自动选择平台、收集有限事实和整理结果，同时要求它遵守维护授权边界。不要让 Agent 在生产系统上通过“跑一次逃逸看看”来验收，也不要让它把不认识的厂商构建猜成安全版本。

工具验证范围也需要公开：Bash、Zsh 已做语法检查，macOS 默认审计已实机执行，Linux 默认审计已在 Linux 环境执行；还核查了帮助、错误参数和拒绝不适用平台等分支。Windows PowerShell 脚本经过静态审阅，本次没有 Windows 11 实机，Ubuntu 26.04 的更新路径也没有在生产主机执行，不能声称三端修复均已实测完成。

十、真正收尾时，要确认“值班的人”已经换了

安装新内核，就像把新保安的制服送进仓库；正在门口值班的，仍可能是旧保安。

图 12：本文原创示意图。热补丁也需要确认明确覆盖本 CVE，不能只看服务已启用。

维护结束至少核对三件事：厂商说明这个包或构建包含修复；当前真正处理网络包的内核已切换到对应构建；正常虚拟机、网络、DNS 与业务请求仍然工作。uname -r 可以提供运行身份线索，但发行版回移补丁仍要结合包版本和公告判定。

在修复证据或维护窗口尚未到位时，可以按环境限制新的不可信任务、收紧不必要的设备与网络能力，或把高风险工作负载暂时放到已确认修复的隔离资源。这些是降低暴露面的措施，不是补丁替代品。

不建议把“关闭全部 offload”写成一条通吃的修复命令。它可能影响性能和不同的数据路径，软件回退也可能涉及校验和补全；没有针对当前产品的验证，不能靠一个开关承诺所有入口都被封住。

图 13：本文原创示意图。每一步都应留下与当前环境对应的证据。

十一、几个最容易被问到的问题

我不用 Vercel，也需要关注吗？

需要根据实际环境评估。缺陷来自上游 Linux，而非 Vercel 专属配置。运行不可信客户机的自建平台应优先检查，但不能由此推导“所有云厂商都已证实能逃逸”。

只升级虚拟机里面的 Ubuntu，够不够？

如果有问题的处理发生在外层宿主机网络栈，只升级内层客户机不够。就像给住户换门，无法替整栋楼修门禁。需要先确认哪一层内核正在处理那条路径。

没有崩溃、日志也很安静，是不是没事？

不能这样判断。可用性和保密性是不同维度，内存泄漏未必留下明显故障。反过来，一次普通网络故障也不能直接当作这个漏洞遭利用的证据。

分数这么高，为什么 Ubuntu 写 Medium？

CVSS 基础分与发行版优先级服务于不同决策。实际配置、暴露条件和厂商评估会影响排期。应该查看优先级解释及对应内核状态，不能只挑一个词证明“很危险”或“完全不用管”。

Ubuntu 更新后，脚本为什么还不显示 Fixed？

因为 APT 成功只证明事务完成。本文核查时官方仍未给出该行的修复版本，脚本没有可靠证据把一个未知构建宣布为已修复。等厂商公告更新后，再把实际运行构建与公告对应起来。

AI 找到漏洞，意味着以后把安全交给 Agent 就行了吗？

研究者披露使用了 AI 辅助源码分析和实验组织，但也明确保留人类主导、对照实验和独立复核。会提出一个看起来聪明的猜想，与证明它能跨越真实边界，是两件需要分别完成的工作。

这次最值得带回日常开发的审查问题是：如果一份数据已经参与了安全判断，后面的异步任务、延迟写入或格式转换，还能不能悄悄改变它的含义？从网络包到消息队列、文件上传和后台任务，这个问题都值得沿着实际调用链问到底。

参考资料与核查时间

以下一手资料核查于 2026-10-19。修复状态可能继续更新，执行维护时应重新读取厂商公告。

1. CVE-2026-99999 官方记录：编号、状态、CVSS、受影响范围及上游修复基线。
2. NVD 条目：条目处理状态与记录提供方评分。
3. pwn.ai：PwnEscape 原始研究：机制、受控实验、完整逃逸证据边界及补丁讨论。
4. Vercel：Sandbox 挑战复盘：生产泄漏验证、实验环境影响与厂商响应。
5. Linux 主线修复提交：实际改动与纵深防御范围。
6. Linux：Checksum Offloads：校验和元数据和补全机制。
7. Ubuntu 官方安全页面：发行版优先级、内核轨道与当前修复状态。
8. Microsoft：WSL 基本命令：WSL 更新、关闭与版本查询命令。