【转载】CVE-2026-42945（NGINX Rift）深度解析：一个潜伏18年的堆缓冲区溢出漏洞

2026年5月13日，F5联合安全研究团队公开披露了一个影响范围极广的NGINX高危漏洞——CVE-2026-42945（NGINX Rift）。该漏洞存在于ngx_http_rewrite_module中，属于典型的堆缓冲区溢出，潜伏时间长达18年，几乎影响了从0.6.27到1.30.0的所有NGINX Open Source版本。

这是一个“基础设施级”漏洞：它不需要认证、远程即可触发，既能稳定造成DoS，也在特定条件下存在RCE潜力。大量反向代理、Kubernetes Ingress、API网关、CDN和WAF都处于风险之中。

一、漏洞概述

• 漏洞编号：CVE-2026-42945
• 漏洞名称：NGINX Rift
• 漏洞类型：Heap Buffer Overflow（堆缓冲区溢出）
• 影响组件：ngx_http_rewrite_module
• CVSS v4：9.2（Critical）
• 影响版本：
  • NGINX Open Source：0.6.27 ~ 1.30.0
  • NGINX Plus：R32 ~ R36
• 修复版本：
  • Open Source：1.30.1 / 1.31.0 及以上
• 利用条件：未授权远程触发（特定配置下）
• 潜在影响：Worker进程崩溃（DoS）、服务重启风暴、ASLR关闭时可能RCE

该漏洞的核心本质不是简单的memcpy越界，而是 “长度计算阶段”与 “实际写入阶段”的逻辑失配——这在Web服务器、WAF、Proxy等高性能C/C++组件中极为常见。

二、NGINX Rewrite模块工作机制

很多人以为一条rewrite指令只是简单的字符串替换：

rewrite ^/api/(.*)$ /test.php?id=$1 last;

实际上远非如此。

NGINX会将rewrite规则编译成script bytecode（类似虚拟机指令），然后由ngx_http_script_engine_t执行。整个过程涉及：

• 正则匹配（PCRE）
• Capture组提取
• URI escaping
• Query String处理
• 多条指令链式执行（rewrite → set → if 等）

核心文件位于：src/http/ngx_http_script.c

关键函数包括：

• ngx_http_script_add_capture_code
• ngx_http_script_copy_capture_code
• ngx_http_script_copy_capture_len_code
• ngx_http_script_regex_end_code

三、漏洞根因：两阶段长度计算失配

NGINX Rewrite引擎采用经典的两阶段处理：

1. 长度预计算阶段（Length Phase）：计算最终需要多少内存
2. 实际数据拷贝阶段（Copy Phase）：真正写入堆内存

漏洞就出在这两个阶段的escape逻辑不一致。

关键触发条件（必须同时满足）

1. 使用未命名PCRE捕获组（$1、$2等）
2. replacement字符串中包含?（切换URI/ARGS escaping模式）
3. 后面跟随其他rewrite/set/if指令（污染engine状态）

示例危险配置：

rewrite ^/api/(.*)$ /v1.php?data=$1 last;
set $flag 1;

四、代码层面深度分析

1. 长度预计算阶段（ngx_http_script_copy_capture_len_code）

if (escape) {
    return ngx_escape_uri(NULL, cap, len, NGX_ESCAPE_ARGS);
} else {
    return len;
}

2. 实际写入阶段（ngx_http_script_copy_capture_code）

if (escape) {
    dst = ngx_escape_uri(pos, src, len, NGX_ESCAPE_ARGS);
} else {
    pos = ngx_copy(pos, src, len);
}

核心问题：escape标志在两个阶段可能不一致，尤其当?出现并有后续指令修改engine->is_args、engine->quote等状态时。

?的作用在于：它会让NGINX认为后续部分进入Query String，从而改变escaping策略，导致长度计算偏差（例如空格从1字节变成%20的3字节）。

后续的set/if指令会继续执行opcode，进一步污染共享状态机，导致前一个capture的escape决策失效。

五、漏洞利用思路

攻击流程

利用技巧：

• 构造超长capture（如大量A或特殊字符%``?``#``+）
• 触发escape长度膨胀
• 利用NGINX pool allocator的连续内存布局，覆盖相邻chunk中的函数指针、request结构体等

公开PoC：DepthFirst已开源包含Docker复现环境的仓库（https://github.com/DepthFirstDisclosures/Nginx-Rift），DoS路径极易复现，RCE需精细heap feng shui。

六、影响范围与严重性

• DoS：单请求即可导致worker崩溃，重启后可重复攻击，形成拒绝服务风暴。
• RCE：ASLR关闭时可行。默认Linux启用ASLR会显著提高难度，但并非绝对安全。
• Kubernetes环境：Ingress Controller内置NGINX，风险更高（需单独检查pod内版本）。
• 暴露面：几乎所有使用rewrite做路由、灰度、API转发的NGINX实例。

七、修复与缓解措施

1. 根本修复：升级NGINX

# 以yum/apt为例
nginx -v
# 升级到 1.30.1+ 或 1.31.0+

2. 临时配置缓解（强烈推荐）

将未命名捕获组改为命名捕获组：

# 危险
rewrite ^/api/(.*)$ /test.php?id=$1 last;

# 安全
rewrite ^/api/(?<id>.*)$ /test.php?id=$id last;

3. 其他防御

• 开启/确认ASLR（cat /proc/sys/kernel/randomize_va_space应为2）
• WAF规则拦截异常长URI或包含大量特殊字符的请求
• 监控日志中的worker process exited on signal 11（段错误）

八、检测方法

# 检查版本
nginx -v

# 搜索危险配置
grep -rE 'rewrite\s+.*\$\d' /etc/nginx/
grep -rE '\?[^ ]*\$[0-9]' /etc/nginx/

# Kubernetes环境
kubectl exec -n ingress-nginx <pod> -- nginx -v

九、代码审计启示

1. 警惕两阶段处理：任何“先calc len → malloc → copy”的模式都是高危区。
2. 关注escape/encode/decode：长度会动态变化的场景极易出错。
3. 状态机共享风险：多阶段、多指令共享的engine状态是bug温床。
4. 正则捕获：用户可控输入+长度放大 = 经典溢出放大器。

NGINX Rift是“Length Confusion”类漏洞的经典教科书案例，类似问题还广泛存在于URL Parser、HTTP Parser、Chunked Encoding等场景。

十、总结与思考

CVE-2026-42945再次证明：基础设施代码的“稳定运行多年”并不等于安全。一个18年前留下的逻辑缺陷，就可能动摇整个互联网的根基。

对于运维和安全团队而言：

• 定期审计rewrite、location等高风险配置
• 保持核心组件及时更新
• 不要过度依赖“历史稳定”作为安全依据
• 在Kubernetes等云原生环境中，尤其重视sidecar/Ingress的版本管理

安全从来不是一劳永逸，而是持续的攻防博弈。

参考资料：

• 官方披露与技术细节（DepthFirst）
• F5 / NGINX 安全公告
• AlmaLinux、Red Hat 等厂商分析
• 公开PoC仓库

欢迎讨论与交流。

本文基于公开漏洞信息与代码审计整理，仅用于安全研究与防御目的。请在授权环境下进行测试。