CVE-2026-42945 怎么排查？Nginx Rift 漏洞触发条件、版本检查与升级建议

CVE-2026-42945 是 NGINX Open Source 和 NGINX Plus 中的一个安全漏洞，外界也把它称为 Nginx Rift。它出现在 ngx_http_rewrite_module，漏洞类型是 heap-based buffer overflow。

这类新闻很容易被写成“潜伏 18 年”“不用密码远程控制”“三成服务器中招”。这些说法有传播性，但看补丁和 NVD 描述时，最好把风险拆开看：它确实严重，也确实不需要登录账号；但并不是所有 Nginx 实例都会自动被接管，触发需要特定 rewrite 配置和请求条件。

先看官方描述

NVD 对 CVE-2026-42945 的描述可以概括为：

影响 NGINX Plus 和 NGINX Open Source。
漏洞位于 ngx_http_rewrite_module。
当 rewrite 指令后面跟着 rewrite、if 或 set 指令，并且使用未命名的 PCRE 捕获组，例如 $1、$2，同时替换字符串里包含问号 ? 时，可能触发问题。
未认证攻击者可以发送构造请求触发漏洞。
结果可能是 NGINX worker 进程发生 heap buffer overflow 并重启。
如果系统关闭了 ASLR，存在代码执行可能。

F5 作为 CNA 给出的评分是：

CVSS v4.0：9.2，Critical。
CVSS v3.1：8.1，High。
CWE：CWE-122 Heap-based Buffer Overflow。

所以，这不是普通的“配置写错导致 404”问题，而是 Nginx 官方安全修复范围内的内存安全漏洞。

哪些说法需要降温

第一，“不用密码”基本可以理解为未认证攻击。也就是说，攻击者不需要登录 Nginx 后台，不需要拿到 SSH，也不需要应用系统账号。但这不等于任何公网 Nginx 都能被随手接管。

第二，“直接远程控制”要看条件。官方描述里更稳妥的说法是：漏洞可导致 worker 进程重启；在 ASLR 关闭的系统上，代码执行是可能结果。对启用了 ASLR、发行版编译加固完整、运行权限受限的环境，风险路径会更复杂。

第三，“30% 服务器中招”不能简单等同于“所有 Nginx 市占率都是漏洞暴露面”。真正暴露要同时看版本、是否启用受影响模块、是否存在特定 rewrite 配置、发行版是否已经回补补丁，以及 Nginx 运行环境的加固状态。

更准确的判断方式是：只要你在生产环境运行 Nginx，就应该尽快检查；但不要只按标题里的比例判断自己是否中招。

受影响范围怎么判断

从 nginx.org 发布信息看，2026 年 5 月 13 日发布的 nginx-1.30.1 stable 和 nginx-1.31.0 mainline 包含多项安全修复，其中包括 ngx_http_rewrite_module 的 buffer overflow，也就是 CVE-2026-42945。

如果你使用官方 Nginx 源码或官方包，可以优先关注：

NGINX Open Source stable：升级到 1.30.1 或之后版本。
NGINX Open Source mainline：升级到 1.31.0 或之后版本。
NGINX Plus：查看 F5 对应分支的修复版本。

如果你使用 Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、容器镜像、Plesk、宝塔、Ingress Controller 或云厂商托管组件，不要只看 nginx -v 里的上游版本号。很多发行版会把安全补丁 backport 到旧版本包里，版本号看起来旧，但补丁可能已经合入。

一分钟判断是否需要紧急处理

可以先按下面几个问题快速分级：

这台 Nginx 是否直接暴露在公网，或者位于 API Gateway、反向代理、负载均衡、Ingress 入口层？
是否使用官方 Nginx 包、源码编译包、第三方面板、容器镜像，且还没有确认 CVE-2026-42945 修复状态？
配置里是否存在复杂 rewrite 规则，尤其是连续 rewrite、if、set，以及 $1、$2 这类未命名捕获组？
是否存在把请求路径、查询参数或用户可控输入带入 rewrite 目标的场景？
系统加固是否较弱，例如 ASLR 被关闭、worker 权限过高、容器权限过宽？

如果前两项命中，并且 rewrite 配置还没有排查，建议按高优先级处理。公网入口、共享环境、Kubernetes Ingress、边缘代理和承载登录/API 流量的 Nginx，应该优先升级或替换到确认修复的包。

Debian / Ubuntu / RHEL / Alpine 如何确认修复

发行版用户不要只看 nginx -v。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine 这类系统经常把安全补丁回补到稳定分支，表面版本号可能仍然低于 nginx.org 的 1.30.1 或 1.31.0。

Debian / Ubuntu 可以优先看安全公告、包 changelog 和可升级列表：

1
2
3
4


nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux 可以看安全更新和包变更记录：

1
2


yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine 可以检查当前包版本和安全分支更新：

1
2


apk info -v nginx
apk version -v nginx

如果包管理器、发行版安全公告或厂商 advisory 明确写明已修复 CVE-2026-42945，即使上游版本号看起来不新，也可以按“已回补修复”处理。反过来，如果只是版本号较高但来源不明，仍然要确认构建日期和补丁来源。

容器镜像与 Ingress Controller 怎么查

容器环境要检查镜像里的 Nginx，而不是只看宿主机。先确认镜像实际内置版本：

1
2


docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

还要看基础镜像是否更新过。如果镜像基于 Debian、Ubuntu、Alpine 或发行版包构建，判断方式应回到对应发行版的安全公告和包 changelog。只重启旧镜像没有意义，镜像本身需要重新构建或替换。

Kubernetes Ingress 需要同时确认三件事：

Ingress Controller 项目是否发布了针对 CVE-2026-42945 的 advisory 或修复版本。
当前集群运行的 controller 镜像 digest 是否已经更新，而不是只改了 tag。
controller 内置 Nginx 版本、构建参数和模板配置是否仍然包含高风险 rewrite 规则。

可以先看运行中的镜像：

1
2


kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

如果使用云厂商托管 Ingress 或网关，还要查对应云服务公告。托管组件通常不是用户自己 apt upgrade 能解决的，需要等待厂商修复或切换到已修复版本。

rewrite 配置重点排查哪些写法

这个漏洞和 rewrite 配置有关，排查时可以先搜索 Nginx 配置：

1
2


grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

重点关注类似模式：

1

rewrite ^/old/(.*)$ /new/$1? permanent;

这里的 $1、$2 这类未命名捕获组，以及替换目标中的 ?，是官方描述里的关键条件之一。排查时尤其关注下面几类写法：

一个 rewrite 后面紧跟另一个 rewrite、if 或 set。
正则里使用 (.*)、(.+) 这类宽泛捕获，并在目标里用 $1、$2。
rewrite 目标里带 ?，用于拼接或丢弃查询参数。
rewrite 输入来自公网路径、Host、URI、参数或上游可控值。
面板、网关、Ingress 注解或模板自动生成的 rewrite 规则。

如果短时间内无法升级，可以先做临时缓解：

减少复杂 rewrite 规则。
把未命名捕获组改成更清晰的命名捕获。
避免在替换字符串里拼接不必要的 ?。
对高风险入口加 WAF 或反向代理规则。
确认系统启用了 ASLR。
降低 Nginx worker 运行权限，确认 systemd sandbox、SELinux/AppArmor 等加固状态。

这些只是缓解，不是替代补丁。

修复优先级

建议按暴露面排序：

公网入口 Nginx。
反向代理、API Gateway、边缘网关。
多租户环境里的 Nginx。
Kubernetes Ingress Controller。
Plesk、面板工具、云市场镜像等自带 Nginx 的组件。
内网但承载关键业务的 Nginx。

升级后如何验证：nginx -t、reload、worker 状态

更新后不要只看包管理器提示成功，还要确认配置、进程和实际二进制都已经切换。先验证配置：

1

nginx -t

确认没有错误后再平滑加载：

1

systemctl reload nginx

如果包升级涉及二进制替换，建议确认旧 worker 已退出：

1

ps aux | grep nginx

也可以查看主进程启动时间和二进制路径，确认运行中的服务不是旧进程继续驻留。必要时安排维护窗口重启服务，避免旧 worker 或旧容器继续处理请求。

容器和 Ingress 环境还要确认新镜像已经真正滚动完成：

1
2


kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

验证重点不是“命令执行过”，而是“线上流量已经由包含修复的 Nginx 进程承载”。

不要忽略同批次 Nginx 修复

nginx.org 在同一天发布的 1.30.1 和 1.31.0 不只修复了 CVE-2026-42945。发布信息还提到 HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free 等问题。

这意味着生产环境不应该只针对单个 CVE 做临时规则，而是应该把 Nginx 这一轮安全更新当成一次整体升级来处理。

小结

CVE-2026-42945 的关键点不是“所有 Nginx 都会被秒控”，而是：一个长期存在于 rewrite 模块里的内存安全漏洞，在特定配置下可被未认证请求触发，最直接后果是 worker 崩溃重启；在 ASLR 关闭等较弱环境下，代码执行风险更高。

对运维来说，处理顺序很简单：

确认 Nginx 来源和版本。
查看发行版、F5、nginx.org 或云厂商公告。
尽快升级到包含修复的版本或发行版安全包。
排查复杂 rewrite 配置，尤其是 $1、$2 和 ? 组合。
确认 ASLR、权限隔离和服务重载状态。

标题可以吓人，修复要冷静。先确认暴露面，再升级，再回头清理高风险 rewrite 规则。