nginx CVE-2026-93479 与 CVE-2026-15176：在 Linux 上检查和修补
木子
|
|
|
12
|
0
|
文档

5474 字
|
29 分钟

执行 nginx -v 无法判断发行版构建的 nginx 是否已经修复 CVE-2026-93479 和 CVE-2026-15176。在 Ubuntu 26.04 上，易受攻击的软件包和修复后的软件包都显示 nginx/1.28.3，因为 Canonical 通过反向移植修复程序来打补丁，而没有把上游版本升到 1.30.6。反过来也会误判：版本字符串易受影响，不等于请求一定能够触发漏洞，两个堆溢出都要求特定的配置形态。

因此需要确认两件事：软件包是否包含修复程序，以及配置中是否包含 F5 公告描述的 map 正则或 alias + rewrite 模式。本文先检查这两项，再修补 Ubuntu、Debian 和 Amazon Linux 2023，并说明无法立即打补丁的服务器应如何修改配置来阻断攻击路径，包括尚无厂商修复程序的 RHEL 系列。以下操作于 2026 年 10 月在 Ubuntu 26.04、Ubuntu 24.04 和 Debian 13 上运行，Amazon Linux 2023 与 Rocky Linux 10 则在容器中测试。

两个漏洞都需要特定配置

F5 于 2026 年 10 月 14 日发布两份公告。上游已在 nginx 1.30.6 稳定版和 1.31.7 主线版中修复。两个问题都是 nginx worker 进程中的堆缓冲区溢出，并且只有在配置按特定顺序求值变量时才能触发。F5 描述的结果是 worker 崩溃并重启，也就是拒绝服务；只有在禁用 ASLR 或能够绕过 ASLR 的情况下，才可能导致代码执行。因此配置检查与版本检查同等重要，因为它能说明未打补丁的机器当前是否暴露于攻击路径。

按照 F5 公告 K000162607 和 K000162416 的说明，触发漏洞所需的配置形态如下：

  • CVE-2026-93479：使用正则匹配的 map，并让根目录或访问日志格式在 map 输出变量之前引用该 map 的编号捕获；另一条路径是在特定条件下把不可缓存变量放入字符串表达式。
  • CVE-2026-15176：同时使用 location、alias 和 rewrite，且 set 或 return 引用了 $request_filename；另一条路径是在 log_format 中使用 $request_filename。

两个漏洞的受影响版本范围不同。nginx.org 列出了 0.6.27 至 1.30.5 以及 1.31.0 至 1.31.6 的受影响版本，修复版本为 1.30.6 和 1.31.7。发行版可能反向移植修复，因此不能只根据版本号判断，应查看包修订记录。

各发行版的修复版本

上游在 nginx 1.30.6（稳定版）和 1.31.7（主线版）中修复了所有受影响分支。各发行版通常反向移植修复，因此需要比较的版本取决于 nginx 来自哪里。2026 年 10 月 26 日，Ubuntu 发布 USN-8955-1，Debian 为 trixie 发布 DSA-6575-1，Amazon Linux 2023 发布 ALAS2023-2026-3263 并把版本完整重定基到 1.30.6：

来源 发行版 修复版本 安全公告
nginx.org 稳定版 1.30.x 1.30.6 nginx.org、F5 K000162607 / K000162416
nginx.org 主线版 1.31.x 1.31.7 同上
Ubuntu 26.10 1.30.4-7ubuntu1.1 USN-8955-1
Ubuntu 26.04 LTS 1.28.3-2ubuntu1.12 USN-8955-1
Ubuntu 24.04 LTS 1.24.0-2ubuntu7.19 USN-8955-1
Ubuntu 22.04 LTS 1.18.0-6ubuntu14.22 USN-8955-1
Debian 13（trixie） 1.26.3-3+deb13u10 DSA-6575-1
Debian forky / sid 1.30.4-8 及更高版本 不稳定仓库更新
Debian 12（bookworm） 尚未修复 安全跟踪器标记为易受影响
Amazon Linux 2023 nginx-1.30.6-1.amzn2023.0.1 ALAS2023-2026-3263
RHEL、Rocky、AlmaLinux 8、9、10 暂无厂商修复 Red Hat 表示正在处理

