历史文章日期：2026-10-14（本批漏洞公开及修复日期）。资料核验与补充截至：2026-10-27。
本文按事件日期归档；下文包含 10 月 14 日之后发布的版本与发行版更新信息。
适用对象：NGINX Open Source / NGINX Plus 的网站与反向代理运维人员、安全响应人员、发行版维护者，以及自编译 NGINX 和维护第三方模块的工程师。
本文聚焦 2026 年 10 月 14 日公开并集中修复的五项 NGINX 核心漏洞，同时回溯 2026 年 5—9 月具有代表性的内存安全与请求完整性漏洞。内容覆盖触发条件、代码层成因、影响范围、正式修复流程、短期缓解措施、官方补丁实现、旧分支回补及上线验收。正文采用 S1 等编号引用，全部参考链接集中列在文末附录。示例配置仅用于说明部署与审计思路，应根据实际版本、配置继承、依赖及业务容量验证后再实施。
TL;DR：修复步骤与建议
- 优先完成安全升级：使用 nginx.org 官方 Open Source 包的，Stable 1.30 分支至少升级到 1.30.6；Mainline 1.31 分支至少升级到 1.31.7，截至核验日建议直接使用最新 1.31.8。这是两个独立的修复门槛，不能单纯按数字大小跨分支比较。S1S2
- 发行版安装按完整软件包版本验收：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 已修复。S13S14S15 - 立即审计五类配置组合：
alias + rewrite + $request_filename、map+ regex + 变量求值、aio + ssi + include virtual、HTTP/3 +proxy_request_buffering on、以及ssl_session_cache shared:...+ 自动 TLS Session Ticket 密钥轮换。是否存在指令不等于漏洞必然可利用；必须结合请求路径与配置作用域判断。S1S3S4 - 替换全部旧进程与容器：完成
nginx -t、服务重启或高可用滚动部署，检查旧 master/worker 是否彻底退出；仅执行nginx -s reload不能证明线上已切换到更新后的二进制。 - 针对风险验证真实入口：检查 HTTP/1.1、HTTP/2、HTTP/3（若启用）、反向代理上传及 API 请求体、mTLS 证书认证、SSI 页面和访问日志。记录每个实际入口的软件包来源、版本、镜像摘要、运行中进程及验证结果。
- 暂不能升级时先移除触发条件：禁用不必要的 SSI/AIO 或 HTTP/3，重构脆弱的
alias/rewrite/map变量引用；涉及 mTLS 的实例可评估临时ssl_session_tickets off;。WAF、ASLR、限流和移除高风险指令只覆盖部分攻击条件，不能替代正式补丁。S3S4S8S12
1. 漏洞概览与风险判断
NGINX 于 2026 年 10 月 14 日发布 1.30.6（Stable）与 1.31.7（Mainline），同时修复五项安全问题。其中三项为堆溢出或释放后使用，F5 在 CVSS v4.0 标准下为其分别打出 9.2 / Critical；另外两项涉及 HTTP/3 请求完整性和 TLS 客户端证书认证边界。S1S2S3
评级差异需要明确区分：nginx.org 官方安全列表将本批五项全部标为 medium，而 F5 的 CVSS v4.0 与部分国家级安全机构将三项内存问题列为 Critical。这不是五项漏洞都可以无条件远程执行代码；真实攻击还受到 NGINX 配置、流量可达性及某些不可由攻击者控制的条件约束。可利用内存破坏与稳定可靠的 RCE 是不同证据层级。S1S3S4
| 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 自有等级与发行版评分中可能显示不同的严重性。S1S3S4
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
但即便进程非特权，仍可能接触代理凭据、证书私钥所在可读文件、上游服务令牌、临时文件、内部 API 及可达网络。对 mTLS 而言，认证绕过本身可能就是严重业务后果，不必同时具备代码执行。
2. 成因分析
2.1 理解 NGINX 中三个容易出错的边界
NGINX Worker 是常驻的事件驱动进程，维护请求状态、异步操作及协议解析器。此次漏洞集中体现出三个工程层面的约束：
- 变量求值与内存尺寸必须一致：
rewrite改变请求 URI 后，路径映射必须与当前有效location一致；脚本解释器计算变量长度时，写入空间必须覆盖实际输出及保留区。 - 异步操作必须延长请求内存的生命周期：有未完成的文件读写、缓存等待或线程任务时，不能把相关请求内存池提前释放。
- 协议状态与安全状态不能混用或遗漏：HTTP/3 未知帧跳过的长度不能被当作 DATA 请求体长度；TLS Session Ticket 轮换时所有参与验签的密钥槽位必须正确初始化、同步。
以下内容以 NGINX 上游修复提交与厂商公告为依据，解释可触发的失败机制；示例片段用于分析，不是可直接用于修复生产环境的完整代码。S5S6S7S8S9
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
典型组合（仅作为配置审计反例，不建议部署）：
# 仅用于识别风险模式：不是修复配置
location /foo/ {
alias /srv/alias-root/;
rewrite ^/foo/.*$ /new-path;
return 200 $request_filename;
}危险并不局限于 return：set、if、add_header、log_format 等若在相同请求流程中触发 $request_filename 求值，也需要审计。示例中的 return 仅让这一状态路径容易看清，不能用它推断所有生产配置都会产生溢出。S5S10
攻击后果：构造请求可能造成 Worker 重启或服务中断；在 ASLR 被关闭或可被绕过等条件下，存在潜在 RCE。上游补丁的核心是拒绝在不再有效的 alias 上下文中完成重写后的 URI 路径映射，而不是简单扩大某个缓冲区。S5S10
2.3 CVE-2026-93479：脚本求值中“预留空间”与真实变量长度错配
NGINX 的 HTTP 和 Stream 模块都有将字面字符串和变量值拼接成结果字符串的脚本求值器。应用示例包括 HTTP 文档根路径、访问日志路径，以及 Stream 中的变量表达式。
某些 map + 正则表达式的配置允许捕获值在 map 结果变量求值之前被其他表达式读取。结合带有预留长度的脚本执行方式，旧实现会把 len 预留空间提前计入求值的长度累加器，使后续写入指针计算与缓冲区边界不再一致。在特定变量求值序列中，后续字符串写入可能覆盖预留区域，造成堆溢出。S6
| 参与元素 | 为什么值得关注 |
|---|---|
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；应检查完整安全修复链。S6S14S17
这里的潜在 RCE 风险与内存保护环境有关，不应宣称仅含 map 正则就一定能够被匿名攻击者利用。S11
2.4 CVE-2026-97205：AIO 未完成操作计数回绕造成 Use-After-Free
本漏洞不是简单的“开启 SSI 就有 UAF”，关键在于主请求所持有的异步操作引用计数。
NGINX 使用 r->main->blocked 跟踪尚未结束的异步处理，旧实现中它是 8 位计数；某些路径没有在增加计数之前进行上限检查。当同一主请求累计 256 个未完成操作时，计数可能从 255 回绕到 0。后续流程会错误地认为没有阻止请求释放的异步操作，从而释放仍被任务引用的请求内存池。S7
失败过程可分为：
- 启用了相关异步 I/O/线程路径，SSI 页面通过
include virtual引入多个子请求或读取操作。 - 某一主请求的未完成操作累加到计数字段的表示上限。
- 8 位计数回绕，错误地表示为“没有挂起操作”。
- 请求内存池被释放，而文件读取、缓存等待或线程任务的回调仍保留其中的引用。
- 后续异步完成回调访问已释放的内存，产生 UAF、Worker 崩溃或潜在内存破坏。
官方修复在请求头文件加入 NGX_HTTP_MAX_BLOCKED 250，并在输出过滤器、缓存读取与上游线程路径加入限制；达到阈值时，有同步路径的操作改为同步完成，不能安全处理的则拒绝继续增加挂起任务。S7
适用性判断：必须评估 SSI、AIO、虚拟包含、子请求及相关异步操作能否在同一请求链中组合发生。这些通常不是默认普通静态代理配置。aio off; 或 ssi off; 可移除特定触发要素，但应先确认业务功能依赖。S4S7S25
2.5 CVE-2026-95101：HTTP/3 未知帧与 DATA 请求体的状态混淆
HTTP/3 帧解析器必须区分 DATA 帧（需要传递给 HTTP 请求体处理流程）和应跳过的未知帧。未知帧的长度在跨网络缓冲区分片时也必须被准确保留。
旧实现的 ngx_http_v3_parse_data() 在跳过未知帧时使用了 st->length 字段保存“剩余待跳过字节数”，而请求体过滤器把同一字段解释为“剩余 DATA 载荷长度”。如果未知帧恰好跨多次解析调用，解析中断后下一批字节可能被误认为请求体的一部分。S8
由此出现两类风险：
- 请求体注入：客户端提交的非 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; 就认定不存在触发条件。S8S18
该漏洞的直接后果属于后端请求完整性与安全边界变化，不是在 NGINX 内核直接完成 RCE 的等价表述。其最终业务影响取决于上游怎样解析和信任这些字节。S24
2.6 CVE-2026-97629：TLS Ticket 轮换遗漏第三个密钥槽位
在受影响配置中，NGINX 可以通过共享内存缓存自动生成和轮换 TLS Session Ticket 密钥，使多个 Worker 能处理同一批票据。
相关同步逻辑为每个 Worker 分配 3 个密钥槽位，解密回调也会遍历这些槽位；但旧实现每次只从共享内存复制 2 个密钥槽位，导致第 3 个槽位的密钥名称、HMAC 密钥和 AES 密钥可能保持未初始化状态。若某个票据的密钥标识被这个状态匹配，可能以未初始化的密钥材料进行验签与解密，从而形成伪造 TLS 会话的路径。S9
高风险部署组合通常是：
# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制该漏洞最严重的业务结果是：在以 ssl_verify_client on; 等方式使用客户端证书认证（mTLS）的服务上，伪造恢复会话可能绕过客户端证书验证。攻击成功还受不可控条件限制；仅使用普通服务端 HTTPS 证书、没有客户端证书认证的站点，不应被错误描述为“攻击者能够绕过整个网站登录”。S9S12
这是一个 TLS 会话认证状态问题，与服务端 TLS 私钥是否被破解、公共 CA 根证书是否受影响无关。S24
2.7 如何理解 DoS、RCE、认证绕过与已知利用
- DoS：内存错误导致 Worker 崩溃或大量重启。是否造成整体不可用与流量压力、进程重启能力、连接维持时间和高可用架构有关。
- 潜在 RCE：部分公告指出 ASLR 关闭或被绕过时存在代码执行可能，不代表已披露可稳定通用地执行命令的公开攻击链。S4
- 请求注入 / 认证绕过：可能直接改变受保护业务状态或请求内容，不能因为其不直接获得 shell 就忽视。
- 已发现攻击尝试：2026 年 5 月的 CVE-2026-42945 有野外利用活动相关报告；不应把这条历史事实直接推断为 10 月五项 CVE 都已遭大规模成功利用。S23
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，仍然低于主线分支的修复门槛。S1S2
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
3.3 Ubuntu：发行版回补版本（USN-8955-1）
Canonical 2026 年 10 月 26 日的 USN-8955-1 为四个 Ubuntu 版本提供了安全更新：S13
| 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
3.4 Debian：版本间差异必须单独核查
Debian 的 DSA-6575-1（2026-10-21）覆盖本批五项 CVE，并确认 Debian 13 / trixie 的 nginx 修复版本为：
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 跟踪记录为依据。S14S15S16
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 |
| njs / ngx_http_js_module | 2026-10-14 发布 njs 1.0.2，修复 CVE-2026-101019 和 CVE-2026-101025；若正在使用 njs，要同时核对模块与 NGINX 的兼容性。S20 |
| F5 NGINX Ingress Controller / Gateway Fabric | 与 NGINX 核心是关联但独立的软件发行链。以各自控制器、镜像及发行说明修复相关漏洞，不能只替换 Pod 内的一个 NGINX 二进制。 |
Kubernetes 社区 kubernetes/ingress-nginx | 该项目在 2026 年 3 月退役，不再提供新的安全维护。应规划迁移到受维护控制器或 Gateway API，而非把其发行版号误认作 F5 NGINX Ingress Controller。S21 |
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 检查版本和编译信息
# 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 权限、私有文件权限保存，不要把原始文件贴到公开工单：
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 自动判定工具：
grep无法判断变量是否位于同一location或同一个请求求值链，也无法推导配置继承关系。proxy_request_buffering on、部分缓存及票据配置存在默认值，不写出相应指令不等于风险消失。- 反向代理、CDN、容器侧车或控制器生成的配置可能与手工检查的文件不同。
NGINX Plus与动态模块的特性可能需要使用各自的官方管理工具才能确认。
4.4 通过可信渠道部署修复
Debian/Ubuntu（官方发行版仓库）：
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，需要额外的厂商修复、隔离或迁移措施。S13S14S15
nginx.org 官方包：
# 先确认仓库来自 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
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
如果通过 systemd socket、容器入口脚本或多套安装管理 NGINX，应检查实际启动目标和进程路径，而不是直接假设 systemctl restart nginx 覆盖所有实例。
4.6 从真实外部入口验收并做业务回归
建议至少执行：
- 普通 HTTPS、重写路由、静态资源以及
alias映射页面是否正确。 - 正则
map分流、变量根路径、访问日志路径、SNI/证书路由、Stream 代理是否正确。 - HTTP/3（启用时）的普通上传、分块上传、API 请求及上游体积限制是否仍与预期一致。
- mTLS：合法证书请求应成功；缺失、过期或无权证书应仍被拒绝，TLS 恢复/重连不应意外改变权限。
- SSI 页面和异步文件访问是否正常；错误日志无异常的请求内存引用或反复 Worker 崩溃。
- 流量切换后，旧版本进程和旧镜像副本应已退出。
测试须在自有或获授权环境进行。正常请求冒烟测试不能单独证明内存漏洞已被修复；最终还需以供应商修复版本、源码补丁和运行时实测共同验收。
5. 无法立即升级时的缓解措施
本节是风险降低方案，不是补丁替代品。所有临时配置改动都应备份、执行 nginx -t、分批发布，必要时能快速回退。S3S4
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
5.3 map / Regex：降低捕获变量状态混用
建议优先采用具名捕获并限制其传播范围，而不是让 $1 等匿名捕获跨不同正则处理流程长期复用。例如：
# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
default /srv/www/default;
~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}该片段仅演示变量所有权更容易审计的结构；并不意味着它已被证明能独立消除所有 CVE-2026-93479 的触发路径。尤其要审核捕获变量是否被其他 root 或 log_format 提前引用，以及是否有 volatile、动态路径和相互依赖的求值链。F5/CERT 建议使用具名捕获、将使用范围限定在对应正则匹配配置中作为短期缓解。S3S6
5.4 AIO + SSI：关停不必要的功能组合
对不需要 SSI 或异步文件 I/O 的服务器/路径，可采用：
# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;从漏洞触发条件看，关闭二者之一通常足以移除描述的特定链条；同时关闭仅适用于业务确实不依赖该能力的场景。检查 include virtual、子请求、缓存及线程池行为；在反向代理负载较高时，关停 AIO 可能改变延迟和 I/O 性能。S7
5.5 HTTP/3 请求体注入：必要时临时关闭入口
停用涉及 HTTP/3 的 quic 监听，取消对外宣告 HTTP/3 的 Alt-Svc 响应头，并核对边缘层/负载均衡器是否仍把 QUIC 请求直接送入未修复的 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 代理路径后采用。S8S18
5.6 TLS Session Ticket：优先保护 mTLS 认证边界
若无法升级且实例依赖共享会话缓存 + 自动票据密钥轮换，可评估：
# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;这样可以关闭 TLS Session Ticket 机制，从而移除该漏洞描述的票据伪造路径；但可能影响会话恢复性能。不能只关掉 mTLS 客户端证书验证来“避免漏洞”，那会直接删除原有认证边界。S9S12
也可由专业 TLS 管理流程使用显式 ssl_session_ticket_key 文件及安全轮换来避开自动生成条件，但密钥保管、全节点分发、轮换和旧票据生命周期都需谨慎审计。不建议为临时应急在普通 Web 配置或脚本中硬编码一个长期复用的密钥。对使用 mTLS 的关键服务，应额外监视 TLS 会话恢复行为与无证书访问拒绝情况。S12
5.7 操作系统与边界防护的作用
# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_spaceASLR、非 root Worker、容器只读文件系统、最小文件权限和网络访问隔离均可降低潜在 RCE 的最终影响；但 ASLR 不能修复堆越界或 UAF，也不能保证 Worker 不崩溃。WAF、限流和请求体大小限制也无法覆盖 TLS Ticket 密钥同步逻辑错误。S4
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 月修复提交。代码只摘取有代表性的变化，用于帮助审阅、核验厂商回补方向与理解防御原则，不保证可以脱离原补丁独立编译。若确实需要维护自编译版本，应检查完整提交、上下文差异与对应测试，并优先采用已发布的完整版本。S5S6S7S8S9
6.1 CVE-2026-15176：将 URI 已改写纳入 alias 路径映射拒绝条件
上游提交修改了 src/http/ngx_http_core_module.c 中的 ngx_http_map_uri_to_path()：
- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {审阅重点：不能在 URI 已变化但 alias 对应位置语义不再可靠时继续计算文件系统路径。这是对前置状态约束的补强，不是简单检查请求 URI 是否存在非法字符。S5
6.2 CVE-2026-93479：正确区分输出数据长度和保留长度
上游提交同时更新 src/http/ngx_http_script.c 与 src/stream/ngx_stream_script.c，核心意图可概括为：
- 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
审计回补时要同时覆盖 HTTP/Stream 的对应求值器；只查 map 的配置语法文件不能证明缺陷已修复。
6.3 CVE-2026-97205：为 8 位异步操作计数设置安全阈值
上游在 src/http/ngx_http_request.h 新增：
#define NGX_HTTP_MAX_BLOCKED 250并在异步文件读取、缓存等待、输出过滤和线程操作入口增加类似：
if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
/* 使用同步路径，或者拒绝新的异步操作 */
}审阅重点：必须覆盖会增加 r->main->blocked 的所有实际代码路径，不能只是把阈值常量写在头文件里。回补还需要检查同步回退、异步回调和错误返回的完整配合，确保不会因为直接拒绝任务造成死锁或引用泄漏。S7
6.4 CVE-2026-95101：为未知帧单独维护 skip 状态
上游在 HTTP/3 解析器状态结构中新增 skip 字段，并进行状态分离：
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
6.5 CVE-2026-97629：同步完整的 TLS 密钥槽位数组
上游改动位于 src/event/ngx_event_openssl.c：
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
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 月的新问题影响，以下列出近期具代表性的修复节点：S1S2
| 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
为什么特别关注 CVE-2026-42945
有政府机构安全公告记录针对这项 5 月 rewrite 漏洞的野外利用活动及公开利用代码信息，因此对于在 5 月至今长期未打补丁、同时开放公网复杂正则重写的实例，除了完成修复，还应额外审查当时的异常 Worker 崩溃、访问日志和可疑变更。S23
“发生了攻击尝试”并不自动证明攻击者已经在每个目标上稳定执行命令；如涉及事件响应，应把入侵指标、进程崩溃与真正的权限提升或持久化证据分开调查。
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 - F5 NGINX Plus / NGINX Ingress Controller：Plus、控制器及 Gateway Fabric 各自可能带有额外安全公告、不同打包版本及特有策略漏洞，升级一个层面不等于自动更新另一个层面。S19
- Kubernetes 社区 ingress-nginx：Kubernetes 官方早已公告该控制器于 2026 年 3 月停止维护，其仓库与 F5 控制器不能混为一谈。受影响业务应规划平滑迁移、验证 Ingress 注解及 Gateway API 语义差异，而不是等待新安全版本。S21
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 官方反向代理模块文档
- https://nginx.org/en/docs/http/ngx_http_proxy_module.html
- https://nginx.org/en/docs/http/ngx_http_core_module.html
查询 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 正式退役说明
- https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
- https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
说明该项目于 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 触发条件及潜在的内存破坏风险。