有勇气的牛排博客
☰

CVE-2026-42945 深度解析：18 年的 NGINX Rewrite 漏洞（NGINX Rift）

2026 年 5 月，NGINX 官方披露了一个高危漏洞：

CVE-2026-42945
又被业内称为：NGINX Rift

这是一个存在了 18 年 的漏洞，影响全球大量互联网服务、反向代理、Ingress 网关与 Kubernetes 集群。

更危险的是：

  • 攻击者无需登录
  • 仅需构造恶意 HTTP 请求
  • 即可触发：
    • Worker Crash（DoS）
    • Heap Buffer Overflow（堆溢出）
    • 某些条件下甚至 Remote Code Execution（RCE）

漏洞公开后，安全圈几乎全线预警。

一、漏洞基本信息

项目 内容
CVE CVE-2026-42945
漏洞名称 NGINX Rift
类型 Heap Buffer Overflow
影响组件 ngx_http_rewrite_module
影响版本 0.6.27 ~ 1.30.0
漏洞等级 High / Critical
CVSS v4 9.2
披露时间 2026-05-13
利用条件 特定 rewrite 配置
是否需要认证 不需要
是否可能 RCE 是

二、漏洞根源是什么？

问题出现在：

ngx_http_rewrite_module

也就是：

rewrite
if
set

这些 NGINX URL 重写逻辑。

三、触发漏洞的核心条件

漏洞并不是“所有 NGINX 都会被打”。

必须满足：

条件 1：使用 rewrite 指令

例如：

rewrite ^/user/(.*)$ /profile?id=$1? last;

条件 2：使用匿名捕获组

即：

$1
$2
$3

这种 PCRE 捕获变量。

条件 3：replacement 中包含 ?

例如：

/profile?id=$1?

这里的：

?

就是关键触发点。

条件 4：后面继续跟 rewrite / if / set

例如：

rewrite ^/user/(.*)$ /profile?id=$1? last;

set $abc "test";

或者：

if ($http_user_agent ~* "curl") {
    ...
}

四、漏洞原理（技术分析）

NGINX 的 rewrite 模块内部有一套：

script engine

用于：

  • 动态拼接 URI
  • 解析 $1
  • 处理 rewrite
  • 执行 if/set

它采用“两阶段执行”：

第一阶段

计算：

需要分配多少内存

第二阶段

真正写入字符串。

但问题在于：

当：

  • rewrite replacement 中有 ?
  • 同时使用 $1
  • 后续还有 rewrite/if/set

时：

第一阶段

计算长度错误。

第二阶段

实际写入超出申请内存。

最终导致：

Heap Buffer Overflow

即：

堆缓冲区溢出

五、攻击效果

1、Worker Crash（最容易）

攻击者可发送特殊请求：

GET /user/AAAAAAA....

导致：

nginx worker process exited on signal 11

表现为：

  • 服务间歇性 502
  • worker 不断重启
  • CPU 飙升
  • 连接抖动

2、远程代码执行（RCE）

如果：

  • ASLR 被关闭
  • 堆布局可预测
  • 存在可利用内存布局

理论上：

攻击者可实现：

Remote Code Execution

即：

远程执行代码

六、为什么这个漏洞这么危险？

因为：

1、NGINX 是互联网基础设施

全球大量：

  • Web 服务
  • API 网关
  • Kubernetes Ingress
  • CDN
  • WAF
  • Docker Gateway

都基于 NGINX。

2、漏洞存在了 18 年

官方披露：

该问题从：

2008 年

就已经存在。

3、很多人喜欢写 rewrite

尤其国内：

伪静态
SEO URL
PHP rewrite

使用极其广泛。

七、哪些系统可能受影响？

不仅是原生 NGINX。

还包括：

  • Kubernetes ingress-nginx
  • OpenResty
  • Kong
  • APISIX
  • Tengine
  • Nginx Proxy Manager
  • 各类云 WAF

八、如何检查是否受影响？

查看版本

nginx -v

如果：

<= 1.30.0

则属于受影响范围。

九、危险配置排查

搜索 rewrite 中包含 ?

grep -R "rewrite.*\\?" /etc/nginx

搜索匿名捕获组

grep -R '\$[1-9]' /etc/nginx

重点检查：

是否存在：

rewrite ... $1? ...

后面继续：

rewrite
if
set

十、修复方案（官方推荐）

方案 1：升级 NGINX（强烈推荐）

官方修复版本：

分支 安全版本
Open Source 1.30.1
Mainline 1.31.0
NGINX Plus R37

Ubuntu/Debian 升级

apt update
apt install nginx

CentOS/RHEL

dnf update nginx

Docker 用户

重新拉取镜像：

docker pull nginx:1.31

然后：

docker compose up -d

十一、临时缓解方案（无法升级时）

如果短时间无法升级：

不要使用匿名捕获组

危险写法：

rewrite ^/user/(.*)$ /profile?id=$1? last;

改成：

使用命名捕获组

安全写法：

rewrite ^/user/(?<uid>.*)$ /profile?id=$uid last;

这是官方建议的重要缓解措施。

十二、推荐的 rewrite 安全规范

建议以后统一：

不使用：

$1
$2
$3

统一使用：

(?<name>)

例如：

rewrite ^/post/(?<id>\d+)$ /article?id=$id last;

十三、如何检测攻击痕迹？

查看 error.log

tail -f /var/log/nginx/error.log

关注：

signal 11
segmentation fault
worker process exited
malloc corruption

查看异常请求

grep "?" access.log

查看 worker 重启

journalctl -u nginx

十四、Kubernetes 用户尤其危险

很多：

ingress-nginx

镜像仍然内置：

NGINX 1.27.x

可能长期脆弱。

尤其：

  • 已归档项目
  • 无人维护镜像
  • 第三方 Helm Chart

风险极高。

十五、这次漏洞最值得警惕的地方

这次 CVE 最震撼行业的点：

不是漏洞本身。

而是：

它是 AI 自动发现的。

研究人员表示：

AI 在数小时内：

  • 自动分析代码
  • 自动找到漏洞
  • 自动定位可利用点

这意味着：

未来：

“沉睡十几年”的漏洞

可能会被 AI 批量挖掘。

对运维、安全、DevOps 来说：

快速升级能力将越来越重要。

十六、最终建议

如果你正在运行：

  • NGINX
  • OpenResty
  • ingress-nginx
  • Kong
  • APISIX

建议立即：

必做

  • 升级到：
    • 1.30.1+
    • 1.31.0+
  • 检查 rewrite 配置
  • 替换 $1/$2
  • 重启 worker

推荐额外措施

  • 开启 ASLR
  • 配置 WAF
  • 开启 Crash 监控
  • 增加日志告警
  • 建立镜像升级机制

评论区

×
×