Xray 紧急安全更新：如何在 Linux 上修复 CVE-2026-98432 漏洞

核心要点（Key Takeaways）

• CVE-2026-98432 是一个 Linux 内核漏洞。 更新应用程序可以降低暴露风险，但要从根本上修复漏洞，仍然需要为操作系统安装安全补丁。
• Anthropic 已演示通过暴露 MPTCP 监听端口的服务器远程执行 Root 权限命令。 但这一研究结果并不意味着所有 Linux 部署环境都具备完全相同的可利用条件。
• Xray-core v26.10.31 默认禁用了 MPTCP。 官方版本公告同时确认撤回 v26.10.29 版本。
• Go 1.24 在受支持的 Linux 系统上引入了默认启用 MPTCP 监听的行为。 实际行为还取决于构建配置、应用程序设置以及内核支持情况。
• 禁用 MPTCP 只能作为临时缓解措施。 要彻底修复漏洞，必须安装发行版厂商确认有效的内核安全补丁，并确保修复已在当前运行的系统中生效。

更新时间：2026 年 11 月 1 日。 Xray 紧急版本公告明确建议用户同时升级 Xray 和更新 Linux 系统。这是两项相互独立的维护任务，不能相互替代。

什么是 CVE-2026-98432？

CVE-2026-98432 是 Linux 内核在处理 IPv4 TCP 连接时存在的一个释放后使用（Use-After-Free，UAF）漏洞。

在特定的并发时序下，一条执行路径可能提前释放连接选项所使用的内存，而另一条执行路径仍然尝试访问该内存，从而造成内存安全问题。

相关内核变更最早可以追溯到 Linux 4.4。这说明漏洞产生的历史来源，但并不代表此后所有内核版本在安装安全更新后仍然存在漏洞。

不同 Linux 发行版厂商对漏洞严重程度的评估存在差异：

这些评估分别记录在 Ubuntu 漏洞跟踪页面 、Amazon Linux 漏洞跟踪页面和 Red Hat 安全公告中 。

因此，不应将某一个 CVSS 分数描述为所有厂商一致认可的评级。

Linux 内核漏洞的工作原理

该漏洞涉及 TCP 连接建立过程中 IPv4 选项数据的所有权管理和内存生命周期管理。

1. 一个等待建立的连接持有 IPv4 选项数据。
2. Linux 内核将这些选项转移到新创建的 Socket，但没有复制相应数据。
3. 另一个 CPU 可能同时为重传的连接请求准备响应。
4. 如果新创建的 Socket 首先被销毁，处理重传响应的代码路径就可能访问已经释放的内存。

修复方案是在相关代码路径中使用 kfree_rcu()，取代立即释放内存的方式。

这种机制会延迟内存回收，直到当前所有 RCU 读取者完成访问，从而避免并发情况下的释放后使用问题。

Linux 内核 CVE 公告还指出了一个相关的请求迁移处理路径 。

这一漏洞带来了一个重要的运维结论：不能依赖应用层身份验证来阻止攻击。

因为漏洞可能在 Linux 内核建立 TCP 连接的过程中就被触发，而 HTTP 登录页面等应用层安全机制是在这一处理阶段之后才发挥作用的。

Anthropic 究竟演示了什么？

在 2026 年 10 月 27 日发布的研究报告中 ，Anthropic 描述了一个尚未公开发布的内部研究模型如何针对暴露 MPTCP 监听端口的 Linux 服务器生成漏洞利用程序。

根据报告，攻击链首先泄露内核地址，以绕过内核地址空间布局随机化（KASLR），随后实现以 Root 权限执行攻击者指定的命令。

需要特别注意报告中的时间数据：

这些数字表示 PoC 漏洞利用程序的执行时间，并不是 Claude 发现漏洞或开发 Exploit 所花费的时间。

同样，这些数据也不能被理解为攻击者入侵任意 Linux 服务器所需的普遍时间。

Anthropic 还指出，当竞争条件攻击尝试失败时，TCP 握手可能失败，但系统不一定崩溃，因此攻击者可以继续重试。

