CVE-2026-98432：Ubuntu 和 RHEL 仍无补丁，而 Claude 模型已编写出漏洞利用程序

关于 CVE-2026-98432 的这两件事放在一起令人不安。它是 Linux 内核 IPv4 TCP 握手过程中的释放后使用漏洞，可通过网络访问，无需登录、无需交互，内核 CVE 团队给它评分为 9.8。截至 2026 年 10 月 30 日，Ubuntu 尚未为 22.04、24.04、26.04 或 26.10 发布修复，Red Hat 则将 RHEL 8、9 和 10 列为受影响，既没有修复，也没有官方认可的缓解措施。第二件事是，10 月 27 日，Anthropic 发布研究称，一个未发布的 Claude 模型针对运行 MPTCP 监听器的服务器，生成了可用的概念验证，可实现未认证远程 root——大约 48 分钟泄漏内核地址，再用五分钟实现命令执行。

两大企业级 Linux 厂商至今仍无法修补的漏洞，外加一个部分由机器编写的可用漏洞利用程序——这可不是一次例行的“补丁星期二”。它正是那种决定性案例：你的内核升级流程与你的 Agent 访问策略到底有没有关系。

这个 bug，用一段话说明

在建立 TCP 连接时，附加在传入数据包上的 IP 选项会被交给新套接字，而不是被复制。如果握手发生重传，该数据包可能会在不同于拥有该选项缓冲区的 CPU 上被处理——而第二个 CPU 可能读取第一个 CPU 已经释放的内存。请求迁移路径上也存在类似的竞态。受影响范围始于内核 4.4，也就是说大多数仍在运行受维护内核的机器都受影响。上游修复提交 code>e3f33b0a1d89/code>，将释放选项缓冲区推迟到不再有其他核心可能持有引用时。

可利用性源于其机制：无需认证、无需用户交互、存在网络可达路径，以及可反复尝试的竞态。Anthropic 自己对 PoC 为何可行的总结正是这一特性——竞态失败只会导致一次握手失败，而不会使机器崩溃，因此攻击者可以再次尝试。

三家供应商，三个严重程度数值

评分拆分是值得内化的部分，因为它决定了你的扫描器本周是否会创建工单。

• 内核 CVE 团队 — 9.8，严重。网络可达，无需特权，无需交互。

• Red Hat — 8.1，重要。公司的立场是，这场竞赛在实践中很难获胜。

• Ubuntu — 高优先级，所检查的页面上未公布数值评分。

9.8 与 8.1 之间的差距并不是关于该漏洞的分歧，而是关于赢得一场竞态的概率的分歧。两者都站得住脚，而这一差异在操作层面很重要：带有公开 PoC 的 9.8 是紧急事件，带有难以赢下的竞态的 8.1 则是计划内修复。在有人发布真实硬件上的复现数据之前，诚实的解读是这场竞态是可以赢下的，因为据称有一个前沿模型赢下了它。

谁有修复方案，谁没有

截至10月29日至30日，情况参差不齐，这会让那些认为稳定内核就等于已修补内核的人措手不及。

• Debian 12 bookworm — 已通过 DLA-4841-1 在 6.1.190-1 中修复。

• Debian 13 trixie — 已通过 DSA-6568-1 在 6.12.113-1 中修复。

• Ubuntu 22.04、24.04、26.04、26.10 — 尚未发布修复；工作正在进行中。

• Ubuntu 16.04、18.04、20.04—— 存在漏洞，尚未发布修复程序。

• RHEL 8、9、10 和 OpenShift 4——受影响，无修复方案，也没有 Red Hat 认可的缓解措施。

• RHEL 6 和 7 — 不受影响。

• Amazon Linux 2023 — 内核 6.18 据报告已修复；Oracle Linux UEK 据报告已修复；SUSE 报告称部分版本已修复，其他版本仍在测试中，但未指明版本。

包含该修复的上游稳定版本为 5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 和 7.3——如果你自行编译内核而不是使用发行版软件包，就应参照这份列表核对自己的构建。

为什么 MPTCP 总是被提及

这个漏洞并非 MPTCP 特有，而很多报道正是在这里出错。Red Hat 将任何可访问的 TCP 服务都视为可能的触发点。MPTCP 提供的是已证实的路径，而提供流量的是 Go：当内核开启 MPTCP 时，Go 1.24 及更高版本会默认在 Linux 的监听套接字上启用多路径 TCP。Go 安全团队于 10 月 29 日就这一组合发出了警告。

