先判断：版本和配置必须一起看

上游开源 NGINX 的受影响范围为0.6.27至1.30.0，修复版本从1.30.1或1.31.0开始。版本落在范围内只是一个条件，不表示实例必然可触发；配置不符合触发链，也不能据此忽略升级。反过来，配置中发现相似写法，也要结合实际运行版本与厂商补丁状态评估。

F5列出的典型触发配置如下：

location / {
    rewrite ^/old/(.*)$ /new?upgrade=1;
    set $orig $1;
}

F5给出的例子是同一 location内，含问号查询串的 rewrite之后，后续 set引用了匿名正则捕获 $1。NVD收录的供应商描述还列出后续 rewrite、if或 set等情况，盘点时不宜只搜索这个例子；但搜索命中也不等于每种配置都能触发。需核对指令顺序、问号、匿名捕获的来源及后续引用，再按实际部署测试。配置片段可能来自 include 文件、模板或控制器生成结果，源码仓库里的配置不一定等于线上生效配置。

漏洞涉及堆缓冲区溢出，已知直接后果包括 worker 崩溃并重启，形成拒绝服务风险。远程代码执行不是所有部署都能稳定实现的结果；F5给出的RCE条件还涉及 ASLR 关闭或可绕过等额外情形。不要把“存在溢出”直接写成“可远程执行任意代码”，也不要因为主机启用了 ASLR 就把漏洞标记为已修复。ASLR只能影响利用条件，不能替代补丁。

按产品选择升级目标

开源版应升级到当前使用分支提供的、包含修复的维护版本。上游最早修复版本是1.30.1或1.31.0，但生产环境不宜把“最早修复点”当作长期目标；应按维护策略选择仍受支持的修复版本，并确认发行版是否通过补丁回补修复。

NGINX Plus 使用独立版本线。F5列出的修复版本为：R32 P6、R36 P4或R37。不要把 OSS 的版本号套到 Plus 上，也不要仅看主版本数字。F5其他产品也有独立矩阵，例如 Instance Manager 2.22.1、F5 WAF for NGINX 5.13.0、F5 DoS for NGINX 4.9.0列为修复版本。部分 App Protect、Gateway Fabric、Ingress Controller 产品行当时仍显示没有修复候选版本。这不等于所有 Ingress 都已修复，也不等于这些产品都能通过换一份 NGINX 配置解决；应按具体产品、版本和最新厂商公告确认升级路径。若当前分支没有修复候选版本，安排迁移到包含修复的版本，并把迁移作为明确风险事项跟踪。

生产环境修复：确认对象，再替换运行制品

变更前记录实例、部署方式、版本、配置来源和回滚制品。至少保存当前配置及镜像/软件包版本，准备维护窗口或灰度批次。检查命令应在实际运行 NGINX 的环境中执行：

nginx -v
nginx -V
nginx -T

-v查看命令指向的磁盘二进制版本，-V查看其构建参数，-T测试并展开当前磁盘上的配置；若文件曾修改却未重载，输出未必等于运行进程已加载的配置。需同时核对实际进程及变更记录。输出可能包含内部路径、主机名或敏感配置，不要未经脱敏直接贴到工单或公共渠道。发行版软件包可能显示旧的上游版本号，但已回补安全修复；核对发行版安全公告、包版本和变更记录，不能只凭 nginx -v定性。NGINX Plus及嵌入式产品则以各自厂商矩阵为准。

准备发布修复版本时，先验证配置语法。以下 reload 仅适用于配置变更，不是二进制升级命令：

nginx -t
nginx -s reload

若变更的是 NGINX 程序本身，仅执行 nginx -s reload不足以完成二进制升级。reload 由现有 master 处理；它重新读取配置并启动 worker，却不会自动把旧 master 替换成磁盘上的新程序。优先通过服务管理器受控重启，或通过编排平台滚动替换；对有无中断热升级要求的部署，必须完整遵循 NGINX 官方 USR2 可执行文件升级与回滚流程，验证新旧 master/worker 的交接，不能只发一个信号就宣称完成。上述命令必须针对实际服务使用的二进制、配置路径和运行用户。不要在容器里临时替换文件后误以为镜像已修复。容器场景应构建或拉取包含修复的镜像、更新部署引用，再滚动替换 Pod/任务，并确认新实例的镜像摘要及进程版本。若使用发行版镜像，检查发行版安全更新说明；若控制器会生成 NGINX 配置，修复控制器或数据面制品后仍需核对最终生成配置。

出现 nginx -t失败时不要重载；先检查语法、include 路径、权限和版本兼容性。变更后观察进程、错误日志、健康检查和上游请求，确认新 worker 正常接流量。配置重载成功本身并不能证明新二进制已运行：master 可能仍是旧程序，或容器滚动未完成。应再次核对实际进程/容器以及其使用的修复版本。

暂时不能升级：命名捕获只能减缓，不能结案

若升级窗口受限，可按 F5建议把匿名捕获改成命名捕获，并同步替换全部引用。例如：

location / {
    rewrite ^/old/(?.*)$ /new?upgrade=1;
    set $orig $cap_orig;
}

对这份最小配置，改写仅尝试将匿名 $1换为命名 $cap_orig，后置 set仍给原来的 $orig赋值，避免变量自引用；是否与原配置语义一致，须在目标 NGINX 版本和完整业务配置中验证，不能只凭片段断言。实际配置不能机械复制：若 $cap_orig已被其他用途占用，应换成不会冲突的名称，并逐一更新相关引用。rewrite目标中的问号有明确作用，切勿在改写时删掉或随意调整参数行为。测试旧、新 URL 的路径、查询参数、重定向、转发和 URL 编码结果，确认业务语义一致。

配置减缓不是修复版本，也不是对所有写法和部署形态的通用保证。完成修改后仍要 nginx -t、灰度验证，并记录尚未升级的实例、负责人和期限；不能把“改了命名捕获”写成“CVE已修复”。

验收与回滚：闭环看运行中的进程

补丁修复的验收包括：目标产品所用软件包或镜像确实包含该CVE修复；实际 master/worker 或容器已运行新制品且不再有接流量的旧进程；发布后健康检查、错误日志、请求转发和关键业务路径正常。nginx -T只能辅助核查磁盘上的配置；确认配置确已发布并加载后，才能用它辅助评估触发条件，不能替代补丁验收。尚未升级的节点即使当前配置不命中，也只能记为“当前配置未发现触发链”；如果修改命名捕获完成临时缓解，仍应标注“未修复”，保留升级工单。

若配置测试失败、worker 异常、错误率升高或转发行为变化，按预案恢复已保存的配置和上一版制品，再通过服务管理器或编排平台回滚。回滚后确认旧版本重新接流量、服务恢复，并保留风险状态；不要为了恢复服务而悄悄取消后续修复计划。生产闭环的判断对象不是变更单上的版本号，而是重载或滚动后正在处理请求的二进制及其有效配置。

标签：NGINX · CVE-2026-42945 · rewrite漏洞修复 · NGINX Plus