Nginx CVE-2026-42945漏洞分析及复现

2026年5月12日，NGINX 官方发布紧急安全公告，披露了一组潜伏长达 18年 的高危漏洞，其中最严重的 CVE-2026-42945（代号"NGINX Rift"） 的 CVSS v4.0 评分高达 9.2分（Critical）。

该漏洞影响从 2008 年发布的 0.6.27 版本 到最新的 1.30.0 版本，覆盖了 18 年间几乎所有 NGINX 部署。据 Netcraft 统计，NGINX 占据全球 Web 服务器市场 37.2% 的份额，这意味着超过 1.3亿个网站和API网关 直接暴露在威胁之下。

更令人担忧的是，漏洞利用门槛极低——无需任何认证，攻击者只需发送一个精心构造的 HTTP 请求，即可导致 NGINX worker 进程崩溃，甚至在特定条件下实现 远程代码执行（RCE），完全接管服务器。

一、漏洞介绍

漏洞概况

关联漏洞

除 CVE-2026-42945 外，本次还披露了另外两个漏洞：

影响规模

• • NGINX 占全球 Web 服务器市场的 37.2%
• • 受影响网站/API 网关超过 1.3亿个
• • 影响所有主流 Linux 发行版（Debian、Ubuntu、CentOS、RHEL 等）
• • 所有使用 NGINX 作为反向代理、负载均衡、API 网关、静态文件服务器的场景均受影响

利用场景

攻击者无需身份认证，只需向目标 NGINX 服务器发送一个精心构造的 HTTP 请求，即可：

1. 1. 拒绝服务（DoS） — 触发 worker 进程崩溃，导致服务不可用
2. 2. 信息泄露 — 通过堆溢出读取内存中的敏感数据
3. 3. 远程代码执行（RCE） — 在特定配置和系统环境下实现任意代码执行，完全控制服务器

二、原理分析

漏洞本质

CVE-2026-42945 的根源在于 ngx_http_rewrite_module 重写模块中一个极其隐蔽的逻辑错误——内部标志位管理错误。具体来说，漏洞位于 ngx_http_script_regex_replace 函数（文件：src/http/ngx_http_script.c）。

核心缺陷：is_args 标志位失控

NGINX 在处理 rewrite 规则时，使用一个叫做 is_args 的内部标志位来标记 URI 中是否包含查询参数（问号 ? 后的部分）。这个标志位会在遇到问号时被设置为 1。

问题出在以下环节：

当 rewrite 替换串中包含 ? 符号时：

1. 1. 第一遍扫描：计算目标缓冲区所需长度。此时 is_args=1，会额外加上 args 的长度
2. 2. 分配内存：按计算出的长度分配堆内存
3. 3. 第二遍扫描：实际拷贝数据。此时 is_args仍然为 1，但实际拷贝时 并没有拷贝 args 的内容

这就导致了一个经典的漏洞模式：分配的长度 > 实际写入的长度 + 后续操作，为堆缓冲区溢出创造了条件。

完整触发流程

漏洞触发流程客户端发送含特殊URI的HTTP请求NGINX匹配第一条rewrite规则替换串包含 '?' 且使用 1/2 捕获组否·正常处理无漏洞是·is_args = 1计算缓冲区长度（含args大小）分配堆内存 (len + args_len + 1)实际拷贝数据（未包含args内容）紧随其后有第二条rewrite/if/set指令否·正常结束无溢出是·is_args未被重置仍为1处理第二条指令再次使用错误is_args长度计算再次出错·堆缓冲区溢出覆写内存池指针·DoS或RCE

危险配置示例

所有配置了 rewrite 规则的 NGINX 都可能受影响，以下是几种 极其常见 的危险模式：

模式1：PHP 前端控制器（最广泛）

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    location / {
        # ❌ 第一条 rewrite：包含 ? 和 $1 捕获组
        rewrite ^/(.*)$ /index.php?$1 break;
        # ❌ 第二条 rewrite：紧随其后，触发漏洞
        rewrite ^/admin/(.*)$ /admin/index.php?$1 break;
    }
}

⚠️ 几乎所有 PHP 框架（WordPress、Laravel、ThinkPHP）的 Nginx 配置都存在此模式。