同一次发布还修复了其他三个问题。CVE-2026-97205 涉及 AIO 与 SSI 的组合，CVE-2026-95101 涉及 HTTP/3，CVE-2026-97629 涉及 TLS 会话票据。下面的配置检查会同时检查这些组合，但本文重点是两个堆溢出。

版本范围也有差异。nginx.org 将 CVE-2026-15176 标记为影响 0.1.29 至 1.31.6；CVE-2026-93479 则只列在 1.30.0 至 1.30.5 和 1.31.2 至 1.31.6 中。Ubuntu 和 Debian 仍修补了 1.18 至 1.28 的软件包，因为它们已经从新版本反向移植了脚本处理代码，缺陷因此也存在于版本号范围之外的发行版构建中。判断时以发行版公告为准，不要只看上游版本范围。

第二攻击路径没有公开全部必要条件，所以通过配置检查只能说明没有发现已知触发形态，不能证明绝对安全。应优先安装补丁；配置修改是暂时无法更新软件包时的过渡措施。

关于严重程度，各方评级并不一致。nginx.org 将两个问题都列为中危，F5 的 CVSS 3.1 评分为 8.1（高危），CVSS 4.0 评分为 9.2（严重），Ubuntu 跟踪页面也采用 9.2。截至 2026 年 10 月 26 日，两个 CVE 均未进入 CISA 已知被利用漏洞目录；FIRST 的 EPSS 模型估计未来 30 天内被利用的概率，CVE-2026-93479 约为 1.0%，CVE-2026-15176 约为 0.8%，尚无公开利用报告。因此通常可按正常维护窗口修补，除非配置符合上述触发形态且服务直接暴露于互联网。

包修订记录能证明补丁是否存在

不要只查询二进制版本，应询问软件包管理器。nginx -v 显示上游基础版本，而 Ubuntu 和 Debian 会在整个发行版生命周期内保留该版本号，所以安全更新前后可能完全相同。真正变化的是 Debian 修订号，例如 ubuntu1.12 或 +deb13u10；CVE 编号则记录在软件包变更日志中。Debian 的 nginx 位于 /usr/sbin，普通用户 PATH 中可能找不到，因此使用 sudo。

以下检查不会改动服务器：

sudo nginx -v
dpkg-query -W -f='${Package} ${Version}\n' 'nginx*' 'libnginx-mod*' 2>/dev/null
apt list --upgradable 2>/dev/null | grep -i nginx
zgrep -c -E 'CVE-2026-(93479|15176)' /usr/share/doc/nginx-common/changelog.Debian.gz

更新前的 Ubuntu 26.04 测试服务器显示：二进制为 1.28.3，安装包为发行版仓库原有的 1.28.3-2ubuntu1，APT 提供来自 resolute-security 的 1.28.3-2ubuntu1.12，变更日志中没有任何相关 CVE：

nginx version: nginx/1.28.3 (Ubuntu)
nginx 1.28.3-2ubuntu1
nginx-abi-1.28.3-1
nginx-common 1.28.3-2ubuntu1
nginx-core
nginx-doc
nginx-extras
nginx-light
nginx-common/resolute-updates,resolute-security 1.28.3-2ubuntu1.12 all [upgradable from: 1.28.3-2ubuntu1]
nginx/resolute-updates,resolute-security 1.28.3-2ubuntu1.12 amd64 [upgradable from: 1.28.3-2ubuntu1]
0

从最后一行往前看：变更日志匹配数为 0，apt list --upgradable 仍列出 nginx，或已安装修订低于上表中的修复版本，都说明软件包侧仍处于风险状态。nginx-core、nginx-light 等空条目只是通配符匹配到的虚拟包或未安装包，可以忽略。Ubuntu 24.04 和 Debian 13 在测试中的情况相同，分别安装 1.24.0-2ubuntu7 和 1.26.3-3+deb13u7，等待修复修订。

