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

CVE-2026-98432 可能使 Linux TCP 服务器遭受远程 Root 权限攻击。了解如何检查 Xray 和 Go MPTCP 配置、获取内核安全补丁并验证修复结果。

Canonical URL: https://aiidelist.com/zh/blog/cve-2026-98432-xray-go-mptcp-linux-fix-zh

Language: zh

Published: 2026-10-31

Updated: 2026-10-31

## 核心要点（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 紧急版本公告](https://github.com/XTLS/Xray-core/releases/tag/v26.10.31)明确建议用户同时升级 Xray 和更新 Linux 系统。这是两项相互独立的维护任务，不能相互替代。

## 什么是 CVE-2026-98432？

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

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

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

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

| 发布机构 | 公布的风险评级 | 如何理解 |
| --- | --- | --- |
| Ubuntu | CVSS v3.1：9.8，严重（Critical）；Ubuntu 优先级：高（High） | CVSS 严重程度与发行版的补丁处理优先级是两个不同指标 |
| Amazon Linux | CVSS v3：8.1；重要（Important） | 其评分向量认为攻击复杂度较高 |
| Red Hat | 严重影响（Critical） | 安全公告指出存在未经身份验证即可实施远程代码执行的风险 |

这些评估分别记录在 [Ubuntu 漏洞跟踪页面](https://ubuntu.com/security/CVE-2026-98432)、[Amazon Linux 漏洞跟踪页面](https://explore.alas.aws.amazon.com/CVE-2026-98432.html)和 [Red Hat 安全公告](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016)中。

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

## Linux 内核漏洞的工作原理

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

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

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

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

[Linux 内核 CVE 公告](https://lists.openwall.net/linux-cve-announce/2026/10/15/1)还指出了一个相关的请求迁移处理路径。

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

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

## Anthropic 究竟演示了什么？

在 [2026 年 10 月 27 日发布的研究报告](https://www.anthropic.com/research/discovering-vulnerabilities-with-claude)中，Anthropic 描述了一个尚未公开发布的内部研究模型如何针对暴露 MPTCP 监听端口的 Linux 服务器生成漏洞利用程序。

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

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

| 演示阶段 | PoC 实际执行时间 |
| --- | --- |
| 获取内核指针 | 48 分钟 |
| 随后实现命令执行 | 额外约 5 分钟 |

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

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

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

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

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

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

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

根据 [Go 官方 GODEBUG 文档](https://go.dev/doc/godebug)，不同配置项具有以下行为：

| 配置 | 请求的默认行为 |
| --- | --- |
| `multipathtcp=0` | 对监听器和主动连接均禁用 MPTCP |
| `multipathtcp=1` | 对监听器和主动连接均启用 MPTCP |
| `multipathtcp=2` | 仅对监听器启用 MPTCP |
| `multipathtcp=3` | 仅对主动连接启用 MPTCP |

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

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

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

还需要注意另一个区别。

[Go 网络 API 文档](https://pkg.go.dev/net#ListenConfig.SetMultipathTCP)允许应用程序通过 `SetMultipathTCP` 方法，为单独的监听器覆盖默认设置。

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

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

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

[Xray PR #7291](https://github.com/XTLS/Xray-core/pull/7291/files)修改了监听器的默认配置行为。

核心逻辑如下：

```go
lc.SetMultipathTCP(false)

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

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

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

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

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

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

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

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

| 部署环境 | 建议排查内容 |
| --- | --- |
| 运行 Xray 的公网 Linux VPS | 检查 Xray-core 版本、显式 MPTCP 配置以及内核补丁状态 |
| Linux 上的 Caddy 或 Traefik | 检查实际部署的构建版本和生效的监听器配置 |
| 其他 Linux TCP 服务 | 即使应用程序并非使用 Go 开发，也应检查内核安全状态 |
| Linux 主机上的容器 | 同时检查宿主机内核和相关容器的网络命名空间 |
| Android 代理应用 | 检查局域网可访问的入站监听端口以及设备内核 |
| 托管服务器 | 明确哪些基础设施更新由服务商负责，哪些需要客户自行执行 |

[MPTCP 项目的应用支持列表](https://github.com/multipath-tcp/mptcp.dev/blob/main/apps.md)记录了部分应用默认启用 MPTCP 的版本，例如 Caddy v2.10.0，以及包括 Traefik v2.11.26 和 v3.4.2 在内的特定版本。

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

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

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

[Go 安全团队的公告](https://groups.google.com/g/golang-announce/c/PCoQcdxoScw/m/aD-MgXEvAAAJ)进一步指出，这个底层内核漏洞并不是 MPTCP 独有的问题。

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

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

根据持续维护的 [Linux 内核 CVE 记录](https://kernel.googlesource.com/pub/scm/linux/security/vulns/+/refs/heads/master/cve/published/2026/CVE-2026-98432.mbox)，以下上游内核版本已经包含修复：

| 内核分支 | 已记录的修复版本 |
| --- | --- |
| 5.10 | `5.10.272` |
| 5.15 | `5.15.223` |
| 6.1 | `6.1.190` |
| 6.6 | `6.6.159` |
| 6.12 | `6.12.113` |
| 6.18 | `6.18.56` |
| 7.2 | `7.2.10` |
| 7.3 | `7.3` |

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

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

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

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

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

| Linux 发行版 | 已公布状态 | 实际建议 |
| --- | --- | --- |
| Debian Bookworm | 安全源代码包 `6.1.190-1` 标记为已修复 | 安装对应的受支持内核软件包 |
| Debian Trixie | 安全源代码包 `6.12.113-1` 标记为已修复 | 安装并激活更新后，确认正在运行的内核版本 |
| Amazon Linux 2 和 2023 | 已列出包含修复的软件包公告 | 根据实际使用的内核分支匹配对应公告 |
| Ubuntu | 部分内核软件包仍被标记为存在漏洞或正在修复 | 检查具体 Ubuntu 版本和内核类型 |
| AlmaLinux 8、9 和 10 | 10 月 30 日公告提供了测试仓库构建版本 | 安装前确认生产仓库是否已经发布正式软件包 |
| RHEL | 安全公告表示正在加速推进修复 | 持续关注对应产品的安全更新公告 |

[Debian 安全跟踪页面](https://security-tracker.debian.org/tracker/CVE-2026-98432)提供的是源代码包版本，它不一定与 `uname -r` 命令输出完全一致。

[AlmaLinux 补丁公告](https://almalinux.org/ca/blog/2026-10-30-cve-2026-98432/)也明确区分了测试版本和生产环境正式版本。

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

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

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

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

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

```bash
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 文档](https://docs.kernel.org/networking/mptcp-sysctl.html)明确指出，`net.mptcp.enabled` 是一个**针对每个网络命名空间分别生效的配置项**。

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

建议同时记录以下信息：

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

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

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

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

```bash
sudo sysctl -w net.mptcp.enabled=0
```

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

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

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

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

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

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

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

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

```bash
sudo systemctl edit example.service
```

添加以下配置：

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

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

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

```bash
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. 重新检查正在运行的内核版本和应用程序健康状态。

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

```bash
uname -r
```

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

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

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

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

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

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

但其[安全公告](https://access.redhat.com/security/vulnerabilities/RHSB-2026-016)同时提醒，这种过滤方式可能干扰正常业务，而且不能代替内核补丁。

**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 内核。

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

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