NGINX 1.30.6 和 1.31.7：10 月漏洞公告之后为什么要升级

2026 年 10 月 14 日，nginx.org 发布了 stable 分支的 nginx 1.30.6 和 mainline 分支的 nginx 1.31.7。两个版本都修复了五个中等严重程度的漏洞。其中四个影响多年前发布的版本，而且每一个都只能在特定配置下触发，例如 HTTP/3 或 alias 搭配 rewrite。

如果你用 NGINX Open Source 承载生产流量，请升级到 1.30.6，或 1.31.7 及更高版本，或者升级到你所用发行版的修补软件包。检查配置可以帮你决定升级顺序，但不是继续停留在受影响版本上的理由：配置会随时间变化，而修补后的版本不再依赖那次分析。

本文说明这些版本修复了什么，如何确认服务器、软件包和容器镜像中实际运行的是哪个 NGINX，值得查找哪些指令，以及如何固定新版本，避免版本回退。最后，一个 Node.js 的真实案例展示了同一模式在另一个组件上的应用。

1.30.6 和 1.31.7 修复了什么

根据 nginx.org 的变更日志，10 月 14 日的五项修复如下：

• CVE-2026-15176：当 alias 指令处理一个此前被 rewrite 修改过的 URI 时，worker 进程中可能发生缓冲区溢出。影响 0.1.29 至 1.31.6。
• CVE-2026-93479：计算带变量的表达式时可能发生缓冲区溢出，涉及 http 和 stream 模块中 root 的计算和日志记录。影响 1.30.0 至 1.30.5，以及 1.31.2 至 1.31.6。
• CVE-2026-95101：使用 HTTP/3 时，未知帧的一部分可能被当作请求体处理，从而绕过 client_max_body_size，或向发往后端的请求中注入数据。影响 1.25.0 至 1.31.6。
• CVE-2026-97629：轮换 TLS 会话票据密钥时，其中一个密钥未被初始化，可能导致会话被伪造。影响 1.23.2 至 1.31.6。
• CVE-2026-97205：使用异步文件 I/O（aio）时，带有 include virtual 命令的 SSI 页面可能导致 use-after-free。影响 0.8.11 至 1.31.6。

nginx.org 将它们评为中等严重程度。负责分配 NGINX CVE 的 F5 在 NVD 中公布的 CVSS 3.1 分数在 5.3 到 8.1 之间。截至 10 月 23 日，NVD 还没有对这五个漏洞做出自己的分析。

如果你使用的版本早于 1.30.4，这次升级还会带来更早的修复。其中最重要的是 CVE-2026-42533，nginx.org 将其评为 major，并于 7 月 15 日在 1.30.4 中修复：当 map 使用正则表达式并与该 map 的捕获结合时，可能发生内存溢出。10 月 21 日发布的 mainline 版本 1.31.8 没有新增漏洞修复。

• nginx: security advisories
• nginx: CHANGES-1.30（stable 分支）
• nginx: CHANGES（mainline 分支）
• NVD: CVE-2026-15176
• NVD: CVE-2026-93479
• NVD: CVE-2026-95101
• NVD: CVE-2026-97629
• NVD: CVE-2026-97205
• NVD: CVE-2026-42533

即使你的配置不会触发，为什么也要升级

这些漏洞中的每一个都需要特定的组合：alias 搭配 rewrite、HTTP/3、TLS 票据轮换、aio 搭配 SSI。人们很容易检查一遍配置，没找到这些指令，就让版本保持原样。不这样做有三个理由。

第一，配置会变。一个新的 include、另一个团队的模板，或者在某台服务器上开启 HTTP/3，都可能在没人重新看公告的情况下让服务器重新暴露于这些漏洞。修补后的版本不依赖那次分析是否仍然成立。

第二是成本。1.30.6 与 1.30.5 属于同一分支，它的变更日志只列出了修复和部分日志消息级别的调整，没有新功能。在 stable 分支上，升级通常比维持并论证一个例外更省事。

第三，旧分支不会从 nginx.org 获得这些补丁。下载页面把 1.28、1.26 等列为 legacy 版本，而公告只把 1.30.6 和 1.31.7 及之后的版本标为已修复。如果你使用这些分支，出路是 1.30.6，或者你所用发行版的修补软件包。

第 1 步：确认你实际运行的是哪个 NGINX

重要的是承载流量的那个二进制文件的版本，它并不总是与 README 或镜像 tag 中写的版本一致。