Ubuntu 还提供能识别 CVE 的 pro fix 助手。对于 main 仓库中的软件包，不需要 Ubuntu Pro 订阅；--dry-run 不会修改系统：

pro fix CVE-2026-93479 --dry-run

它会列出受影响的源码包，并打印将执行的 APT 命令。若系统中没有该工具，也可继续使用上面的软件包版本和变更日志检查。

用 nginx -T 检查实际加载的配置

不要直接 grep /etc/nginx，因为这样会漏掉从其他路径 include 的文件，也会检查永远不会加载的禁用站点。应搜索 nginx 实际解析的完整配置。nginx -T 会在每个已加载文件前打印 # configuration file，可用 awk 把文件名带到每条匹配之前。

模式中使用 [[:space:]] 而不是 \s。Debian 默认的 awk 是 mawk，它会把 \s 当作匹配不到任何内容的表达式，导致假阴性。以下命令在 Ubuntu 的 gawk 上也可直接使用。

按顺序执行四项检查，每项对应公告中的一组条件：

  1. alias、rewrite 和 $request_filename（CVE-2026-15176）
  2. map 块中的正则行（CVE-2026-93479）
  3. 使用 $1 这类编号捕获的 root 或日志行（CVE-2026-93479）
  4. aio、ssi、TLS 会话缓存与票据密钥，以及 QUIC 监听（三个伴随 CVE）
sudo nginx -T 2>/dev/null | awk \
  '/^# configuration file /{f=$4} /^[[:space:]]*(alias|rewrite)[[:space:]]|\$request_filename/{print f, $0}'

sudo nginx -T 2>/dev/null | awk \
  '/^# configuration file /{f=$4} /^[[:space:]]*map[[:space:]]/{m=1} m && /^[[:space:]]*~/{print f, $0} m && /^[[:space:]]*}/{m=0}'

sudo nginx -T 2>/dev/null | awk \
  '/^# configuration file /{f=$4} /^[[:space:]]*(root|log_format|access_log)[[:space:]].*\$[1-9]/{print f, $0}'

sudo nginx -T 2>/dev/null | awk \
  '/^# configuration file /{f=$4} /^[[:space:]]*(aio|ssi|ssl_session_cache|ssl_session_ticket_key)[[:space:]]|listen.*quic/{print f, $0}'

测试服务器准备了两个符合公告描述的文件，并为第四项检查加入一条共享 TLS 会话缓存配置。Debian 13 的输出如下，Ubuntu 26.04 的输出相同：

/etc/nginx/conf.d/cve-lab.conf:         alias /srv/files/;
/etc/nginx/conf.d/cve-lab.conf:         rewrite ^/files/old/(.*)$ /files/$1 break;
/etc/nginx/conf.d/cve-lab2.conf: log_format fileaudit '$remote_addr $status "$request_filename"';
/etc/nginx/conf.d/cve-lab2.conf:         alias /srv/files/;
/etc/nginx/conf.d/cve-lab2.conf:         rewrite ^/dl/v1/(.*)$ /dl/$1 break;
/etc/nginx/conf.d/cve-lab2.conf:         set $served_file $request_filename;
/etc/nginx/conf.d/cve-lab.conf:     ~^/assets/(?<asset_name>.+)$ $asset_name;
/etc/nginx/conf.d/cve-lab2.conf:     ~^/thumbs/(.+)\.jpg$ $1;
/etc/nginx/conf.d/cve-lab2.conf:         root /srv/thumbs/$1;
/etc/nginx/conf.d/cve-lab.conf:     aio off;
/etc/nginx/conf.d/cve-lab.conf:     ssl_session_cache shared:SSL:10m;