因此，“禁用 MPTCP”消除的是 Anthropic 所演示的那条攻击路径，而非漏洞本身。作为一种可辩护的临时措施，它有一个明确的附加说明：今天在 Go 服务上值得这么做，但它不能替代打补丁的内核。

这些检查很简短：

• code>ss -Mltnp/code> — 列出当前正在使用 MPTCP 的套接字。

• code>net.mptcp.enabled/code> — 表示该内核功能是否处于启用状态。

• code>net.ipv4.tcp_migrate_req/code> — 默认关闭；如果你已将其开启，请重新关闭。

具体到 Go，可在运行时设置 code>GODEBUG=multipathtcp=0/code>，或一条 code>godebug/code> 行位于 code>go.mod/code> 中，即可让该二进制选择退出。

这些都没有得到厂商的认可。Red Hat 明确表示，没有任何缓解措施能够达到其自身的标准——这句话比罗列一堆寄望于侥幸的变通方案更有用。

Anthropic 究竟发布了什么

这项研究范围狭窄且具体。一个尚未发布的 Claude 模型在获得该 CVE 信息以及一个带有 MPTCP 监听器的目标后，生成了一条利用链，在大约 48 分钟内泄露了一个内核地址，并在约五分钟后实现了命令执行。Anthropic 尚未公布该漏洞利用代码；截至 10 月 29 日，厂商和 CVE 记录均未报告任何在野攻击；该漏洞不在 CISA 的 KEV 目录中。10 月 30 日，一个第三方 GitHub 仓库发布了用于触发竞态条件和内存泄漏的实验室工具——一个复现框架，但尚未达到完整代码执行。

这种组合才是耐人寻味之处。能力已被展示出来，武器却被扣下不发，而那个使其成为可能的关键细节——将一次脆弱的竞态转变为可靠竞态的重试特性——已以文字形式公之于众。任何能够复现该竞态的人，如今都明白为何值得坚持下去。

本周做什么

• 存在修复方案时，请安装补丁并重启。内核修复即使已安装但未重启，也不算真正修复；请用 code>uname -r/code> 验证。

• 如果你的发行版没有补丁——Ubuntu 22.04 至 26.10、RHEL 8 至 10——现在就决定：是采用厂商提供的实时补丁，还是迁移到已修复的版本，或者接受这一暴露风险并在 Go 服务上关闭 MPTCP。

• 清点 MPTCP 暴露面，而不是假定它已关闭。默认值是在 Go 中改变的，而不是在你的配置中，而默认值的变化在配置差异中是不可见的。

• 演练重启。此类修复需要完整重启，而那些在维护窗口期间才发现自身故障转移方案的组织，损失的时间最多。

这个 CVE 实际上引出的两个问题

第一个问题涉及漏洞利用生成，而且并非哲学问题。一个模型在一个具有特定启用配置的目标上，于不到一小时内发现了一个许多人类研究人员都未能发现的序列。无论该漏洞利用是否被公开，时间线都已经改变：从公开公告到可用的漏洞利用之间的窗口，现在要参照那些会阅读该公告的模型来衡量。

第二点讲的是：当厂商无法打补丁时，打补丁究竟意味着什么。为你交付内核的发行版和包含修复的内核并不是同一个对象，而它们之间的落差，恰恰是本文大多数读者所面对的这一漏洞的所在。OrcaRouter AI Incident Archive 会将此类事件与其原始来源、严重程度和置信度对应起来建立索引，而这正是新闻周期过去后仍值得留存的那个版本。

最不该做的就是把这件事归到“等待供应商”这一类。供应商自己的页面说，目前还没有什么可等待的。

来源说明：该机制、自内核 4.4 起受影响的范围、上游提交 code>e3f33b0a1d89/code>、稳定版本列表以及缓解指导均来自 2026 年 10 月 30 日查阅的 CVE 记录和发行版公告。9.8、8.1 和 Ubuntu High 评级分别来自内核 CVE 团队、Red Hat 和 Canonical。各发行版的补丁状态来自 Debian 的 DLA-4841-1 和 DSA-6568-1、Red Hat 和 Ubuntu 的 CVE 页面，以及同日厂商声明。概念验证时间线、48 分钟和 5 分钟的数字以及重试属性来自 Anthropic 10 月 27 日的研究，该研究未公开漏洞利用代码。10 月 30 日的实验室仓库被描述为第三方仓库，并非我们的。