# 二进制文件的版本
nginx -v

# 编译进来的模块：HTTP/3 显示为 --with-http_v3_module
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|file-aio|threads'

# Debian 和 Ubuntu：判断补丁是否已应用，要看软件包版本
apt-cache policy nginx

# 容器：镜像内的真实版本
docker run --rm nginx:1.30.6-alpine nginx -v

使用发行版软件包时，nginx -v 显示的数字可能会误导。发行版常常在自己的版本上打补丁，而不改变主版本号。以 Debian 13 为例，根据公告 DSA-6575-1，修复 10 月这五个 CVE 的软件包是 1.26.3-3+deb13u10，而 nginx -v 仍然显示 1.26.3。需要比较的是完整的软件包版本与你所用发行版公告中的版本。

• Debian security tracker: DSA-6575-1

在 Kubernetes 中，ingress 控制器或第三方镜像可能自带 NGINX 构建。例如，nginx.org 的页面会把它自己的 NGINX Ingress Controller 与社区项目 ingress-nginx 区分开。在这些情况下，修补版本由维护该控制器或镜像的一方发布。

第 2 步：查看配置用到了哪些指令

nginx -T 会校验配置并完整打印出来，所有 include 都已展开。用 grep 过滤后，可以得到与今年公告相关的指令的初步清单：

# 完整配置（include 已展开），按公告涉及的指令过滤。
# 行号是 nginx -T 输出中的行号，不是各个文件中的行号。
sudo nginx -T 2>/dev/null | grep -nE '^\s*(alias|rewrite|map|aio|ssi|http3|ssl_session_cache|ssl_session_ticket_key)\b|\$request_filename|\bquic\b'

根据 F5 在 NVD 中为每个 CVE 发布的描述，结果可以这样解读：

• 一个 location 同时使用 alias、rewrite，以及引用 $request_filename 变量的 set 或 return 指令，或者在 access log 格式（log_format）中使用 $request_filename，指向 CVE-2026-15176。
• 一个使用正则表达式的 map，其捕获变量在 root 或 access log 格式中出现在 map 输出变量之前，指向 CVE-2026-93479。如果它们以这种方式出现在任何带变量的表达式中，指向 CVE-2026-42533。
• 带 quic 的 listen，或 http3 on，指向 CVE-2026-95101。
• 使用 ssl_session_cache shared 而没有 ssl_session_ticket_key，指向 CVE-2026-97629。
• aio 与 ssi 一起使用，指向 CVE-2026-97205。

匹配并不能证明漏洞可以被利用，没有匹配也不能完全排除它：grep 看不到第三方模块，也看不到启动时生成的配置。它的作用是给工作排序。有匹配的服务器先处理，其余的照样升级。

第 3 步：升级并固定版本

在使用软件包的服务器上，按各系统的常规方式升级：安装新软件包，用 nginx -t 校验，然后重启服务，让新的二进制文件承载流量。根据 nginx 文档，reload 只会重新读取配置；要更换二进制文件，需要重启，或者用 USR2 信号进行在线升级。

• nginx: controlling nginx

在容器中，建议同时用 tag 和 digest 固定镜像。tag 说明你想要哪个版本，digest 则精确固定你审核过的镜像，即使有人重新发布了这个 tag。

# 可读的 tag 加不可变的 digest。
# digest 的获取方式：crane digest nginx:1.30.6-alpine
FROM nginx:1.30.6-alpine@sha256:47928bf67eb62a1863cb08d9ecb52d3e704304ba614eaee17884204677702951

这个示例中的 digest 是该 tag 在 2026 年 10 月 23 日返回的值。一个 tag 可能以不同的内容重新发布，例如在重新构建镜像时，所以请在固定时再获取 digest。

为了防止版本回退，可以在 CI 中加一项检查：只要有 Dockerfile 或清单使用了早于修复版本的 NGINX 镜像，就让它失败：

#!/usr/bin/env bash
# 如果有 Dockerfile 或 YAML 清单使用早于 1.30.6（stable）或 1.31.7（mainline）的 NGINX 镜像，则失败。
set -euo pipefail
refs=$(grep -rhoE --include='Dockerfile*' --include='*.yaml' --include='*.yml' \
  '(nginx|nginxinc/nginx-unprivileged):[0-9]+\.[0-9]+(\.[0-9]+)?' . | sort -u || true)