其中 cve-lab2.conf 最需要关注：/dl/ location 同时使用 alias、rewrite，并通过 set 读取 $request_filename，正好符合 CVE-2026-15176；其 log_format 也使用该变量。此外，它的 map 正则使用未命名捕获，root 又直接使用 $1，没有引用 map 的输出变量，符合 CVE-2026-93479。cve-lab.conf 则展示相反情况：有 alias 和 rewrite 但没有 $request_filename，map 使用命名捕获，并且关闭了 AIO；其 ssl_session_cache shared 旁边没有 ssl_session_ticket_key，对应 CVE-2026-97629 的组合。

检查结果应作为审查清单，而不是最终结论。单独的 alias 很常见，也不构成这两个问题；map 正则只有捕获值泄漏到 map 块外时才值得关注。真正危险的是同一个 location 或变量链中的组合。如果四项检查都没有输出，说明配置未包含公告公开的触发形态，但这只争取了处理时间，并不等于免疫，因为 F5 尚未完整定义不可缓存变量路径。

用 apt 修补 Ubuntu 和 Debian

Ubuntu 26.04、24.04、22.04 和 Debian 13 的修复都通过正常安全仓库提供，只需定向升级 nginx 软件包。--only-upgrade 防止在未安装 nginx 的机器上误装，适合批量下发命令。如果前一步 dpkg-query 列出 libnginx-mod-*，应把它们加入同一命令，确保同源码构建的软件包一起更新：

sudo apt-get update && sudo apt-get install --only-upgrade -y nginx nginx-common

Debian 13 测试服务器从 trixie-security 拉取两个软件包，应关注以下输出：

The following packages will be upgraded:
  nginx nginx-common
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 725 kB of archives.
After this operation, 6144 B of additional disk space will be used.
Get:2 https://deb.debian.org/debian-security trixie-security/main amd64 nginx amd64 1.26.3-3+deb13u10 [614 kB]
Get:3 https://deb.debian.org/debian-security trixie-security/main amd64 nginx-common all 1.26.3-3+deb13u10 [112 kB]
Unpacking nginx (1.26.3-3+deb13u10) over (1.26.3-3+deb13u7) ...
Unpacking nginx-common (1.26.3-3+deb13u10) over (1.26.3-3+deb13u7) ...
Setting up nginx-common (1.26.3-3+deb13u10) ...
Setting up nginx (1.26.3-3+deb13u10) ...
Upgrading binary: nginx.

升级后不一定需要再手动重启 nginx。Upgrading binary 表明安装脚本已经启动新二进制并接管监听套接字。可以通过 master 进程 PID 变化确认旧代码不再运行：测试中的 Ubuntu 26.04 从 29278 变为 30333，Ubuntu 24.04 从 2042 变为 3177，Debian 13 从 15873 变为 16469，测试站点的 403 响应保持不变。如果 master 仍使用更新前的启动时间，即使 dpkg 显示新版本，服务器仍可能运行旧代码。

一次确认三件事：软件包修订、变更日志中的 CVE 条目，以及更新后启动的 master 进程：

dpkg-query -W -f='${Package} ${Version}\n' nginx nginx-common
zgrep -E 'CVE-2026-(93479|15176|97205|95101|97629)' /usr/share/doc/nginx-common/changelog.Debian.gz
ps -o pid,lstart,cmd -C nginx | head -2
sudo nginx -t

Ubuntu 26.04 更新后的输出中，五个 CVE 都以独立补丁列出，master 进程在 apt 执行时启动：

nginx 1.28.3-2ubuntu1.12
nginx-common 1.28.3-2ubuntu1.12
    - debian/patches/CVE-2026-15176.patch: Avoid post-rewrite URI to path
    - CVE-2026-15176
    - debian/patches/CVE-2026-93479.patch: Script: reserved memory overrun
    - CVE-2026-93479
    - debian/patches/CVE-2026-95101.patch: HTTP/3: kept the skipped frame length
    - CVE-2026-95101
    - debian/patches/CVE-2026-97205.patch: Limited the number of pending
    - CVE-2026-97205
    - debian/patches/CVE-2026-97629.patch: SSL: synced all session ticket keys
    - CVE-2026-97629
    PID                  STARTED CMD
  30333 Tue Oct 27 01:34:39 2026 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Ubuntu 24.04 的变更日志列出其中四个，没有 CVE-2026-95101。这不是漏修补，而是在 USN-8955-1 中 HTTP/3 问题只影响 26.04 和 26.10。Debian 13 列出全部五个，并注明均从上游 1.30.6 反向移植。

