Nginx 在 10 月 14 日发了 1.31.7 和 1.30.6，一次修 5 个洞。
我先把官方公告看完，再去看二手报道，落差有点大：官方五条全是 medium，二手标题写的是"critical"、"18 年 RCE"。
官方这 5 条，我抄一遍，方便对着查：
- CVE-2026-15176：
alias配合rewrite时的缓冲区溢出，影响 0.1.29–1.31.6 - CVE-2026-93479：脚本求值缓冲区溢出，影响 1.31.2–1.31.6、1.30.0–1.30.5。这条还有点讽刺——它是 7 月修复 CVE-2026-42533 时引入的回归，等于上一次打补丁，打出了一个新洞
- CVE-2026-95101：HTTP/3 请求体注入，影响 1.25.0–1.31.6
- CVE-2026-97629：TLS session ticket 会话伪造（可绕过客户端证书校验），影响 1.23.2–1.31.6
- CVE-2026-97205：异步文件 I/O（AIO）use-after-free，影响 0.8.11–1.31.6
注意每条后面都跟着一句"需要特定指令组合才触发"。session ticket 那条，只有在启用了相关配置、又拿 TLS 客户端证书做鉴权时才致命；AIO 本来就是个少见的边缘指令。
所以真正该做的不是看到 medium 就放心，也不是看到"critical"就通宵，而是先问一句：我这台机器上，到底有没有开 alias + rewrite？有没有开 AIO？
这两条指令，很多老项目里是祖传的——十几年前从别人的配置里抄过来，一直没动。官方影响范围写着 0.1.29，也就是说十几年前的版本都可能在名单里，这不是危言耸听。
说到这儿，我更想聊的不是这 5 个洞，是那个落差。
做安全运营最贵的成本之一，是替别人的标题做二次研判。一条"18 年 RCE"转进群里，三个人要去核，半天就没了；结果打开一手公告一看，medium，触发条件三条全不满足。这不是说不用修，是说判断优先级的信息应该来自一手公告，不是标题。
标题通胀还有个副作用：它会让"真的 critical"变得不值钱。狼来了喊多了，下次真出事，群里先怀疑的是"是不是又夸张了"。
我的土办法是拿到这类公告先分三桶：在野利用的、我确实暴露在公网的、版本真的命中的——先取交集，剩下的排期，别被标题牵着走。
想批量看机器上的 nginx 版本和编译参数，一台台 ssh 太慢，这类巡检用七亿批量远程管理工具能省不少事；但版本号、编译选项、include 进来的配置，还是得逐项对，工具替不了这步。
前几天写过另一个 Nginx 的洞（一行 18 年前的代码，一个请求打崩 Nginx），当时也有人问"要不要连夜升"。我的答案没变：先盘点暴露面，再排期。这次这 5 条，同理。
顺手补一句：容器里的 nginx 和宿主机没关系，K8s 的 ingress-nginx 得单独查版本。之前那批面板洞也踩过类似的坑（图省事装的 Nginx 面板，一晚上爆了七个洞）。
评论