CVE-2026-98432 等漏洞自查：AI 查出的 Linux、Windows 漏洞，运维怎么确认受不受影响

一、背景

10 月 27 日，Anthropic 发布研究，称用内部模型在多款主流软件中找到严重漏洞并报给厂商。对运维来说，重点不是"AI 多厉害"，而是这几个编号已经公开、补丁已经发布，该自查就自查。本文只讲怎么确认受不受影响、怎么确认修好，不涉及利用方法。

涉及的三个有编号的漏洞：

编号	软件	类型	触发条件	修复
CVE-2026-98432	Linux 内核网络栈	释放后使用	远程、无需凭证	上游已修，回移到各稳定分支
CVE-2026-33096	Windows HTTP.sys（QUIC / HTTP/3）	越界读取	远程发包使服务崩溃重启	微软已修（补丁版本见下）
Chrome 多个	Chrome 浏览器	多类	打开恶意网页	Chrome 156 已修，共 62 个编号

二、Linux CVE-2026-98432

2.1 受影响条件

官方编号记录描述的是 IPv4 TCP 处理重发 SYN 包时的释放后使用；Anthropic 的博客称影响开了 MPTCP 监听的服务器。两个口径指向同一编号，自查时都要看。

2.2 自查

复制代码

uname -r                          # 看内核版本
sysctl -n net.mptcp.enabled       # MPTCP 开关，1 为开
ss -Mln                           # 列 MPTCP 监听套接字

上游标注已修复的版本：5.10.272、5.15.223、6.1.190、6.6.159、6.12.113、6.18.56、7.2.10 及以上。发行版内核号和上游对不上，以发行版公告为准。

要说明的是：net.mptcp.enabled 为 0、或者 ss -Mln 查不到监听，只能说明当前这台机器暂时没把这条路径暴露出去，不等于"已排除漏洞"------配置随时可能被改回，补丁没打上，隐患还在。是否修好，看的是内核补丁，不是功能开关。

2.3 把已装内核和公告对上

上游版本号只能粗筛，发行版会把补丁回移到自己的内核包里，版本号和上游不一样。要确认补丁到没到位，看已装的内核包版本，再和发行版公告里写的补丁版本比对。

Debian / Ubuntu（apt 系）：

复制代码

# 列出已装的内核镜像包及版本
dpkg -l 'linux-image-*' | awk '/^ii/{print $2, $3}'
# 看某个内核包的变更日志里有没有这条编号（需联网）
apt-get changelog linux-image-$(uname -r) 2>/dev/null | grep -i CVE-2026-98432

RHEL / CentOS / openEuler（rpm 系）：

复制代码

rpm -q kernel                                   # 已装的内核包版本
rpm -q --changelog kernel | grep CVE-2026-98432 # 变更日志里找这条编号

变更日志里能搜到这条编号，基本说明当前内核包已带补丁；搜不到就按发行版公告升级。

2.4 处置

升级到带补丁的内核并重启；暂时不能重启的，评估关闭用不到的 MPTCP；处理后复查版本号，并重跑一遍 §2.2、§2.3。

三、Windows CVE-2026-33096

3.1 受影响条件

微软的编号记录把它归为 Windows HTTP.sys 的越界读取，攻击者远程发包可使服务拒绝服务（崩溃重启）。Anthropic 描述的是 Windows 内核 QUIC 实现的问题。编号记录里写的是 HTTP.sys，没有单独写 HTTP/3 / QUIC，两者是否完全同一处，公开信息没有明说，以微软公告为准。

3.2 自查

**判断是否修复，主要看补丁版本，不是看 HTTP/3 开没开。**编号记录指向 HTTP.sys，是否只在开启 HTTP/3（QUIC）时才能触发，公开信息没有明说。所以别把"没开 HTTP/3"当成"不受影响"，补丁版本才是准数。

第一步，看系统补丁版本。Windows 的完整版本号是 10.0.<内部版本>.<修订号>，要和微软公告里的修复版本逐位比：

复制代码

# 取当前内部版本号和修订号（UBR）
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($cv.CurrentMajorVersionNumber).$($cv.CurrentMinorVersionNumber)." +
  "$($cv.CurrentBuildNumber).$($cv.UBR)"

# 也可以直接看最近装的补丁
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5

把上一条命令打印出来的版本，和微软公告（搜 CVE-2026-33096）里你这个系统版本对应的修复版本比较。微软列出的部分修复版本示例：Windows Server 2022 为 10.0.20348.5020，Windows 11 24H2 为 10.0.26100.8246（完整清单以公告为准）。

第二步，看暴露面（辅助判断，不代替补丁）。HTTP/3 走 QUIC，Windows 上默认不开，要在注册表里置 EnableHttp3 才生效：

复制代码

# 查 HTTP/3 开关，返回 1 为开启，键或值不存在说明没开
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\HTTP\Parameters' `
  -Name EnableHttp3 -ErrorAction SilentlyContinue

开着 HTTP/3 的机器更该优先处理；没开也要按第一步把补丁打上。

3.3 处置

低于公告里的修复版本，按公告打补丁；
没有业务需要 HTTP/3 的，可以不开启（不置 EnableHttp3），减少这一面的暴露；
打完补丁重跑 §3.2 的版本命令确认。

四、Chrome

打开"关于 Chrome"让它检查更新，确认版本在 156 及以上，然后重启浏览器。企业统一管理的，推相应策略。谷歌为这一批共分配了 62 个漏洞编号，都评为严重或高危，所以别拖。

五、把扫描接进开发流程，别只补存量

上面几条都是补"已经公开的洞"。但 AI 既然能更快找出洞，新代码里带进来的洞也会更快被发现。只补存量、不管增量，等于一边堵一边漏。

Anthropic 在这篇研究里给防守方的建议之一，是在代码合并（PR）阶段就扫描，而不是等上线后集中处理。它把这套安全检查做成了一个 Claude Code 插件并公开发布。对自己有代码库的团队，可以参考这个思路，把安全扫描接到提交和合并环节：

每个 PR 自动跑一遍安全扫描，有新引入的问题就在合并前拦下；
对确认的问题做"变体分析"，顺手查同一类写法在别处有没有重复；
扫描结果走一套固定的验证和定级流程，避免误报淹没真问题。

这类做法不依赖某一家的工具，关键是把"扫描"从一次性动作变成每次提交都过的关口。

六、小结

AI 查漏洞这件事对防守方的实际意义是：公开的漏洞会更快、更多。应对办法没有变，只是更要抓紧------盯住自己用到的软件的安全公告，按编号确认受不受影响，及时打补丁；同时把扫描接进开发流程，别让新代码继续往里带洞。