图1

Amazon Linux 2023 需要更新的仓库快照

Amazon Linux 2023 把实例固定到带日期的仓库快照。修复发布后，除非将仓库指向更新快照，否则 dnf 看不到修复。测试容器运行 2023.12.20261021 快照和 nginx 1.30.5，即使 ALAS2023-2026-3263 已发布数日，普通安全公告查询仍为空。这个空结果容易误读成“不受影响”，实际含义是“当前快照尚不可见”：

cat /etc/amazon-linux-release
rpm -q nginx
sudo dnf updateinfo list --cve CVE-2026-93479 --releasever 2023.12.20261026

显式指定公告发布的版本标签后，可以看到三个待更新软件包：

Amazon Linux release 2023.12.20261021 (Amazon Linux)
nginx-1.30.5-1.amzn2023.0.1.x86_64
ALAS2023-2026-3263 Medium/Sec. nginx-1:1.30.6-1.amzn2023.0.1.x86_64
ALAS2023-2026-3263 Medium/Sec. nginx-core-1:1.30.6-1.amzn2023.0.1.x86_64
ALAS2023-2026-3263 Medium/Sec. nginx-filesystem-1:1.30.6-1.amzn2023.0.1.noarch

Amazon 将整个更新包标为中危，dnf updateinfo info ALAS2023-2026-3263 会列出五个 CVE。只应用该公告，可以让实例其余软件包继续使用当前快照：

sudo dnf update -y --advisory ALAS2023-2026-3263 --releasever 2023.12.20261026

三个软件包都升级到 1.30.6-1.amzn2023.0.1；Amazon 采用重定基而不是反向移植，因此二进制直接报告上游修复版本：

Upgraded:
  nginx-1:1.30.6-1.amzn2023.0.1.x86_64
  nginx-core-1:1.30.6-1.amzn2023.0.1.x86_64
  nginx-filesystem-1:1.30.6-1.amzn2023.0.1.noarch

Complete!
nginx-1.30.6-1.amzn2023.0.1.x86_64
nginx version: nginx/1.30.6

Amazon 软件包的升级脚本会在升级时调用 /usr/bin/nginx-upgrade，实现类似 Debian 的二进制文件替换。测试环境没有 systemd，无法核对 master 启动时间；在真实实例中应运行 ps -o pid,lstart,cmd -C nginx，如果进程启动时间早于更新，就执行 sudo systemctl restart nginx。

RHEL 克隆和 Debian 12 仍在等待修复

Red Hat 将 RHEL 8、9、10 列为受 CVE-2026-15176 影响，状态为“正在寻求修复”，截至 2026 年 10 月 27 日没有 RHSA，因此 Rocky Linux 和 AlmaLinux 暂时没有可重建的厂商补丁。Rocky Linux 10.2 的 AppStream 仍提供 nginx-2:1.26.3-6.el10_2.7。Debian 12 同样如此，安全跟踪器将 bookworm 的 1.22.1-9+deb12u10 标记为受两个 CVE 影响，而 DSA-6575-1 只覆盖 trixie。此时有两种选择：

  • 应用下一节的配置缓解措施，并等待厂商软件包
  • 切换到 nginx.org 官方软件包，其版本已达到 1.30.6

切换到官方仓库是一次较大的变更。nginx.org 构建采用不同文件布局，自带 conf.d/default.conf，并使系统离开 Red Hat 的更新链路。普通 dnf upgrade nginx 会因 AppStream 把文件拆分到 nginx-core 而发生冲突：