bad=0
for ref in $refs; do
  ver=${ref##*:}
  IFS=. read -r major minor patch <<< "$ver"
  patch=${patch:-0}
  if (( major < 1 || ( major == 1 && ( minor < 30 || (minor == 30 && patch < 6) || (minor == 31 && patch < 7) ) ) )); then
    echo "Needs update: $ref"; bad=1
  fi
done
exit $bad

这个脚本只识别带版本号的 tag。stable-alpine 或 latest 这类浮动 tag 没有可比较的数字，这也是要同时固定版本和 digest 的另一个原因。

真实案例：Node.js 上的同一模式

10 月 21 日，Node.js 发布了 24.22.1、22.23.4 和 26.12.1 版本。它们修复了多个漏洞，按项目自己的评级，其中最严重的为高危；同时把根证书更新到 NSS 3.131.1，Node.js 的公告把这次更新与 eMudhra 的一个中间 CA 被攻破的事件联系在一起。

eMudhra 事件有一篇专门的文章，介绍 macOS 上的开发工具需要更新什么。

• macOS 上的 eMudhra：curl、Node、Python、Go、Java、Rust 和 Docker 需要更新什么

一个在生产环境中运行、有多个容器镜像的 Node.js 项目，已经在其开发分支中完成了这次更新，其中三项做法同样适用于 NGINX：

• 所有镜像都改用 node:24.22.1-alpine，并同时用 tag 和 digest 固定。
• 一个自带 Node 22 的辅助镜像，以及一个使用 Node 20 的旧基础镜像，也升级到了同一版本。
• package.json 把 engines.node 声明为 >=24.22.1，CI 中有检查会拒绝版本更旧的镜像。

# 镜像内的 Node 版本，无需启动应用
docker run --rm node:24.22.1-alpine node -v

# 用于固定镜像的 digest
crane digest node:24.22.1-alpine

# 仅限已修复的 24.x 版本线（>=24.22.1 <25）；加上 --engine-strict 后，在该范围之外的任何 Node 版本上 npm install 都会失败
npm pkg set engines.node='^24.22.1'
npm install --engine-strict

这个经验可以原样照搬。一次漏洞补丁更新并不是改完一行就结束了：只有当版本在镜像中固定、在项目中声明、在 CI 中检查，后续的改动才无法在无人察觉的情况下把它撤销。

• Node.js: October 21, 2026 Security Releases
• Node.js 24.22.1 (LTS)：版本说明

这次更新不涵盖什么

如果 NGINX 不归你管，补丁也不归你管。CDN 或托管平台在你的应用前面放置的代理由其提供商负责更新，你要做的是清楚哪些组件确实由你管理。它也不涵盖同一家族的其他产品：例如 njs 在同一天 10 月 14 日发布了自己的 1.0.2 版本，修复的是不同的问题。

升级、固定、检查

10 月 14 日的公告要求的是把工作做完，而不是仓促应对：弄清哪个 NGINX 在承载流量，升级到 1.30.6 或 1.31.7，用 digest 固定镜像，并在 CI 中留下一项防止版本回退的检查。

如果你想讨论如何把这个流程用到你的基础设施上，可以通过联系页面写信给我们；在留言中提到这篇文章即可，不要附上凭证或敏感的配置细节。

• 申请技术审查

参考来源

来源查阅于 2026 年 10 月 23 日。在 Linux 上执行并保存了输出：对 nginx.org 的 1.30.6 软件包和 Debian 13 的 1.26.3 软件包执行 nginx -v 和 nginx -V；在测试配置上执行 nginx -T 和指令过滤；在测试清单上运行 CI 脚本；对文中的镜像执行 crane digest；用 crane 提取 nginx:1.30.6-alpine 和 node:24.22.1-alpine 镜像并查看其中的 NGINX 和 Node 版本；npm pkg set 和 npm install --engine-strict。未执行：docker run（以 crane 提取镜像代替），以及在服务器上升级和重启服务。

• nginx: security advisories
• nginx: CHANGES-1.30
• nginx: CHANGES
• nginx: 新闻
• nginx: 下载
• nginx: controlling nginx
• NVD: CVE-2026-15176
• NVD: CVE-2026-93479
• NVD: CVE-2026-95101
• NVD: CVE-2026-97629
• NVD: CVE-2026-97205
• NVD: CVE-2026-42533
• Debian security tracker: DSA-6575-1
• Docker Hub：nginx 官方镜像
• Node.js: October 21, 2026 Security Releases
• Node.js 24.22.1 (LTS)
• crane (go-containerregistry)