这一演示证明了漏洞具备严重的可利用性，但并不能单凭该研究就认定现实环境中已经发生大规模攻击。

为什么 Go 1.24 让 MPTCP 成为安全关注重点？

MPTCP（Multipath TCP，多路径 TCP）允许一个 TCP 连接同时利用多条网络路径进行通信。

应用程序可以主动请求创建 MPTCP 监听 Socket，即使连接该服务的普通客户端仍然使用传统 TCP。

根据 Go 官方 GODEBUG 文档 ，不同配置项具有以下行为：

Go 1.24 将 multipathtcp=2 引入为默认配置。

不过，Go 的兼容性设置还可能受到模块或工作区声明的 Go 版本，以及显式构建指令的影响。

因此，仅仅知道程序使用哪个 Go 编译器版本，并不足以判断其实际生效的 MPTCP 配置。

还需要注意另一个区别。

Go 网络 API 文档允许应用程序通过 SetMultipathTCP 方法，为单独的监听器覆盖默认设置。

官方文档还说明，当 MPTCP 不可用，或者客户端不支持 MPTCP 时，连接可以回退到普通 TCP。

因此，即使观察到客户端使用的是普通 TCP 流量，也不能证明服务器没有启用 MPTCP 监听。

Xray-core v26.10.31 做了哪些修改？

Xray PR #7291修改了监听器的默认配置行为 。

核心逻辑如下：

lc.SetMultipathTCP(false)

if sockopt != nil {
    lc.SetMultipathTCP(sockopt.TcpMptcp)
}

以上代码仅展示相关的核心行为，并不是完整的监听器实现。

修改之后，MPTCP 默认处于关闭状态，但用户仍然可以通过显式配置重新启用它。

因此，管理员升级后仍应检查现有配置中是否存在 tcpMptcp 设置。

对于通过管理面板安装和运行 Xray 的用户，还需要确认面板实际启动的是哪个 Xray 可执行文件。

管理面板升级成功，并不代表其中捆绑的 Xray-core 已经更新，也不代表运行中的进程已经重新启动。

哪些部署环境应该优先排查？

建议根据服务是否可以被访问，以及当前运行内核的补丁状态确定排查优先级。

MPTCP 项目的应用支持列表记录了部分应用默认启用 MPTCP 的版本，例如 Caddy v2.10.0，以及包括 Traefik v2.11.26 和 v3.4.2 在内的特定版本。

这些信息有助于识别值得调查的应用，但不能直接证明某个具体部署环境存在可被利用的漏洞。

Xray 的发布公告还特别提醒 Android 用户：如果客户端向局域网暴露 Socks 或 HTTP 入站服务，同样需要关注安全风险。

即使是客户端应用，也可能因为创建入站监听端口而产生攻击面。

Go 安全团队的公告进一步指出 ，这个底层内核漏洞并不是 MPTCP 独有的问题。

即使系统没有 MPTCP 监听器，也可能存在其他漏洞利用路径。

哪些 Linux 内核版本已经修复漏洞？

根据持续维护的 Linux 内核 CVE 记录 ，以下上游内核版本已经包含修复：

最初的安全公告已经指出，主线内核的修复包含在 7.3-rc7 中。

生产环境应优先通过当前 Linux 发行版支持的官方更新渠道获取补丁。

不能简单地使用上游内核版本号作为通用的漏洞检测规则。

因为 Linux 发行版可以将安全补丁向后移植到较旧的内核分支，同时保留原来的基础版本号。

根据本文审查的发行版公告，各系统状态如下：

Debian 安全跟踪页面提供的是源代码包版本 ，它不一定与 uname -r 命令输出完全一致。

AlmaLinux 补丁公告也明确区分了测试版本和生产环境正式版本 。

需要注意，以上软件包状态可能在本文更新后发生变化。

第一步：检查当前运行的 Linux 系统

首先在每台相关 Linux 主机上执行以下只读检查命令：

uname -r
cat /etc/os-release
sysctl net.mptcp.enabled
sysctl net.ipv4.tcp_migrate_req

