最近，LINUX DO 上关于 CVE-2026-98432 临时缓解措施的讨论，让这个 Linux 内核漏洞受到不少关注。对于运行网站、监控和其他自建服务的人来说，最需要弄清楚的是：自己的系统是否受影响，发行版有没有提供补丁，以及暂时不能升级时能做什么。
这个 CVE 在 2026 年 10 月 15 日已经公开。10 月 27 日，Anthropic 发布研究，介绍了针对 MPTCP 监听服务的零点击远程 root 命令执行演示，进一步引起关注。演示证明了特定环境下的利用能力，不能据此推断所有 Linux 服务器都能以同样方式被攻陷。漏洞公开信息与研究原文分别说明了这两个时间点。
本文的官方进展核对时间为 2026 年 11 月 4 日，悉尼时间。处置上应优先安装发行版的修复内核；需要等待升级窗口时，再通过限制入口和过滤报文降低暴露面。
漏洞发生在哪里
CVE-2026-98432 位于 Linux 内核处理 IPv4 TCP 连接的路径中。问题与并发处理连接请求时的内存生命周期有关：一个处理过程释放了 IP 选项相关的内存，另一个处理过程还在读取它，形成 use-after-free，也就是“释放后使用”。
漏洞可能造成内核崩溃、信息泄露或内存破坏；研究人员已经在使用 MPTCP 监听服务的环境中演示了远程代码执行。更细的函数关系与 RCU 修复说明，可以查看 Linux 内核 CVE 公告。
漏洞本身不限于 MPTCP。 Ubuntu 官方明确指出，关闭 MPTCP 的建议主要针对已描述的研究利用方式，安全更新才是其认可的修复途径。因此，下文关闭 MPTCP 的操作只能作为补充措施，不能用来判定系统已经安全。Ubuntu 官方解释
官方修复进展
上游合入修复之后，发行版还需要回移补丁、构建软件包并完成测试。判断服务器状态时，要看正在使用的发行版和内核分支。
| 项目 | 截至核对时的状态 |
|---|---|
| Linux 上游 | 已修复并回移到维护中的稳定分支。披露说明 |
| Ubuntu | 22.04、24.04、26.04 的通用内核修复在 -proposed 测试仓库。官方进展 |
| Debian | Bookworm、Trixie 的安全仓库已提供修复。安全跟踪 |
| RHEL | 8、9、10 的标准 kernel 包已有修复公告。CVE 页面 |
| Amazon Linux | Amazon Linux 2、2023 已提供修复内核。AWS 公告 |
Debian 的 linux 源包中，Bookworm 从 6.1.190-1 起修复，Trixie 从 6.12.113-1 起修复。源包版本与 uname -r 的输出格式不同，需要对照已安装软件包。RHEL 的具体小版本、实时内核和 OpenShift 则应分别查询对应公告。
Ubuntu 的情况需要多看一层。Canonical 在 11 月 2 日的博客中列出了三个通用内核测试包：22.04 的 5.15.0-203.213、24.04 的 6.8.0-149.149、26.04 的 7.0.0-43.43。这些版本不能直接套到 linux-aws、linux-azure、HWE 或其他内核分支上。
同一篇官方博客将 Ubuntu 26.10 的 7.3.0-10.10 标为已修复，但本次核对时，CVE 跟踪页的对应项仍显示 work in progress。两处状态存在差异，安装前应继续确认当前仓库、具体包名和安全公告，避免只凭一张版本表作判断。
AWS 在其 11 月 2 日更新的公告中表示，尚无证据表明该漏洞已被利用。这是该公告当时掌握的情况，不应写成对所有环境的保证。
先检查自己的服务器
以下命令在目标 Linux 主机的 Bash 中执行。修改防火墙和重启服务前，保留现有 SSH 会话，并准备云控制台或其他恢复入口。文中的 203.0.113.10 是文档示例地址，必须替换成自己的可信来源地址。
确认发行版与正在运行的内核
1 | cat /etc/os-release |
Ubuntu、Debian 还可以查看内核包。这里同时列出二进制包版本和源包版本，方便对照发行版公告：
1 | dpkg-query -W -f='${binary:Package}\t${Version}\t${source:Package}\t${source:Version}\n' \ |
没有安装的包名可能产生提示，按实际已安装的条目判断即可。RHEL、Amazon Linux 可以查看：
1 | rpm -qa 'kernel*' | sort |
“安装了新内核”与“正在运行新内核”是两回事。 uname -r 显示后者；发行版还可能将安全补丁回移到较旧的版本号上，不能仅凭 5.x、6.x 这样的主版本号判定。
检查监听端口与 MPTCP
1 | # TCP 监听服务及其进程 |
net.mptcp.enabled = 1 表示允许创建 MPTCP socket，不代表应用已经在使用它；值为 0 或列表为空，也不能排除这个 CVE 的其他触发路径。若 ss 不认识 -M，需要使用支持该选项的 iproute2 工具，不能把命令失败当成“没有 MPTCP”。MPTCP 开关定义
监听在 0.0.0.0 或 [::] 表示绑定了通配地址，是否能从公网访问，还取决于路由、安全组和防火墙。容器与 Kubernetes 还涉及转发路径和独立网络命名空间；下面的主机 input 规则与主机 sysctl，不能自动覆盖这些路径。
暂时无法升级时的完整处置
下面三类措施作用不同：来源限制减少可达对象，报文过滤减少特定流量进入漏洞路径的机会，关闭 MPTCP 则减少已描述利用方式所需的条件。它们都不能替代内核补丁。过滤规则还会影响确实需要 IPv4 Options 的业务，应先验证业务需求和连通性。Red Hat 缓解说明
1. 收紧不必要的公网入口
云服务器优先在安全组或边界防火墙中限制来源，并同步检查 IPv4、IPv6。不同云平台的配置入口不同，不能用一条通用主机命令替代。
对于已经启用 UFW、服务直接监听在宿主机上的 Ubuntu 主机，可以按下面的例子，把监控端口 9100/tcp 限制为单个 IPv4 来源。先确认状态为 active：
1 | sudo ufw status verbose |
将可信监控服务器地址和实际监控端口填入变量，再执行：
1 | MONITOR_IP='203.0.113.10' |
这组规则会保存在 UFW 配置中。应确认允许规则排在该端口的拒绝规则之前，并从可信来源、其他来源分别测试新的连接。若使用 IPv6 监听，还要确认 UFW 的 IPv6 管理已启用，或在边界处同步限制 IPv6。
这里没有启用、重置或改变 UFW 的默认策略，也没有操作 SSH 端口。对 Docker 发布端口，不能直接套用这一结论：容器流量可能绕过 UFW 的主机输入规则，应使用边界过滤或容器对应的转发规则。UFW 命令说明与 Docker 防火墙说明
需要撤销这两条示例规则时，使用相同的地址和端口：
1 | MONITOR_IP='203.0.113.10' |
2. 过滤携带 IPv4 Options 的 TCP 入站报文
Red Hat 公布了如下 nftables 规则。这里匹配的是 IPv4 头部中的选项，与 TCP 时间戳、窗口缩放等 TCP Options 不同。ip hdrlength > 5 表示 IPv4 头部长度超过通常的 20 字节。
先确认已有工具；没有安装时，按发行版选择一条安装命令：
1 | command -v nft |
保存当前规则以便排查，再创建独立的规则文件。下面是首次应用流程；若表已经存在，先检查它，避免重复追加相同规则：
1 | sudo nft list ruleset > "$HOME/nftables-before-cve-2026-98432-$(date +%Y%m%d-%H%M%S).txt" |
首次检查提示该表不存在是预期结果。确认后创建文件：
1 | sudo tee /etc/cve-2026-98432.nft >/dev/null <<'EOF' |
--check 通过后才会应用；查看结果应能看到 counter drop 规则。这个独立链中的 policy accept 不会覆盖其他链的拒绝规则。应用后还应检查 SSH、网站及监控连接是否正常。nftables 官方手册
运行时规则不会因为写入了这个文件就自动持久化。 如果主机使用 UFW、firewalld 或其他程序管理规则，应在对应管理工具中集成，并检查它们重载规则之后的结果。
下面的持久化命令仅适用于由 nftables.service 读取 /etc/nftables.conf、未使用 UFW 或 firewalld 管理规则的主机。先查看服务定义和主配置，确认加载路径及现有规则：
1 | sudo systemctl cat nftables.service |
确认符合上述条件后，为主配置加入一次 include，并校验下次启动时要加载的整份配置：
1 | sudo cp -an /etc/nftables.conf /etc/nftables.conf.before-cve-2026-98432 |
这里不重启防火墙服务：运行时规则在前面已经加载。若主配置包含 flush ruleset，下一次由它加载时会重建整个规则集，必须确认完整配置也保留了原有防护。使用其他配置路径的发行版，应按实际服务定义集成，不能直接复制这个持久化步骤。
验证持久化需要在安排好的重启后再次执行：
1 | sudo nft list table inet cve_2026_98432 |
完成内核修复后，撤销本节配置的命令如下。如果没有做过 include 持久化，跳过第一条即可：
1 | sudo sed -i '\|^include "/etc/cve-2026-98432.nft"$|d' /etc/nftables.conf |
删除的只是本节建立的表和文件。已有防火墙继续按原来的管理方式运行；备份文件可在确认后另行处理。
3. 关闭不需要的 MPTCP，并重新创建相关 socket
如果业务没有使用 MPTCP 的需求，可以同时关闭新 MPTCP socket 的创建。该开关按网络命名空间生效，已经创建的 socket 还需要通过相关服务退出或重启来释放。
先查看原值：
1 | sysctl net.mptcp.enabled |
若提示没有这个 sysctl，当前内核可能未提供 MPTCP 功能，跳过本节；仍需核对内核漏洞修复状态。存在该参数时，保存原值，再写入持久化配置并立即生效：
1 | if ! sudo test -e /etc/sysctl.d/.cve-2026-98432-mptcp.previous; then |
接着根据 ss 输出识别服务，使用它本来的进程管理方式重启。下面以 node-exporter.service 为例，执行前替换成实际的 unit 名称：
1 | SERVICE='node-exporter.service' |
预期 sysctl 输出为 0，目标服务原有的 MPTCP socket 已释放，并且服务仍能正常响应。若应用依赖 MPTCP 且不支持普通 TCP 回退，关闭后可能无法正常启动；不要直接杀进程并假设它一定会自动拉起。
重启主机后应再次检查值是否仍为 0，防止被其他 sysctl 或网络管理配置覆盖。容器命名空间需要独立检查。内核对该参数的定义说明了它控制的是 socket 创建，而不是删除已经存在的 socket。
修复内核后，如果决定恢复原来的 MPTCP 设置，可以执行：
1 | if sudo test -f /etc/sysctl.d/.cve-2026-98432-mptcp.previous; then |
恢复开关后，应用是否重新使用 MPTCP，还取决于它如何创建 socket。
安装修复内核并确认生效
临时措施用于等待升级窗口；正式修复仍应来自当前发行版支持的软件仓库。
Ubuntu 与 Debian
先刷新索引并查看可用更新。下面的元包名只是常见示例：Ubuntu 普通通用内核使用 linux-generic，Debian amd64 使用 linux-image-amd64；云内核、HWE、ARM 等环境应换成实际已安装的元包。
1 | sudo apt update |
只有候选包已经包含修复时，这一步才构成漏洞修复。Ubuntu 用户如果准备采用 -proposed，应先阅读 Canonical 的测试包安装说明，在能做内核验收的环境中评估；它与正式更新仓库的发布状态不同。
RHEL 与 Amazon Linux
标准内核可按当前分支更新；实时内核或固定发布版本应继续对照对应公告。以下各组命令按自己的系统选择执行：
1 | # RHEL 标准内核 |
AWS 公告要求，锁定发布版本的 Amazon Linux 2023 使用 2023.12.20261102 或更新的版本才能获得相应更新。以上不适用于托管 Kubernetes 节点等由平台管理的环境；这类环境应按公告更新节点镜像或替换节点。
重启后再核对
确认修复包安装完成、已安排业务重启窗口后：
1 | sudo reboot |
重新连接服务器，检查当前运行内核和异常服务：
1 | uname -r |
将 uname -r 对应的软件包版本与发行版安全公告核对，确认启动的是包含补丁的内核，再检查网站、SSH、监控以及容器服务。随后按前面的撤销步骤评估临时规则是否继续保留。来源白名单本身如果符合业务访问需求，可以作为长期配置保留。
微信- 支付宝