Error: Transaction test error:
  file /etc/logrotate.d/nginx from install of nginx-2:1.30.6-1.el10.ngx.x86_64 conflicts with file from package nginx-core-2:1.26.3-6.el10_2.7.x86_64
  file /etc/nginx/nginx.conf from install of nginx-2:1.30.6-1.el10.ngx.x86_64 conflicts with file from package nginx-core-2:1.26.3-6.el10_2.7.x86_64
  file /usr/sbin/nginx from install of nginx-2:1.30.6-1.el10.ngx.x86_64 conflicts with file from package nginx-core-2:1.26.3-6.el10_2.7.x86_64
  file /var/log/nginx from install of nginx-2:1.30.6-1.el10.ngx.x86_64 conflicts with file from package nginx-core-2:1.26.3-6.el10_2.7.x86_64

测试中加 --allowerasing 也失败，因为 dnf 仍保留同文件的 nginx-core。应先移除 AppStream 软件包，再安装官方仓库版本。在 Rocky Linux 10 上通常是三个包；8 和 9 的 nginx 来自模块流，可能还包含 nginx-mod-* 或 nginx-all-modules，所以先执行 rpm -qa 'nginx*' 查看并移除。切换前确认每个已加载动态模块都有 nginx.org 对应包。两条命令之间 nginx 会短暂停机，应在维护窗口或负载均衡器后方执行：

sudo dnf -y remove nginx nginx-core nginx-filesystem
sudo dnf -y install nginx

验证配置后可恢复保存的主配置。接入第三方仓库前应核对官方签名密钥和仓库定义，不应直接使用未经核实的 URL：

sudo cp /etc/nginx/nginx.conf.rpmsave /etc/nginx/nginx.conf
sudo nginx -t
nginx -v

切换到官方仓库后还应检查 sudo systemctl enable --now nginx，并在 SELinux 强制模式下查看 sudo ausearch -m avc -ts recent。如果自己的 server 块已经占用 80 端口，应删除 /etc/nginx/conf.d/default.conf。Debian 12 也可以使用 nginx.org 的 bookworm 仓库，但本文测试环境没有覆盖该路径，因此 Debian 12 的已验证过渡方案仍是配置修改。

配置修改可阻断公开攻击路径

每份公告都给出了对应的临时处理方式，重点是消除触发形态，而不是禁用整个模块。对 CVE-2026-93479，F5 K000162607 建议停止使用未命名捕获，改为限定在 map 正则块内的命名捕获。对 CVE-2026-15176，K000162416 建议避免在 location 中使用 alias，避免 $request_filename 变量。对 AIO 释放后使用问题，K000162608 建议关闭 AIO 或 SSI。按改动幅度排序：

  1. 在 map 中使用命名捕获，只读取 map 的输出变量
  2. 用 $document_root$uri 替代 $request_filename
  3. 用 root 加剥离前缀的 rewrite 替代 alias
  4. 同时启用时使用 aio off 或 ssi off

测试文件 cve-lab2.conf 同时包含全部触发条件，可以用来验证重写后是否仍提供相同 URL。编辑检测步骤标出的文件：

sudo vim /etc/nginx/conf.d/cve-lab2.conf

下面是 Ubuntu 26.04 测试服务器运行的完整改写配置。map 的捕获进入命名组 $thumb，只有 map 输出变量 $thumb_name 离开块，因此 map 外部不会读取正则捕获。日志格式使用 $document_root$uri，/thumbs/ 使用固定 root，/dl/ 则用 root 加两条 rewrite 替代 alias：

map $uri $thumb_name {
    ~^/thumbs/(?<thumb>.+)\.jpg$ $thumb;
    default "";
}

log_format fileaudit '$remote_addr $status "$document_root$uri" thumb=$thumb_name';

server {
    listen 8081;
    server_name files.example.com;
    access_log /var/log/nginx/files.log fileaudit;

    location /thumbs/ {
        root /srv;
    }

    location /dl/ {
        root /srv/files;
        rewrite ^/dl/v1/(.*)$ /dl/$1;
        rewrite ^/dl/(.*)$ /$1 break;
    }
}