如果 Xray 可执行文件已经加入系统命令搜索路径，可以运行：

xray version

检查结果需要正确理解：

• uname -r 显示当前正在运行的内核版本，而不是磁盘上安装的所有内核版本。
• net.mptcp.enabled=1 表示系统允许创建 MPTCP Socket，但不能证明当前确实存在 MPTCP 监听端口。
• net.mptcp.enabled=0 并不代表底层 Linux 内核漏洞已经修复。
• 如果 MPTCP 对应的 sysctl 参数不存在，可能意味着内核不支持该功能，也可能是运行环境受到限制。这不能作为系统不存在该 CVE 的普遍证明。
• tcp_migrate_req=0 并不能排除另一条与连接请求重传有关的漏洞路径。

Linux 内核 MPTCP 文档明确指出 ，net.mptcp.enabled 是一个针对每个网络命名空间分别生效的配置项。

因此，仅检查宿主机网络命名空间，并不能确认所有容器中的 MPTCP 状态。

建议同时记录以下信息：

• Linux 发行版及版本
• 已安装的内核软件包
• 当前运行的内核版本
• 实际运行的服务可执行文件
• 服务对外暴露的网络接口

将这些信息统一记录，有助于后续重复验证修复效果。

第二步：根据实际需求降低 MPTCP 暴露风险

如果业务并不需要 MPTCP，可以暂时禁止当前网络命名空间创建新的 MPTCP Socket：

sudo sysctl -w net.mptcp.enabled=0

这条命令修改的是运行时配置。

如果希望重启后继续生效，需要通过系统正常的配置管理机制持久化该设置。

由于文档说明该参数控制的是 Socket 创建行为，因此不能假设修改配置后，已经存在的监听器也会自动被替换。

建议在受控维护窗口内重新启动相关服务，并在重启后验证实际配置。

如果系统使用多个网络命名空间，也需要分别评估。

对于 Go 服务，应当在实际负责启动程序的服务管理器中设置环境变量。

仅在一个无关的 SSH 终端中执行 export，并不会改变已经运行的后台服务进程。

例如，对于 systemd 服务，可以将下面命令中的 example.service 替换为真实服务名称：

sudo systemctl edit example.service

添加以下配置：

[Service]
Environment="GODEBUG=multipathtcp=0"

如果原来的 GODEBUG 已经包含其他必要配置，应保留这些设置，并在逗号分隔的配置值中仅修改与 MPTCP 有关的部分。

随后在计划好的维护窗口内重新加载配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl is-active example.service

需要强调，服务成功重新启动只能说明服务处于可用状态，不能证明漏洞已经彻底修复。

应用程序如果显式调用 SetMultipathTCP(true)，仍然可以覆盖环境变量提供的默认设置。

继承自其他进程的监听器，或者由外部组件管理的监听器，也需要单独检查。

Go 安全团队认为，逐个程序禁用 MPTCP 是一种比较脆弱的缓解方式：只要遗漏一个暴露在外的监听端口，就可能继续满足研究中展示的攻击条件。

因此，即使已经禁用 MPTCP，仍然必须安排 Linux 内核安全更新。

第三步：更新 Xray 并激活 Linux 内核补丁

通过现有的软件包管理、容器部署或管理面板更新流程，将 Xray 升级到 v26.10.31，或者升级到后续仍然保留这一安全缓解措施的版本。

随后，根据 Linux 发行版针对该 CVE 发布的安全公告，安装对应的内核软件包。

不能仅凭执行了普通系统更新命令就认定漏洞已经修复。

例如，以下情况都可能导致更新无效：

• 修复版本尚未进入正式软件仓库。
• 内核软件包被设置为暂缓更新。
• 安装的软件包属于不同的内核类型。
• 新内核已经安装，但系统仍在运行旧内核。

建议按照以下步骤实施：

1. 确认软件包安全公告明确覆盖 CVE-2026-98432。
2. 确认软件包与服务器架构及当前内核分支匹配。
3. 在重启远程服务器前准备好控制台访问方式和回滚方案。
4. 按照发行版官方支持的流程激活修复后的内核。
5. 重新检查正在运行的内核版本和应用程序健康状态。