模式2：API 网关路由转发

location /api/v1/ {
    set $service "user-service";
    # ❌ 第一条 rewrite：包含 ? 和 $1
    rewrite ^/api/v1/(.*)$ /$1?$args break;
    # ❌ 第二条 if 指令：紧随其后，触发漏洞
    if ($request_method = POST) {
        proxy_pass http://$service:8080;
    }
}

模式3：URL 重定向

location /old/ {
    # ❌ 包含 ? 和 $1 捕获组的 rewrite
    rewrite ^/old/(.*)$ /new/$1?redirect break;
    # ❌ 紧随其后的 rewrite
    rewrite ^/old/static/(.*)$ /static/$1 break;
}

为什么潜伏了 18 年？

1. 1. 逻辑型漏洞，而非内存型：不像经典的缓冲区溢出（如 gets、strcpy），这个缺陷隐藏在标志位的管理逻辑中，常规的模糊测试难以触发
2. 2. 触发条件苛刻：需要连续两条 rewrite/if/set 指令，且第一条包含 ? 和捕获组，这在单个 location 中并不常见
3. 3. 编译时无警告：代码逻辑在语法层面完全合法，编译器不会报错
4. 4. 运行时无明显异常：大多数情况下只是内存被轻微覆写，不会导致立即崩溃

三、漏洞复现

接下来，我们虚拟机部署低版本的nginx。将下面脚本保存为setup.sh。

#!/bin/bash
set -e
cd "$(dirname "$0")"

echo "Building Docker image (compiles nginx from source)..."
docker compose -f env/docker-compose.yml build

echo ""
echo "Done. To run:"
echo ""
echo "  # Terminal 1 (server) — nginx runs with ASLR disabled (setarch -R):"
echo "  docker compose -f env/docker-compose.yml up"
echo ""
echo "  # Terminal 2 (attacker):"
echo "  python3 poc.py --cmd 'echo hello from depthfirst > /tmp/pwned'"
echo ""
echo "  # Verify RCE:"
echo "  docker compose -f env/docker-compose.yml exec nginx ls -la /tmp/pwned"
echo "  docker compose -f env/docker-compose.yml exec nginx cat /tmp/pwned"

执行下面命令，运行容器。

./setup.sh
docker compose -f env/docker-compose.yml up

接下来，我们利用大佬项目

https://github.com/cipherspy/CVE-2026-42945-POC

NC成功得到会话

NC成功得到会话

四、漏洞修复

官方修复版本

NGINX 官方已在以下版本中修复该漏洞：

🔗 下载地址：https://nginx.org/en/download.html

通用升级方法

对于使用官方源安装的 NGINX，根据不同操作系统执行以下命令：

Debian / Ubuntu（APT 源）

# 更新软件包索引并升级
sudo apt update
sudo apt upgrade nginx
# 或直接安装指定版本
sudo apt install nginx=1.30.1-1~$(lsb_release -sc)

CentOS / RHEL / Rocky Linux（YUM/DNF）

# 通过 EPEL 或 NGINX 官方源升级
sudo yum update nginx
# 或
sudo dnf update nginx
# 如果使用 NGINX 官方源
sudo yum install nginx-1.30.1

升级后验证

升级完成后，通过以下方式验证：

# 检查版本
nginx -v
# 应输出：nginx/1.30.1
# 检查配置
nginx -t
# 应输出：syntax is ok / test is successful
# 检查运行状态
curl -I http://localhost/
# 应返回 HTTP/1.1 200 OK

五、写在最后

CVE-2026-42945 再次提醒我们：即使是最成熟的基础软件，也存在潜伏多年的致命缺陷。NGINX 作为全球最流行的 Web 服务器之一，其代码库已历经近 20 年发展，但一个标志位的错误管理就可能导致 1.3 亿台服务器面临远程代码执行的风险。

对于运维人员和开发者来说，这次事件再次印证了 "及时更新" 的重要性。不要因为"系统运行正常"就推迟安全更新——漏洞就在那里，只是还没人发现而已。

更多精彩文章 欢迎关注我们

基础教程 欢迎关注