第一条 rewrite 没有 flag，所以 /dl/v1/ 请求会继续进入第二条，剥离 /dl/ 后终止。两种 URL 最终都会访问 /srv/files 下的同一文件，达到原 alias 的效果。测试、重载后请求三个路径：

sudo nginx -t && sudo systemctl reload nginx

for u in /dl/report.txt /dl/v1/report.txt /thumbs/cat.jpg; do
  curl -s -o /dev/null -w "%{http_code} %{size_download}\n" "http://127.0.0.1:8081$u"
done

sudo tail -n 3 /var/log/nginx/files.log

测试中对三个 URL 分别得到 200 与一致的 12 字节响应，日志中显示 thumb= 为空或 thumb=cat，与修改前的行为一致。测试服务器还确认，日志中的路径由 $document_root$uri 组成，没有直接暴露旧的 $request_filename 表达式。

Error: “alias” cannot be used in location “/dl/” where URI was rewritten

把 alias 改为 root + rewrite 时，常见错误是仍保留原来的 URI 重写：

nginx: [emerg] "alias" cannot be used in location "/dl/" where URI was rewritten

这表示同一 location 内 alias 与重写规则发生冲突。应根据实际目录结构选择一种路由方式，不要同时保留两套。修改后先执行 sudo nginx -t，通过后再重载。

在启用 SSI 时关闭 AIO

若站点启用了 SSI，又配置了 aio，应核查该组合是否属于公告中的第二条路径。关闭 AIO 可能影响大文件传输性能，因此应在测试环境比较吞吐与延迟，并只对命中的 server 或 location 做最小调整，不要全局关闭所有站点的 AIO。

两个 CVE 的速查表

排查一组服务器时，可用下表逐项核对：何种配置会暴露服务、不能打补丁时如何修改、是否只能通过升级解决。触发形态来自 F5 和 Amazon 公告；这五个问题的上游修复均为 nginx 1.30.6 或 1.31.7：

CVE 暴露条件 无法升级时的修改
CVE-2026-93479 map 正则中的编号捕获被 root 或日志格式使用 改用命名捕获，并且只读取 map 输出变量
CVE-2026-15176 alias + rewrite + 使用 $request_filename 的 set/return，或日志格式中的该变量 用 root 替代 alias，用 $document_root$uri 替代 $request_filename
CVE-2026-97205 开启 aio，且 SSI 页面使用 include virtual 关闭 aio 或 ssi
CVE-2026-95101 HTTP/3 监听器并使用 proxy_request_buffering on 升级
CVE-2026-97629 使用共享 SSL 会话缓存但没有 ssl_session_ticket_key 文件 升级

F5 还列出 NGINX Plus、NGINX Ingress Controller 和 NGINX Gateway Fabric 受影响，它们各有独立修复构建。这些产品在镜像中自带 nginx，修补宿主机操作系统不会影响它们，需要更新对应 Helm chart 或镜像。社区版 ingress-nginx 不在 F5 的表中，应单独查看项目发布说明，不能默认其安全或受影响。

升级完成后，用同样的 nginx -T 快照再次核验配置是否被意外改变。nginx -v 版本号不变并不代表没有修复，真正可靠的是包修订、变更日志和已启动的新 master 进程。

包修订记录能证明补丁是否存在

nginx -v 只显示上游版本，Ubuntu 和 Debian 都可保留上游版本号而提高包修订号。用 dpkg-query 查看完整版本和变更日志：

dpkg-query -W -f='${Package} ${Version}\n' nginx
apt changelog nginx | head -40

修复包会在变更日志中出现 CVE 编号，或显示发行版自己的安全更新编号。先前易受攻击的 Ubuntu 26.04 包显示版本 1.28.3-1ubuntu1，修复后的包显示版本 1.28.3-1ubuntu1.1。修订号增加但变更日志没有 CVE 证据时，不能据此认定已经修复。