完成常规内核更新并重启后，运行：

uname -r

将输出结果与已安装软件包及厂商安全公告进行对比。

磁盘上存在已经修复的内核软件包，并不意味着服务器实际启动了该内核。

如果服务器使用 Livepatch（内核热补丁），则需要明确确认当前运行内核上已应用的热补丁确实覆盖 CVE-2026-98432。

仅仅安装了 Livepatch 客户端，或者拥有有效的热补丁订阅，都不足以证明漏洞已经修复。

防火墙规则能否争取修复时间？

Red Hat 公布了一种临时 nftables 缓解方法，用于过滤包含 IPv4 选项字段的 TCP 数据包。

但其安全公告同时提醒 ，这种过滤方式可能干扰正常业务，而且不能代替内核补丁。

IPv4 Options（IPv4 选项）与 TCP Options（TCP 选项）是两个不同的协议字段。

如果规则的目标是过滤 IPv4 首部中的选项，就不能随意替换为无差别阻断 TCP 选项的规则。

在应用厂商提供的防火墙规则之前，需要先评估数据包实际经过哪些网络路径。

例如，宿主机的 INPUT 链与容器转发流量所经过的路径并不相同。

应结合实际网络路由、防火墙管理工具和回滚流程，对规则进行测试和验证。

这类过滤规则应被视为临时降低暴露风险的手段，并明确维护负责人和未来移除规则的计划。

常见问题与危险的安全误区

升级 Xray 就能彻底修复 CVE-2026-98432 吗？

不能。Xray 更新改变的是应用程序监听器的默认行为。Linux 内核本身仍然需要包含已经激活的安全修复，同时还应检查是否存在显式启用 MPTCP 的配置。

没有发现 MPTCP 连接，是否代表服务器安全？

不是。一个处于空闲状态的 MPTCP 监听器可能没有任何已建立连接。当前连接快照也无法证明内核是否已经安装补丁。

只使用 IPv6 的服务是否完全不受影响？

Linux 内核公告指出，主要的 IPv4 选项所有权管理问题不会影响对应的 IPv6 处理路径，因为 IPv6 选项会被复制。

但公告同时指出，涉及 CALIPSO 的 IPv6 请求迁移路径还存在另一个相关问题。

因此，在得出结论之前，还需要核实服务器实际上是否可以通过 IPv4 访问，特别是检查双栈监听器。

使用 HTTPS 或应用程序登录验证能够保护服务器吗？

不能依赖这些措施防御该漏洞。

HTTPS 和应用层登录控制是在 TCP 连接建立之后发挥作用的，不能作为这一 Linux 内核连接处理漏洞的有效缓解措施。

重新构建 Docker 镜像能够修复漏洞吗？

不能。

重新构建应用程序镜像不会替换容器运行时依赖的 Linux 内核。修复工作必须包含底层宿主机或虚拟机。

Anthropic 的研究是否证明所有 Linux 服务器都可以被远程获取 Root 权限？

没有。

已公开的漏洞利用演示依赖 MPTCP 监听器。漏洞潜在影响范围与已经实际演示成功的攻击条件，必须明确区分。

安装补丁后，是否就能证明服务器之前从未遭到入侵？

不能。

漏洞修复与安全事件调查是两个不同的问题。

如果发现可疑活动，应保留相关证据，并按照组织既定的安全事件响应流程进行调查。

结论（Conclusion）

CVE-2026-98432 的修复需要同时协调应用程序与操作系统的安全维护工作。

Xray 的紧急版本更新可以降低默认 MPTCP 监听带来的风险，但真正持久有效的修复仍然需要落实到当前运行的 Linux 内核。

建议首先排查所有对公网开放的服务器：确认内核版本和监听配置，实施必要的临时缓解措施，安装发行版厂商确认有效的安全补丁，并验证修复是否已经激活。

只有当当前运行的系统已经真正应用安全修复，而不只是下载或安装了补丁软件包时，才能将这项安全维护任务标记为完成。