NGINX Rift（CVE-2026-42945）：潜伏18年的高危堆溢出漏洞详解与修复指南

前言

2026年5月13日，一个潜伏在NGINX核心模块中长达18年的严重漏洞被正式公开——CVE-2026-42945，也被称为 NGINX Rift。该漏洞影响了从2008年至今几乎所有主流NGINX版本，CVSS v4.0评分高达9.2（Critical），属于堆缓冲区溢出类型。

作为全球使用最广泛的Web服务器和反向代理之一，NGINX一旦被攻破，后果可能波及数百万网站。本文将详细解析该漏洞的成因、风险、攻击条件以及最有效的应对措施，帮助运维和安全人员快速理解并处置。

漏洞背景与触发条件

NGINX的ngx_http_rewrite_module模块负责处理URL重写（rewrite）、条件判断（if）和变量设置（set）。CVE-2026-42945正是出在这个模块的脚本引擎（ngx_http_script.c）中。

核心触发条件（必须同时满足）：

配置中存在rewrite指令，且其后紧跟着另一个rewrite、if或set指令。
rewrite中使用未命名的PCRE捕获（如$1、$2等）。
替换字符串（replacement）中包含问号?（用于构造查询参数）。

在这种组合下，NGINX在计算目标缓冲区长度时采用了一种转义逻辑，而实际复制数据时却使用了另一种（NGX_ESCAPE_ARGS模式下的ngx_escape_uri），导致+、%、&等字符被过度扩展，写入长度远超预分配堆缓冲区，从而引发确定性堆溢出。

受影响版本：

NGINX Open Source：0.6.27 ~ 1.30.0
NGINX Plus：R32 ~ R36
众多衍生产品（如NGINX Ingress Controller、NGINX App Protect等）也受波及

潜在风险与攻击场景

1. 拒绝服务（DoS） 这是目前最容易实现的攻击方式。攻击者构造包含特殊字符的恶意URI，单次或多次请求即可导致NGINX worker进程崩溃并重启，形成崩溃循环，使整个服务不可用。对于作为边缘网关的NGINX而言，这意味着后端所有业务都将受到影响。

2. 远程代码执行（RCE） 在ASLR被禁用、绕过或系统随机化较弱的环境中，攻击者可利用可控的溢出数据实现任意代码执行，从而完全接管服务器。现代Linux系统默认开启ASLR提升了利用难度，但并非完全免疫，尤其在容器化、旧系统或特定部署场景下仍存在风险。

3. 影响范围 NGINX占据全球约三分之一的Web服务器市场，许多CDN、API网关、微服务入口都依赖它。此次漏洞完全发生在数据平面（请求处理阶段），无需任何认证即可触发，攻击面极广。

目前PoC已公开，野外利用风险正在快速上升。

修复与缓解措施

推荐方案一：立即升级（最彻底）

NGINX Open Source → 1.30.1 或 1.31.0 及以上版本
NGINX Plus → R36 P4、R32 P6 或更新版本

升级后务必重启NGINX，确保所有worker进程加载新二进制。大多数Linux发行版已推送安全更新，可通过包管理器一键升级：

# Debian/Ubuntu
apt update && apt upgrade nginx

# CentOS/RHEL/Rocky
yum update nginx    # 或 dnf update nginx

推荐方案二：配置层面临时缓解（无法立即升级时）

将所有存在风险的rewrite中的未命名捕获改为命名捕获（Named Captures）。此修改可完全避开漏洞代码路径。

易受攻击配置示例：

rewrite ^/users/([0-9]+)/profile/(.*)$ /profile.php?id=$1&tab=$2 last;

修复后安全配置：

rewrite ^/users/(?<user_id>[0-9]+)/profile/(?<section>.*)$ /profile.php?id=$user_id&tab=$section last;

操作建议：

使用grep -r “rewrite ” /etc/nginx/全面审计配置
重点检查包含?的rewrite规则及其后续指令
修改完成后测试业务是否正常

其他防御加固措施

确认系统已启用ASLR（cat /proc/sys/kernel/randomize_va_space 应为2）
在前端部署WAF或使用云防护过滤异常长URI和特殊字符请求
加强日志监控，关注worker进程异常退出
对无法升级的老版本实例，考虑临时关闭相关rewrite规则或使用其他方式实现相同功能

总结

CVE-2026-42945再次提醒我们：即使是久经考验的基础设施软件，也可能隐藏着长达十几年未被发现的高危缺陷。幸运的是，该漏洞的修复成本相对较低——升级或简单调整几行配置即可。

行动建议：立即自查所有NGINX实例，优先完成升级。对于公网暴露的生产环境，建议在24小时内完成修复。

安全从来不是一劳永逸，而是持续的过程。保持软件更新、定期审计配置、关注权威安全公告，才是长期防护的关键。

Post Views: 330