--- title: "NGINX 高危漏洞成因与修复指南" description: "梳理 2026 年 10 月 NGINX 五项漏洞的触发条件、分支修复版本、发行版回补、临时措施与线上验收。" language: "zh-Hans" url: "https://keendigit.com/zh/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX 高危漏洞成因与修复指南 梳理 2026 年 10 月 NGINX 五项漏洞的触发条件、分支修复版本、发行版回补、临时措施与线上验收。 历史文章日期：2026-10-14（本批漏洞公开及修复日期）。资料核验与补充截至：2026-10-27。 本文按事件日期归档；下文包含 10 月 14 日之后发布的版本与发行版更新信息。\ 适用对象：NGINX Open Source / NGINX Plus 的网站与反向代理运维人员、安全响应人员、发行版维护者，以及自编译 NGINX 和维护第三方模块的工程师。 本文聚焦 2026 年 10 月 14 日公开并集中修复的五项 NGINX 核心漏洞，同时回溯 2026 年 5—9 月具有代表性的内存安全与请求完整性漏洞。内容覆盖触发条件、代码层成因、影响范围、正式修复流程、短期缓解措施、官方补丁实现、旧分支回补及上线验收。正文采用 [S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1) 等编号引用，全部参考链接集中列在文末附录。示例配置仅用于说明部署与审计思路，应根据实际版本、配置继承、依赖及业务容量验证后再实施。 ## TL;DR：修复步骤与建议 1. 优先完成安全升级：使用 nginx.org 官方 Open Source 包的，Stable 1.30 分支至少升级到 1.30.6；Mainline 1.31 分支至少升级到 1.31.7，截至核验日建议直接使用最新 1.31.8。这是两个独立的修复门槛，不能单纯按数字大小跨分支比较。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh/insights/nginx-remediation-guide#source-2) 2. 发行版安装按完整软件包版本验收：Ubuntu 22.04 / 24.04 / 26.04 / 26.10 已有厂商回补；Debian 13（trixie）至少使用 `1.26.3-3+deb13u10`。Debian 12（bookworm）在核验时的安全跟踪记录仍将 `1.22.1-9+deb12u10` 标为受影响，必须逐 CVE 查看最新状态，不能据 Debian 13 的公告认定 Debian 12 已修复。[S13](https://keendigit.com/zh/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/zh/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/zh/insights/nginx-remediation-guide#source-15) 3. 立即审计五类配置组合：`alias + rewrite + $request_filename`、`map` + regex + 变量求值、`aio + ssi + include virtual`、HTTP/3 + `proxy_request_buffering on`、以及 `ssl_session_cache shared:...` + 自动 TLS Session Ticket 密钥轮换。是否存在指令不等于漏洞必然可利用；必须结合请求路径与配置作用域判断。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) 4. 替换全部旧进程与容器：完成 `nginx -t`、服务重启或高可用滚动部署，检查旧 master/worker 是否彻底退出；仅执行 `nginx -s reload` 不能证明线上已切换到更新后的二进制。 5. 针对风险验证真实入口：检查 HTTP/1.1、HTTP/2、HTTP/3（若启用）、反向代理上传及 API 请求体、mTLS 证书认证、SSI 页面和访问日志。记录每个实际入口的软件包来源、版本、镜像摘要、运行中进程及验证结果。 6. 暂不能升级时先移除触发条件：禁用不必要的 SSI/AIO 或 HTTP/3，重构脆弱的 `alias`/`rewrite`/`map` 变量引用；涉及 mTLS 的实例可评估临时 `ssl_session_tickets off;`。WAF、ASLR、限流和移除高风险指令只覆盖部分攻击条件，不能替代正式补丁。[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/zh/insights/nginx-remediation-guide#source-12) ## 1. 漏洞概览与风险判断 NGINX 于 2026 年 10 月 14 日发布 1.30.6（Stable）与 1.31.7（Mainline），同时修复五项安全问题。其中三项为堆溢出或释放后使用，F5 在 CVSS v4.0 标准下为其分别打出 9.2 / Critical；另外两项涉及 HTTP/3 请求完整性和 TLS 客户端证书认证边界。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3) 评级差异需要明确区分：nginx.org 官方安全列表将本批五项全部标为 `medium`，而 F5 的 CVSS v4.0 与部分国家级安全机构将三项内存问题列为 Critical。这不是五项漏洞都可以无条件远程执行代码；真实攻击还受到 NGINX 配置、流量可达性及某些不可由攻击者控制的条件约束。可利用内存破坏与稳定可靠的 RCE 是不同证据层级。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) | CVE | 技术问题与典型触发条件 | 核心影响 | 评价与处置 | | -------------- | -------------------------------------------------------- | ------------------------------------------- | ----------------------------- | | CVE-2026-15176 | `alias` 路径映射 + `rewrite` 改变 URI + 求值 `$request_filename` | 堆缓冲区溢出，Worker 崩溃；特定条件下潜在 RCE | F5 CVSS v4.0 9.2；优先排查 | | CVE-2026-93479 | HTTP/Stream 脚本求值，特别是 `map` 正则捕获与根目录、日志变量交叉引用 | 预留缓冲区被覆盖，堆溢出；特定条件下潜在 RCE | F5 CVSS v4.0 9.2；属于先前修复后的回归风险 | | CVE-2026-97205 | SSI 虚拟包含与 AIO/异步操作；未完成操作计数溢出 | Use-After-Free，Worker 崩溃、内存破坏；潜在 RCE | F5 CVSS v4.0 9.2；需要非默认配置 | | CVE-2026-95101 | HTTP/3 未知帧跨缓冲区分片，代理请求体缓冲开启 | 错将非 DATA 字节注入上游请求体，可能绕过请求体大小限制 | 此漏洞影响请求完整性。它本身不提供远程代码执行（RCE）。 | | CVE-2026-97629 | 共享 TLS Session Cache、自动密钥轮换与 Worker 密钥镜像 | Session Ticket 伪造；受影响的 mTLS 服务可能发生客户端证书认证绕过 | 对证书认证型 API 的业务影响尤需关注 | 上述 CVSS 分数由 F5 采用 v4.0 给出；同一漏洞在 CVSS 3.1、nginx.org 自有等级与发行版评分中可能显示不同的严重性。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) ### 1.1 风险应按业务部署而不是按 CVE 分数机械排序 | 部署形态 | 重点排查点 | 处置优先级建议 | | -------------------------------------- | ------------------------------------------------------ | -------------- | | 公网反向代理，有自定义 `rewrite`、`alias`、复杂 `map` | CVE-2026-15176、CVE-2026-93479 以及 5—7 月的 rewrite/map 漏洞 | P0：立即审计并更新 | | 以客户端证书作为唯一或主要入口鉴权的 API / 管理面 | CVE-2026-97629 的 Session Ticket 与共享缓存配置 | P0：立即确认认证边界及更新 | | 对外提供 HTTP/3 上传、状态变更接口、交易类 API | CVE-2026-95101，尤其是请求体被代理到后端 | P0/P1：按业务重要性安排 | | SSI 动态页面或异步文件 I/O | CVE-2026-97205 | P1：确认组合条件，尽快修复 | | 仅静态页面 + 简单 HTTP/1.1/2 反向代理 | 仍需审计配置和版本，但部分 CVE 条件可能缺失 | P1：列入紧急安全升级窗口 | | 使用已退役 Kubernetes 社区 ingress-nginx | 项目停止安全维护，风险不局限于这五项 CVE | 单独制定控制器迁移计划 | P0/P1 是本文面向公网暴露程度和认证敏感性给出的运维处置建议，不是官方 CVSS 分级，也不应替代企业内部资产与变更风险评估。 ### 1.2 影响边界与攻击权限 本批核心漏洞主要处于 NGINX Data Plane：攻击入口是客户端连接与请求、实际影响通常发生在 Worker 进程。若满足内存破坏的可利用条件，代码执行权限一般受到该 Worker 的运行用户、容器约束、Linux capability、挂载及网络权限限制；潜在 RCE 不自动等于 root 或宿主机接管。[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) 但即便进程非特权，仍可能接触代理凭据、证书私钥所在可读文件、上游服务令牌、临时文件、内部 API 及可达网络。对 mTLS 而言，认证绕过本身可能就是严重业务后果，不必同时具备代码执行。 ## 2. 成因分析 ### 2.1 理解 NGINX 中三个容易出错的边界 NGINX Worker 是常驻的事件驱动进程，维护请求状态、异步操作及协议解析器。此次漏洞集中体现出三个工程层面的约束： 1. 变量求值与内存尺寸必须一致：`rewrite` 改变请求 URI 后，路径映射必须与当前有效 `location` 一致；脚本解释器计算变量长度时，写入空间必须覆盖实际输出及保留区。 2. 异步操作必须延长请求内存的生命周期：有未完成的文件读写、缓存等待或线程任务时，不能把相关请求内存池提前释放。 3. 协议状态与安全状态不能混用或遗漏：HTTP/3 未知帧跳过的长度不能被当作 DATA 请求体长度；TLS Session Ticket 轮换时所有参与验签的密钥槽位必须正确初始化、同步。 以下内容以 NGINX 上游修复提交与厂商公告为依据，解释可触发的失败机制；示例片段用于分析，不是可直接用于修复生产环境的完整代码。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176：`alias` 与重写 URI 的路径映射失效 在 NGINX 中，`location` 匹配与 `alias` 决定实际文件路径；`rewrite` 则可能修改当前请求 URI。一旦 URI 已被改写，原来用于匹配的 `location` 路径映射假设可能不再成立。 受影响的处理路径在 `ngx_http_map_uri_to_path()` 中检查 `alias` 状态时，没有充分检查请求是否已经被重写。当配置在改写后继续求值 `$request_filename`，可能以不符合当前 URI 状态的假设构建路径，最终触发堆内存越界写入。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5) 典型组合（仅作为配置审计反例，不建议部署）： ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` 危险并不局限于 `return`：`set`、`if`、`add_header`、`log_format` 等若在相同请求流程中触发 `$request_filename` 求值，也需要审计。示例中的 `return` 仅让这一状态路径容易看清，不能用它推断所有生产配置都会产生溢出。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/zh/insights/nginx-remediation-guide#source-10) 攻击后果：构造请求可能造成 Worker 重启或服务中断；在 ASLR 被关闭或可被绕过等条件下，存在潜在 RCE。上游补丁的核心是拒绝在不再有效的 `alias` 上下文中完成重写后的 URI 路径映射，而不是简单扩大某个缓冲区。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/zh/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479：脚本求值中“预留空间”与真实变量长度错配 NGINX 的 HTTP 和 Stream 模块都有将字面字符串和变量值拼接成结果字符串的脚本求值器。应用示例包括 HTTP 文档根路径、访问日志路径，以及 Stream 中的变量表达式。 某些 `map` + 正则表达式的配置允许捕获值在 `map` 结果变量求值之前被其他表达式读取。结合带有预留长度的脚本执行方式，旧实现会把 `len` 预留空间提前计入求值的长度累加器，使后续写入指针计算与缓冲区边界不再一致。在特定变量求值序列中，后续字符串写入可能覆盖预留区域，造成堆溢出。[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6) | 参与元素 | 为什么值得关注 | | --------------------- | ----------------------------------------------- | | `map` 中的 regex | 捕获变量求值可能有独立的生命周期与缓存行为 | | `$1`、`$2` 等匿名捕获 | 易被其他正则或表达式覆盖，难以追踪所有权 | | `root` 中的变量 | 触发路径构建时的脚本执行和缓冲区预留 | | `log_format` / 动态日志路径 | 在请求后期可能触发相同类型的求值 | | `stream` 中的脚本表达式 | 上游修复同时修改 `ngx_stream_script_run()`，不能只审 HTTP 模块 | 重要的回归关系：该漏洞相关代码与此前修复 CVE-2026-42533 的改动有关。Debian 13 的官方 DSA 明确指出，受影响的代码是通过较早的安全回补引入 trixie 包的。因此，“已安装 7 月 `map` 漏洞补丁”并不等于已经覆盖 10 月的 CVE-2026-93479；应检查完整安全修复链。[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/zh/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/zh/insights/nginx-remediation-guide#source-17) 这里的潜在 RCE 风险与内存保护环境有关，不应宣称仅含 `map` 正则就一定能够被匿名攻击者利用。[S11](https://keendigit.com/zh/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205：AIO 未完成操作计数回绕造成 Use-After-Free 本漏洞不是简单的“开启 SSI 就有 UAF”，关键在于主请求所持有的异步操作引用计数。 NGINX 使用 `r->main->blocked` 跟踪尚未结束的异步处理，旧实现中它是 8 位计数；某些路径没有在增加计数之前进行上限检查。当同一主请求累计 256 个未完成操作时，计数可能从 255 回绕到 0。后续流程会错误地认为没有阻止请求释放的异步操作，从而释放仍被任务引用的请求内存池。[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7) 失败过程可分为： 1. 启用了相关异步 I/O/线程路径，SSI 页面通过 `include virtual` 引入多个子请求或读取操作。 2. 某一主请求的未完成操作累加到计数字段的表示上限。 3. 8 位计数回绕，错误地表示为“没有挂起操作”。 4. 请求内存池被释放，而文件读取、缓存等待或线程任务的回调仍保留其中的引用。 5. 后续异步完成回调访问已释放的内存，产生 UAF、Worker 崩溃或潜在内存破坏。 官方修复在请求头文件加入 `NGX_HTTP_MAX_BLOCKED 250`，并在输出过滤器、缓存读取与上游线程路径加入限制；达到阈值时，有同步路径的操作改为同步完成，不能安全处理的则拒绝继续增加挂起任务。[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7) 适用性判断：必须评估 SSI、AIO、虚拟包含、子请求及相关异步操作能否在同一请求链中组合发生。这些通常不是默认普通静态代理配置。`aio off;` 或 `ssi off;` 可移除特定触发要素，但应先确认业务功能依赖。[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/zh/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101：HTTP/3 未知帧与 DATA 请求体的状态混淆 HTTP/3 帧解析器必须区分 `DATA` 帧（需要传递给 HTTP 请求体处理流程）和应跳过的未知帧。未知帧的长度在跨网络缓冲区分片时也必须被准确保留。 旧实现的 `ngx_http_v3_parse_data()` 在跳过未知帧时使用了 `st->length` 字段保存“剩余待跳过字节数”，而请求体过滤器把同一字段解释为“剩余 DATA 载荷长度”。如果未知帧恰好跨多次解析调用，解析中断后下一批字节可能被误认为请求体的一部分。[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8) 由此出现两类风险： - 请求体注入：客户端提交的非 DATA 帧载荷可能被传送给上游应用，改变后端实际接收的数据。 - 大小限制绕过：`client_max_body_size` 等限制的预期检查集中在 DATA 路径，错误转换的内容可能绕过相应核验。 官方描述的典型触发场景为 `ngx_http_v3_module` 接收 HTTP/3 请求、并且转发时 `proxy_request_buffering on`。代理请求体缓冲在 `ngx_http_proxy_module` 中默认启用。因此，开启 HTTP/3 的反向代理应优先核对，不宜仅因为没有显式写出 `proxy_request_buffering on;` 就认定不存在触发条件。[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/zh/insights/nginx-remediation-guide#source-18) 该漏洞的直接后果属于后端请求完整性与安全边界变化，不是在 NGINX 内核直接完成 RCE 的等价表述。其最终业务影响取决于上游怎样解析和信任这些字节。[S24](https://keendigit.com/zh/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629：TLS Ticket 轮换遗漏第三个密钥槽位 在受影响配置中，NGINX 可以通过共享内存缓存自动生成和轮换 TLS Session Ticket 密钥，使多个 Worker 能处理同一批票据。 相关同步逻辑为每个 Worker 分配 3 个密钥槽位，解密回调也会遍历这些槽位；但旧实现每次只从共享内存复制 2 个密钥槽位，导致第 3 个槽位的密钥名称、HMAC 密钥和 AES 密钥可能保持未初始化状态。若某个票据的密钥标识被这个状态匹配，可能以未初始化的密钥材料进行验签与解密，从而形成伪造 TLS 会话的路径。[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9) 高风险部署组合通常是： ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` 该漏洞最严重的业务结果是：在以 `ssl_verify_client on;` 等方式使用客户端证书认证（mTLS）的服务上，伪造恢复会话可能绕过客户端证书验证。攻击成功还受不可控条件限制；仅使用普通服务端 HTTPS 证书、没有客户端证书认证的站点，不应被错误描述为“攻击者能够绕过整个网站登录”。[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/zh/insights/nginx-remediation-guide#source-12) 这是一个 TLS 会话认证状态问题，与服务端 TLS 私钥是否被破解、公共 CA 根证书是否受影响无关。[S24](https://keendigit.com/zh/insights/nginx-remediation-guide#source-24) ### 2.7 如何理解 DoS、RCE、认证绕过与已知利用 - DoS：内存错误导致 Worker 崩溃或大量重启。是否造成整体不可用与流量压力、进程重启能力、连接维持时间和高可用架构有关。 - 潜在 RCE：部分公告指出 ASLR 关闭或被绕过时存在代码执行可能，不代表已披露可稳定通用地执行命令的公开攻击链。[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) - 请求注入 / 认证绕过：可能直接改变受保护业务状态或请求内容，不能因为其不直接获得 shell 就忽视。 - 已发现攻击尝试：2026 年 5 月的 CVE-2026-42945 有野外利用活动相关报告；不应把这条历史事实直接推断为 10 月五项 CVE 都已遭大规模成功利用。[S23](https://keendigit.com/zh/insights/nginx-remediation-guide#source-23) ## 3. 修复版本与补丁选择 ### 3.1 NGINX Open Source 官方修复基线 | 上游分支 | 首个覆盖 10 月五项漏洞的正式版本 | 截至 2026-10-27 的建议 | | ------------------------ | ------------------ | -------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | 至少安装 1.30.6，后续安全版本继续跟进 | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | 更早的 NGINX Open Source 分支 | 不能仅依据“曾打过旧漏洞补丁”判定 | 优先迁移至受维护分支；否则要求厂商提供逐 CVE 的正式回补证据 | 这些是 nginx.org 上游源码/官方分支 的版本结论，不应直接拿来否定发行版厂商提供的旧版本回补安全包。`1.31.6` 即使数值大于 `1.30.6`，仍然低于主线分支的修复门槛。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh/insights/nginx-remediation-guide#source-2) ### 3.2 五项 CVE 的上游受影响范围 以下范围按 nginx.org 安全公告原文列示，需结合“当前运行分支”和“实际配置路径”理解： | CVE | 上游标记受影响版本 | 官方标记已修复版本 | | -------------- | ------------------------------- | --------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` 或 `1.31.7+`，各自分支内 | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | 同上 | | CVE-2026-97205 | `0.8.11–1.31.6` | 同上 | | CVE-2026-95101 | `1.25.0–1.31.6` | 同上 | | CVE-2026-97629 | `1.23.2–1.31.6` | 同上 | 要特别注意，CVE-2026-93479 有引入版本限定；不能把所有旧 NGINX 版本都概括为“受此回归漏洞影响”。但较老版本即使不受这次回归影响，也可能仍受更早的 `map` 正则漏洞 CVE-2026-42533 影响。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu：发行版回补版本（USN-8955-1） Canonical 2026 年 10 月 26 日的 USN-8955-1 为四个 Ubuntu 版本提供了安全更新：[S13](https://keendigit.com/zh/insights/nginx-remediation-guide#source-13) | Ubuntu 版本 | `nginx` 及同源包修复版本 | 说明 | | --------- | --------------------- | ---------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | 属于厂商回补；上游版本号仍显示 1.18.0 | | 24.04 LTS | `1.24.0-2ubuntu7.19` | 同上 | | 26.04 LTS | `1.28.3-2ubuntu1.12` | 同上 | | 26.10 | `1.30.4-7ubuntu1.1` | 同上 | 公告包含 `nginx-core`、`nginx-extras`、`nginx-full`、`nginx-light` 等同源包的相应修复版本。不要从 `nginx -v` 只显示的上游部分得出是否修复的结论。例如 Ubuntu 24.04 的 `1.24.0-2ubuntu7.19` 已有这次厂商补丁，但任意来源的 `1.24.0` 并不天然安全。 Ubuntu 官方还明确标注，CVE-2026-95101 在该公告中仅影响 Ubuntu 26.04 / 26.10，CVE-2026-97629 仅影响 Ubuntu 24.04 / 26.04 / 26.10。此处是Ubuntu 自身打包及功能范围，不可直接推及其他发行版。[S13](https://keendigit.com/zh/insights/nginx-remediation-guide#source-13) ### 3.4 Debian：版本间差异必须单独核查 Debian 的 DSA-6575-1（2026-10-21）覆盖本批五项 CVE，并确认 Debian 13 / trixie 的 `nginx` 修复版本为： ```text 1.26.3-3+deb13u10 ``` 然而，截至本报告核验时，Debian Security Tracker 对 Debian 12 / bookworm 的 `1.22.1-9+deb12u10` 仍标记为 vulnerable。因此： - Debian 13 按 DSA-6575-1 更新并验收即可。 - Debian 12 必须逐项检查当前 Security Tracker 或 ELTS 厂商提供的安全修复；在公告尚未确认修复前，不要凭 `apt upgrade` 成功便宣布这五项已全部修复。 - Debian 源码包可能携带独立于 nginx.org 版本号的补丁集。对于自定义构建，需要核对完整源码包修复集合，不能照抄单个上游提交就认为完成。 以上区分以 DSA 与 CVE 跟踪记录为依据。[S14](https://keendigit.com/zh/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/zh/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/zh/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus、njs 与 Ingress Controller | 产品/组件 | 安全选择与验证重点 | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus（商业版） | 以 F5 对应 Plus 分支公告和升级说明为准。核验时最新 CR 为 `PLS.37.2.0.1`，LTS 安全构建为 `PLS.37.0.7.1`；Plus 的版本与包含的回补不能直接用 Open Source 的 1.30/1.31 门槛替代。[S19](https://keendigit.com/zh/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 发布 `njs 1.0.2`，修复 CVE-2026-101019 和 CVE-2026-101025；若正在使用 njs，要同时核对模块与 NGINX 的兼容性。[S20](https://keendigit.com/zh/insights/nginx-remediation-guide#source-20) | | F5 NGINX Ingress Controller / Gateway Fabric | 与 NGINX 核心是关联但独立的软件发行链。以各自控制器、镜像及发行说明修复相关漏洞，不能只替换 Pod 内的一个 NGINX 二进制。 | | Kubernetes 社区 `kubernetes/ingress-nginx` | 该项目在 2026 年 3 月退役，不再提供新的安全维护。应规划迁移到受维护控制器或 Gateway API，而非把其发行版号误认作 F5 NGINX Ingress Controller。[S21](https://keendigit.com/zh/insights/nginx-remediation-guide#source-21) | ### 3.6 实际应选择哪一种 Patch | 部署形态 | 推荐做法 | 修复证明 | | ----------------------------------------- | ---------------------------------- | ---------------------------------- | | nginx.org 官方 DEB/RPM 包 | 升级到所属上游分支已修复版本 | `nginx -v/-V`、包来源、官方安全公告 | | Ubuntu/Debian 官方仓库 | 安装厂商安全软件包 | 完整包版本 + 厂商 USN/DSA + CVE 状态 | | RHEL/Alma/Rocky/SUSE/其他发行版 | 按具体发行版安全公告和包版本升级 | 对应厂商 CSAF/公告，不能套用 Ubuntu/Debian 版本 | | 官方或自定义容器镜像 | 重新构建或拉取经核验的修复镜像，滚动替换 | 镜像摘要、构建 SBOM、运行中 Pod/容器镜像 ID | | 自编译 NGINX、OpenResty、Tengine 或打过第三方模块补丁的版本 | 优先采用维护者完整安全版本；必要时针对目标源码树进行受审查的补丁回补 | 五项漏洞修复内容、ABI/模块兼容、单元及业务回归 | OpenResty 和 Tengine 是不同发行体系；此表仅说明验证方法，不表示其全部版本都与标准 NGINX 同时受影响，也不能无条件应用上游代码补丁。 ## 4. 正式修复流程 ### 4.1 盘点真实接收外部流量的实例 至少为每个入口整理： - 域名、负载均衡/CDN/边缘代理链路、源站暴露方式及所使用的网络协议。 - NGINX 产品（Open Source、Plus、Ingress 等）、完整版本、包仓库来源、镜像摘要。 - `nginx -V` 显示的构建模块和编译参数；有无 njs、Lua、OpenResty、第三方动态模块。 - 真正运行的 master/worker PID、服务单元/容器/Pod、副本和工作节点。 - 实际生效的 `http`/`stream`、`server`、`location`、`include` 配置。 - 是否启用 HTTP/3、mTLS、SSI/AIO、动态日志路径、复杂 `map` 和正则捕获。 不要只检查默认的 `/etc/nginx/nginx.conf`。生产环境常通过 `include` 加载多份站点、TLS 和模块配置，也可能存在多个 NGINX 安装路径或多个代理层。 ### 4.2 检查版本和编译信息 ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` 只能说明命令行路径下二进制的构建情况，并不能单独证明当前在线 Worker 已经加载它。同时注意 `nginx -v` 可能隐藏发行版完整构建后缀；应使用系统包管理器或供应链记录确认。 ### 4.3 导出生效配置并进行第一轮静态筛查 `nginx -T` 会测试配置并转储合并后的配置，输出可能含有认证凭据、密钥路径、内部主机名等敏感信息。推荐在受控终端以 root 权限、私有文件权限保存，不要把原始文件贴到公开工单： ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` 这只是候选路径定位器，不是可靠的 CVE 自动判定工具： 1. `grep` 无法判断变量是否位于同一 `location` 或同一个请求求值链，也无法推导配置继承关系。 2. `proxy_request_buffering on`、部分缓存及票据配置存在默认值，不写出相应指令不等于风险消失。 3. 反向代理、CDN、容器侧车或控制器生成的配置可能与手工检查的文件不同。 4. `NGINX Plus` 与动态模块的特性可能需要使用各自的官方管理工具才能确认。 ### 4.4 通过可信渠道部署修复 Debian/Ubuntu（官方发行版仓库）： ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` 这组命令不能凭空生成尚未提供的安全修复。特别是 Debian 12，升级后的包若仍被安全跟踪系统认定为 vulnerable，需要额外的厂商修复、隔离或迁移措施。[S13](https://keendigit.com/zh/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/zh/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/zh/insights/nginx-remediation-guide#source-15) nginx.org 官方包： ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` 若使用自编译、OpenResty、Tengine 或 NGINX Plus，则采用相应维护者受支持的修复版本，不要混用 nginx.org、发行版和第三方仓库软件包。应保留原始二进制/镜像、配置、签名及可回滚部署清单。 容器/Kubernetes：更新不可变镜像，记录镜像 digest，经灰度发布将旧副本全部滚动替换。`kubectl rollout status` 只能证明部署控制器的发布完成；仍应进一步核对镜像摘要、入口路由与异常副本。 ### 4.5 验证配置并替换旧 Worker ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` 不要把 `nginx -s reload` 视为安装新二进制的充分验收动作：普通配置 reload 常由仍在运行的旧 master 创建 Worker，不能保证进程映像替换。NGINX 有专门的在线二进制升级机制，但需要额外操作和审计；若没有成熟的该流程，建议通过高可用切流后重启服务或滚动更新实现安全切换。[S22](https://keendigit.com/zh/insights/nginx-remediation-guide#source-22) 如果通过 `systemd` socket、容器入口脚本或多套安装管理 NGINX，应检查实际启动目标和进程路径，而不是直接假设 `systemctl restart nginx` 覆盖所有实例。 ### 4.6 从真实外部入口验收并做业务回归 建议至少执行： - 普通 HTTPS、重写路由、静态资源以及 `alias` 映射页面是否正确。 - 正则 `map` 分流、变量根路径、访问日志路径、SNI/证书路由、Stream 代理是否正确。 - HTTP/3（启用时）的普通上传、分块上传、API 请求及上游体积限制是否仍与预期一致。 - mTLS：合法证书请求应成功；缺失、过期或无权证书应仍被拒绝，TLS 恢复/重连不应意外改变权限。 - SSI 页面和异步文件访问是否正常；错误日志无异常的请求内存引用或反复 Worker 崩溃。 - 流量切换后，旧版本进程和旧镜像副本应已退出。 测试须在自有或获授权环境进行。正常请求冒烟测试不能单独证明内存漏洞已被修复；最终还需以供应商修复版本、源码补丁和运行时实测共同验收。 ## 5. 无法立即升级时的缓解措施 本节是风险降低方案，不是补丁替代品。所有临时配置改动都应备份、执行 `nginx -t`、分批发布，必要时能快速回退。[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) ### 5.1 按外部暴露优先控制流量 优先降低无法及时升级的服务的攻击面：对管理面和内部 API 增加可信源访问控制、上游网络隔离或短期下线；为高风险入口加上连接、请求体和速率限制；确保来源认证发生在进入相关 NGINX 请求处理链之前。需注意，多数本次漏洞本身位于 NGINX 数据面内部，传统 WAF 规则可能无法准确判断自定义配置触发条件。 ### 5.2 `alias` / `rewrite`：避免改写后求值 `$request_filename` 建议检查并调整： - 尽量不要在使用 `alias` 的 `location` 中同时进行会改变 URI 的 `rewrite`。 - 避免在 URI 已改写但尚未完成正确位置匹配时使用 `$request_filename`。 - 检查 `return`、`set`、`if`、`add_header`、访问日志格式及包含文件中的间接变量引用。 - 业务上允许时使用清晰的 `root`/`try_files`/独立 `location`，但仅将 `alias` 改成 `root` 也可能改变文件路径语义，必须逐条验证。 不要直接复制互联网上的通用“安全 rewrite 模板”覆盖现有配置。不同 `location` 前缀和重写目标会导致路径拼接含义完全不同。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5) ### 5.3 `map` / Regex：降低捕获变量状态混用 建议优先采用具名捕获并限制其传播范围，而不是让 `$1` 等匿名捕获跨不同正则处理流程长期复用。例如： ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` 该片段仅演示变量所有权更容易审计的结构；并不意味着它已被证明能独立消除所有 CVE-2026-93479 的触发路径。尤其要审核捕获变量是否被其他 `root` 或 `log_format` 提前引用，以及是否有 `volatile`、动态路径和相互依赖的求值链。F5/CERT 建议使用具名捕获、将使用范围限定在对应正则匹配配置中作为短期缓解。[S3](https://keendigit.com/zh/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI：关停不必要的功能组合 对不需要 SSI 或异步文件 I/O 的服务器/路径，可采用： ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` 从漏洞触发条件看，关闭二者之一通常足以移除描述的特定链条；同时关闭仅适用于业务确实不依赖该能力的场景。检查 `include virtual`、子请求、缓存及线程池行为；在反向代理负载较高时，关停 AIO 可能改变延迟和 I/O 性能。[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 请求体注入：必要时临时关闭入口 停用涉及 HTTP/3 的 `quic` 监听，取消对外宣告 HTTP/3 的 `Alt-Svc` 响应头，并核对边缘层/负载均衡器是否仍把 QUIC 请求直接送入未修复的 NGINX： ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` 以上只是变更差异说明，不是可以单独启用的完整 server 配置。HTTP/2 的设置语法与 NGINX 版本有关；如需保留 HTTP/2，应按对应版本使用 `http2 on;` 或现有有效语法，并以 `nginx -t` 检查。部署前必须和现有 server 配置合并，而不是原样用这一节替换整段。同时检查 UDP 443 防火墙、CDN/前置代理的 HTTP/3 终止位置及客户端回退路径。 另一类短期缓解是对受影响代理路径使用 `proxy_request_buffering off;`，但这会改变上游请求体流式发送、失败重试和一些上传工作流的行为；仅在充分测试并确认该指令确实命中受影响的 HTTP/3 代理路径后采用。[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/zh/insights/nginx-remediation-guide#source-18) ### 5.6 TLS Session Ticket：优先保护 mTLS 认证边界 若无法升级且实例依赖共享会话缓存 + 自动票据密钥轮换，可评估： ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` 这样可以关闭 TLS Session Ticket 机制，从而移除该漏洞描述的票据伪造路径；但可能影响会话恢复性能。不能只关掉 mTLS 客户端证书验证来“避免漏洞”，那会直接删除原有认证边界。[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/zh/insights/nginx-remediation-guide#source-12) 也可由专业 TLS 管理流程使用显式 `ssl_session_ticket_key` 文件及安全轮换来避开自动生成条件，但密钥保管、全节点分发、轮换和旧票据生命周期都需谨慎审计。不建议为临时应急在普通 Web 配置或脚本中硬编码一个长期复用的密钥。对使用 mTLS 的关键服务，应额外监视 TLS 会话恢复行为与无证书访问拒绝情况。[S12](https://keendigit.com/zh/insights/nginx-remediation-guide#source-12) ### 5.7 操作系统与边界防护的作用 ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR、非 root Worker、容器只读文件系统、最小文件权限和网络访问隔离均可降低潜在 RCE 的最终影响；但 ASLR 不能修复堆越界或 UAF，也不能保证 Worker 不崩溃。WAF、限流和请求体大小限制也无法覆盖 TLS Ticket 密钥同步逻辑错误。[S4](https://keendigit.com/zh/insights/nginx-remediation-guide#source-4) ### 5.8 常见误区：这些操作不足以视为完成修复 | 常见操作 | 为什么不足 | | -------------------------- | -------------------------------------------- | | “nginx -v 看着比较新” | 未检查所属分支、发行版完整回补版本及在线进程 | | “只升级了内网其中一台” | 旧 Worker/旧容器/旧 CDN 源站实例仍接收请求 | | “网站不使用 PHP/动态代码” | 缺陷发生在 NGINX 核心路径或协议解析，不依赖 PHP 执行 | | “打开 WAF / Cloudflare 已经够了” | WAF 不能证明拦截所有 NGINX 配置依赖型内存缺陷或 TLS 恢复缺陷 | | “已经开启 ASLR” | 只是利用难度缓解；DoS 与请求注入仍然可能 | | “HTTP/3 不对公网暴露，所以完全不需要升级” | 其他四项 CVE 仍需独立评估；且可能存在隐藏源站直连 | | “7 月的 `map` 漏洞已经修复” | 10 月 CVE-2026-93479 涉及后续脚本求值回归问题 | | “禁用缓存能够解决全部问题” | 只影响部分 TLS 缓存或 AIO 场景，不涵盖 alias、script、HTTP/3 | ## 6. 官方 Patch 的实现思路与审阅重点 本节直接对应 NGINX 上游 2026 年 10 月修复提交。代码只摘取有代表性的变化，用于帮助审阅、核验厂商回补方向与理解防御原则，不保证可以脱离原补丁独立编译。若确实需要维护自编译版本，应检查完整提交、上下文差异与对应测试，并优先采用已发布的完整版本。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176：将 URI 已改写纳入 `alias` 路径映射拒绝条件 上游提交修改了 `src/http/ngx_http_core_module.c` 中的 `ngx_http_map_uri_to_path()`： ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` 审阅重点：不能在 URI 已变化但 `alias` 对应位置语义不再可靠时继续计算文件系统路径。这是对前置状态约束的补强，不是简单检查请求 URI 是否存在非法字符。[S5](https://keendigit.com/zh/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479：正确区分输出数据长度和保留长度 上游提交同时更新 `src/http/ngx_http_script.c` 与 `src/stream/ngx_stream_script.c`，核心意图可概括为： ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` 其中 `pool` 是用来说明两种模块均执行内存分配的示意参数名；实际 HTTP 与 Stream 源文件的分配表达式有所不同。核心变化是先计算真实脚本输出长度，再将预留长度加入最终分配，避免写入占用预留空间。[S6](https://keendigit.com/zh/insights/nginx-remediation-guide#source-6) 审计回补时要同时覆盖 HTTP/Stream 的对应求值器；只查 `map` 的配置语法文件不能证明缺陷已修复。 ### 6.3 CVE-2026-97205：为 8 位异步操作计数设置安全阈值 上游在 `src/http/ngx_http_request.h` 新增： ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` 并在异步文件读取、缓存等待、输出过滤和线程操作入口增加类似： ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` 审阅重点：必须覆盖会增加 `r->main->blocked` 的所有实际代码路径，不能只是把阈值常量写在头文件里。回补还需要检查同步回退、异步回调和错误返回的完整配合，确保不会因为直接拒绝任务造成死锁或引用泄漏。[S7](https://keendigit.com/zh/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101：为未知帧单独维护 `skip` 状态 上游在 HTTP/3 解析器状态结构中新增 `skip` 字段，并进行状态分离： ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` 关键不是“禁止未知 HTTP/3 帧”，而是保证跨多次读取时，跳过字节数和DATA 载荷长度永远由独立状态管理。审阅时应关注未知帧跨缓冲区分片，以及 `client_max_body_size` 的最终一致性。[S8](https://keendigit.com/zh/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629：同步完整的 TLS 密钥槽位数组 上游改动位于 `src/event/ngx_event_openssl.c`： ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` 原本镜像含有三个密钥槽位，却只复制了前两个。改为按实际数组元素数量同步，确保 Worker 的验票密钥集合与共享内存一致。审阅时还要确认数组分配、初始化、共享锁与轮换逻辑一致，而非仅检查一次 `memcpy` 长度修改。[S9](https://keendigit.com/zh/insights/nginx-remediation-guide#source-9) ### 6.6 为什么不建议只套用零散补丁片段 这五项修改分别横跨 `src/http`、`src/stream`、`src/http/v3`、`src/event`，且旧版本可能已有安全回补和非官方扩展。回补应形成如下核对矩阵： | 检查对象 | 必须确认的内容 | | ----- | -------------------------------------------------- | | 补丁来源 | 官方提交、匹配目标版本、完整补丁及签名验证 | | 原有补丁集 | 与 CVE-2026-42533、发行版回补等历史修改不冲突 | | 代码路径 | HTTP + Stream 脚本、AIO/线程、HTTP/3、OpenSSL Ticket 都覆盖到 | | 编译兼容 | OpenSSL、PCRE、模块 ABI、动态模块和链接依赖一致 | | 功能回归 | `alias` 重写、动态日志、SSI/AIO、HTTP/3 上传、mTLS session 恢复 | | 运行时 | 所有 Worker/Pod 都运行已经验证的新构建，不再残留旧映像 | 对于维护自身发行版的团队，建议给每条 CVE 保留可审计的 patch ID、包版本、构建日志和回归报告；对于普通运维，最稳妥的方案仍是安装供应商完整安全更新。 ## 7. 历史漏洞回溯、旧分支与其他产品 ### 7.1 2026 年 5—9 月值得同时确认的 NGINX 核心漏洞 很多长时间未更新的 NGINX 实例并不只受 10 月的新问题影响，以下列出近期具代表性的修复节点：[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/zh/insights/nginx-remediation-guide#source-2) | CVE | 首次修复发布 | 关键风险与需要审计的条件 | | -------------- | ---------------------------------------- | ---------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0，5 月 13 日 | `rewrite` 匿名正则捕获与替换逻辑触发堆溢出、潜在 RCE；有公开的野外攻击尝试报告 | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1，5 月 22 日 | `rewrite` 中重叠正则捕获与长度估算导致溢出 | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2，6 月 17 日 | HTTP/2 到上游或 gRPC 的特定配置、大请求头条件触发缓冲区溢出 | | CVE-2026-42530 | Mainline 1.31.2，6 月 17 日 | HTTP/3 Use-After-Free；官方标记受影响范围 `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | `map` + regex 捕获变量求值引发堆溢出，后续补丁与 10 月 CVE-2026-93479 存在回归关联 | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | `ngx_http_slice_module` 特定变量和缓存更新条件下内存内容泄露 | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3，7 月 15 日 | SSI 相关 UAF；与 10 月的 AIO 计数漏洞不是同一根因 | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6，9 月 15 日 | HTTP/3 + 特定 OpenSSL 版本组合的有限堆溢出，主要表现为崩溃/有限内存破坏 | 其他 2026 年公布的 NGINX Core、HTTP/2、charset、SMTP 等漏洞也应按官方安全公告排查；本表有意聚焦与当前 NGINX 公网反代部署最相关、且具有内存安全或请求完整性意义的典型事件，不是 2026 年全部 CVE 列表。[S1](https://keendigit.com/zh/insights/nginx-remediation-guide#source-1) #### 为什么特别关注 CVE-2026-42945 有政府机构安全公告记录针对这项 5 月 `rewrite` 漏洞的野外利用活动及公开利用代码信息，因此对于在 5 月至今长期未打补丁、同时开放公网复杂正则重写的实例，除了完成修复，还应额外审查当时的异常 Worker 崩溃、访问日志和可疑变更。[S23](https://keendigit.com/zh/insights/nginx-remediation-guide#source-23) “发生了攻击尝试”并不自动证明攻击者已经在每个目标上稳定执行命令；如涉及事件响应，应把入侵指标、进程崩溃与真正的权限提升或持久化证据分开调查。 ### 7.2 老版本或发行版回补应采用的应急策略 NGINX 不同分支有各自的支持周期与不同的漏洞引入时间。不能把新版五项补丁不加审阅地统一打到所有早期源码树。 | 场景 | 推荐策略 | | ----------------------------------- | -------------------------------------------- | | 发行版已公布完整安全回补 | 使用厂商软件包，记录完整包版本；避免替换成不兼容的上游裸二进制 | | Debian 12 等暂未覆盖本批所有 CVE 的受影响发行版 | 提交风险工单、限制外部暴露，查供应商/ELTS 状态；必要时迁移或使用可验证的维护发行链 | | 已终止上游支持的历史分支 | 优先迁移到支持版本；若必须短期回补，由维护者评估依赖和补丁兼容、编写完整测试 | | 自带 NGINX 分叉（OpenResty、Tengine、定制网关） | 先判断是否包含相应代码路径，再使用分叉维护者安全声明，不能直接等同上游版本 | | 安全补丁导致业务功能变化 | 采用灰度、双版本切流、配置适配；不宜不加隔离地恢复公网未修复版本 | ### 7.3 njs、Ingress 与 NGINX Core 的修复边界 - njs：除了 NGINX 主程序，还需检查 NGINX JavaScript 模块自身的版本。`njs 1.0.2` 修复了 2026 年 10 月的 XML 解析内存耗尽及带实体引用属性的 XML 验证不一致问题。对于使用 `nginx-saml` 等与 XML 签名验证关联的部署，应进一步阅读 njs 官方针对插件场景的说明。[S20](https://keendigit.com/zh/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX Ingress Controller：Plus、控制器及 Gateway Fabric 各自可能带有额外安全公告、不同打包版本及特有策略漏洞，升级一个层面不等于自动更新另一个层面。[S19](https://keendigit.com/zh/insights/nginx-remediation-guide#source-19) - Kubernetes 社区 ingress-nginx：Kubernetes 官方早已公告该控制器于 2026 年 3 月停止维护，其仓库与 F5 控制器不能混为一谈。受影响业务应规划平滑迁移、验证 Ingress 注解及 Gateway API 语义差异，而不是等待新安全版本。[S21](https://keendigit.com/zh/insights/nginx-remediation-guide#source-21) ## 8. 验收标准与后续检查 建议把以下清单作为变更工单的验收条件： | 项目 | 合格标准 | 可留存的证据 | | ---------- | --------------------------- | ----------------------- | | 资产与入口覆盖 | 所有对外及可绕过 CDN 直连的实例均已盘点 | 域名、LB、IP、Pod/容器清单 | | 包来源与修复范围 | 使用经确认覆盖全部适用 CVE 的版本 | 上游安全公告、USN/DSA、包版本、镜像摘要 | | 旧进程退出 | 所有旧 master/worker/容器已替换 | PID/启动时间、滚动部署状态、运行中映像 | | 配置审计 | 高风险组合已消除或补丁已覆盖，继承关系已核查 | `nginx -T` 的脱敏摘要、审计记录 | | TLS/mTLS | 可信证书通过；无效或缺失证书被拒绝；会话恢复不绕过认证 | 负向/正向授权测试，受控 TLS 测试结果 | | HTTP/3 请求体 | 启用路径经修复；上游请求体与限制行为正确 | HTTP/3、代理上传、体积限制回归测试 | | SSI/AIO | 功能满足要求，Worker 无异常中止 | 业务回归、崩溃与错误率监控 | | 运维监控 | 无明显异常 5xx、SIGSEGV、进程反复退出 | 变更前后服务指标及日志 | | 回滚策略 | 若必须回滚，首先限制暴露并保留安全边界 | 变更单、应急切流与隔离计划 | | 后续生命周期 | 确定安全公告订阅、容器更新频率、分支迁移计划 | 升级台账、责任人与下一次审核日期 | ### 8.1 日志与运行状态应重点观察什么 对已暴露较长时间的服务器，排查异常 `worker process exited on signal`、`SIGSEGV`、请求失败尖峰、异常来源访问聚集、非预期 TLS Session 恢复/认证成功以及异常的后端请求体行为。这些指标只能作为调查线索，不是直接证明某个 CVE 被利用的充分证据；缺少相关日志也不能证明没有受到攻击。 ### 8.2 推荐的最终风险结论措辞 生产环境的验收报告宜使用如下精确表述： > 已识别 NGINX 对外服务入口及软件包来源。全部适用实例已升级到上游正式安全版本，或完成发行版厂商确认的回补；旧 Worker 与旧容器均已替换。已经审计 alias/rewrite/map、AIO/SSI、HTTP/3 请求体和 TLS Session Ticket/mTLS 相关配置，并通过功能、认证和请求完整性回归测试。对尚未完成升级的实例另行登记暴露面、补偿措施、责任人和完成期限。 如果 Debian 12 或其他发行版的补丁仍不完整，不宜将整张验收表判为“已完成”；应明确记录未解决的 CVE、是否存在对应触发配置、隔离状态和最终升级路线。 *** ## 附录：引用来源与链接 说明：正文中的 `[Sx]` 编号统一对应本节。以下优先选择上游项目安全公告、代码提交、供应商发行版公告及国家级安全机构信息。引用中的漏洞严重性按各发布机构原口径描述；资料核验日期为 2026 年 10 月 27 日。 ### S1 — NGINX Open Source 官方安全公告 - 包含五项 10 月 CVE 的上游受影响版本、修复分支及官方自有严重性等级，也涵盖 2026 年历史漏洞。 ### S2 — NGINX 官方版本发布记录 - - 确认 2026-10-14 的 1.30.6 / 1.31.7、2026-10-21 的 1.31.8，以及 5—9 月关键安全修复节点。 ### S3 — 新加坡网络安全局：F5 NGINX 三项 Critical 漏洞 - 说明 CVE-2026-15176、CVE-2026-93479、CVE-2026-97205 的 CVSS v4.0 9.2 评分、必要配置条件及临时缓解建议。 ### S4 — NHS England：F5 NGINX 高危公告 - 说明内存安全问题的 DoS / 潜在 RCE 影响，以及 ASLR 关闭或被绕过等约束。 ### S5 — 官方源码提交：CVE-2026-15176 - 对应 `ngx_http_map_uri_to_path()` 中 `alias` 与 `r->uri_changed` 的状态检查。 ### S6 — 官方源码提交：CVE-2026-93479 - 对应 HTTP/Stream 脚本长度与保留缓冲区分配逻辑。 ### S7 — 官方源码提交：CVE-2026-97205 - 对应 `r->main->blocked` 计数阈值 `NGX_HTTP_MAX_BLOCKED 250` 与异步路径回退。 ### S8 — 官方源码提交：CVE-2026-95101 - 对应 HTTP/3 未知帧剩余长度与 DATA 请求体长度的状态分离。 ### S9 — 官方源码提交：CVE-2026-97629 - 对应同步 TLS Session Ticket 轮换期间全部密钥槽位。 ### S10 — F5：CVE-2026-15176 厂商公告 - 列举 `alias`、`rewrite`、`$request_filename` 与访问日志等触发要素。 ### S11 — F5：CVE-2026-93479 厂商公告 - 列举 map regex 捕获、根路径和日志变量求值条件。 ### S12 — NGINX 官方 TLS/SSL 模块文档 - 说明 `ssl_session_cache`、`ssl_session_tickets`、`ssl_session_ticket_key` 和客户端证书认证等指令。 ### S13 — 安全咨询: Ubuntu USN-8955-1 (2026-10-26) - 提供 Ubuntu 22.04 / 24.04 / 26.04 / 26.10 的完整软件包修复版本及发行版适用范围。 ### S14 — 安全咨询: Debian DSA-6575-1 (2026-10-21) - 确认 Debian 13 / trixie 的安全修复包 `1.26.3-3+deb13u10`，并记录 CVE-2026-93479 的回补关联。 ### S15 — 漏洞追踪: Debian Security Tracker: CVE-2026-15176 - 用于核验 Debian 12 / bookworm 与 Debian 13 / trixie 的发行版修复状态。该状态可能随未来安全更新改变。 ### S16 — 漏洞追踪: Debian Security Tracker: CVE-2026-95101 - 补充确认 HTTP/3 漏洞在不同 Debian 分支上的安全状态。 ### S17 — 安全咨询: Red Hat: CVE-2026-93479 - 补充理解 10 月回归漏洞与 7 月 CVE-2026-42533 的修复关联。 ### S18 — NGINX 官方反向代理模块文档 - - 查询 `proxy_request_buffering`、`client_max_body_size`、`alias`、`aio` 等配置的语义和默认值。 ### S19 — NGINX Plus 官方 Release Notes - 列出 Plus CR/LTS 分支、版本、补丁及升级兼容提醒。 ### S20 — NGINX JavaScript / njs 官方安全公告 - - 包含 2026 年 10 月 njs 1.0.2 和相关 XML 验证、内存耗尽问题。 ### S21 — Kubernetes：社区 ingress-nginx 正式退役说明 - - 说明该项目于 2026 年 3 月停止新版本及安全修复，建议迁移受维护控制器或 Gateway API。 ### S22 — NGINX 官方服务控制与在线二进制升级说明 - 区分配置 reload、重启及在线可执行文件升级方式，用于进程切换验收。 ### S23 — 政府安全通告：2026 年 5 月 NGINX rewrite 漏洞 - - 提供 CVE-2026-42945 的历史风险背景与安全更新建议；野外利用相关判断应以当时机构公告及进一步事件证据为准。 ### S24 — F5：CVE-2026-95101 与 CVE-2026-97629 厂商公告 - - 分别涵盖 HTTP/3 请求体注入与自动 TLS Ticket 密钥轮换风险。 ### S25 — F5：CVE-2026-97205 厂商公告 - 描述 SSI/AIO 触发条件及潜在的内存破坏风险。 [NGINX 安全更新：配置排查、升级与验收要点](https://keendigit.com/zh/news/nginx-security-update) ## 安全维护咨询 不确定证书信任变化如何影响你的系统？我们可以协助排查受影响的客户端，并制定安全更新计划。 [咨询安全更新]() [原始页面]() · [内容索引]() KeenDigit LLC · 怀俄明州登记编号: 2026-002106155 [前往怀俄明州州务卿官网核验]() © 2026 KeenDigit LLC · 美国怀俄明州 Sheridan · 保留所有权利。