RPM 系统可使用：

rpm -q nginx
dnf info --changelog nginx | head -60

对 Amazon Linux 2023，再确认实际安装版本：

rpm -q nginx

修复包安装后需要重新加载服务。先验证配置再加载，避免把配置语法问题带入生产环境：

sudo nginx -t
sudo systemctl reload nginx

若 nginx -t 失败，不要重载。修复二进制文件本身不会改变运行中的 worker，只有启动新 worker 后才使用新代码。

用 nginx -T 检查配置是否命中攻击面

nginx -T 会输出完整配置，包括 include 文件。先保存一份快照，再搜索公告描述的模式：

sudo nginx -T > /tmp/nginx-config.txt 2>&1
grep -nE 'map[[:space:]]+[^;]+[[:space:]]+\\\$' /tmp/nginx-config.txt
grep -nE '(alias|rewrite|log_format|\\$request_filename)' /tmp/nginx-config.txt

真正需要关注的是组合条件，单独出现某个指令并不等于可利用。例如，使用了 alias 但没有 rewrite，或日志格式没有 $request_filename，都不符合公告描述的攻击路径。若存在组合，应先升级，再评估配置。

还可以检查配置中是否存在用编号捕获构造 log_format 的写法：

grep -nE '\\$[0-9]' /tmp/nginx-config.txt

不要为了通过检查而盲目删除 alias 或日志变量，这会破坏站点路由和审计。先保留快照，修改后在测试环境用 nginx -t 检查，再小范围重载。

Avatar photo

关于 木子

Email: muzi@vip.rockylinux.cn 微信：VebinLee QQ: 2306867585
Founder of the Rocky Linux Chinese community, MVP、VMware vExpert、TVP, advocate for cloud native technologies, with over ten years of experience in site reliability engineering (SRE) and the DevOps field. Passionate about Cloud Computing、Microservices、CI&CD、DevOps、Kubernetes, currently dedicated to promoting and implementing Rocky Linux in Chinese-speaking regions.
查看 木子 所有文章 | 网站
版权声明:「自由转载-保持署名-非商业性使用-禁止演绎 3.0 国际」（CC BY-NC-ND 3.0）
用一杯咖啡支持我们，我们的每一篇[文档]都经过实际操作和精心打磨，而不是简单地从网上复制粘贴。期间投入了大量心血，只为能够真正帮助到您。
DebianNginxRHELUbuntu安全漏洞
暂无评论

发送评论 编辑评论 


				

			

						

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
						

					

				

				

					

						

							

								
							

							
							
													

					

				

			

			
			

				

					
				

			

				

											

							
							
						

																

							
							
						

																

							
							
						

										
					
											
						

	

		
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
（╯‵□′）╯︵┴─┴
￣﹃￣
(/ω＼)
∠( ᐛ 」∠)＿
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ｀)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ(￣∇￣o)
ヾ(´･ ･｀｡)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò｡)
Σ(っ °Д °;)っ
( ,,´･ω･)ﾉ"(´っω･｀｡)
╮(╯▽╰)╭
o(*////▽////*)q
＞﹏＜
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
	

	

		
颜文字
Emoji
小恐龙
花!
	


									

			

			
		

	






上一篇

                    

                    
			        推荐文章
		            

		            

							
在 Rocky、Debian 和 Arch Linux 上将 OpenCode 升级到 v2

							
							

							
在 Fedora 45 / 44 上安装 CUDA 与 NVIDIA 容器工具链

							
							

							
在 Ubuntu 26.04 上安装 KVM：从环境准备到创建虚拟机

							
							

							
Nginx功能篇24—后端备份服务器

							
							

							
Nginx功能篇23—主动健康检查

							
							

							
Nginx功能篇22—负载规则

							
							

							
Nginx功能篇21—代理缓冲

							
							

							
Nginx功能篇20—代理服务

							
							

							
Nginx功能篇19—代理缓存

							
							

							
Nginx功能篇18—流媒体服务