Java基础、中级、高级、架构面试资料
    你的位置：业余草 > 业余杂谈 > Nginx 惊现 RCE 漏洞，一条 HTTP 请求，影响全球 1/3 网站

    Nginx 惊现 RCE 漏洞，一条 HTTP 请求，影响全球 1/3 网站

    业余杂谈 herman 26浏览
    公告：“业余草”微信公众号提供免费CSDN下载服务(只下Java资源)，关注业余草微信公众号，添加作者微信：xttblog2，发送下载链接帮助你免费下载！
    本博客日IP超过2000，PV 3000 左右，急需赞助商。
    极客时间所有课程通过我的二维码购买后返现24元微信红包，请加博主新的微信号：xttblog2，之前的微信号好友位已满，备注：返现
    受密码保护的文章请关注“业余草”公众号，回复关键字“0”获得密码
    所有面试题(java、前端、数据库、springboot等)一网打尽，请关注文末小程序
    视频教程免费领
    【腾讯云】1核2G5M轻量应用服务器50元首年，高性价比，助您轻松上云

    随着 AI 的发展，现在找程序漏洞的效率得到了大大的提升。

    不管是 Java 生态里的 Spring 框架，Spring AI 框架，Spring Boot 框架等，最近的常规更新，都顺带修复了不少 CVE。我想这里面少不了 AI 的一些功劳。

    与此同时，AI 本身的一些漏洞也被发现了，比如今日就传出 DeepSeek 出现了一个 P0 级大漏洞，具体可以参见这篇文章《突发，DeepSeek 爆出重大 P0 级会话泄露 bug！》。

    正在我们吃瓜的时候，Nginx 今日也惊曝出了一个隐藏 18 年之久的“老坑”，仅需一条 HTTP 请求就能拿下服务器，全球三分之一网站面临威胁。

    如果你的或你们公司的服务器在 2008 年之后部署过 NGINX，那么恭喜你我他，很可能大家已经被“盯上”了整整 18 年了。

    两天前，也是 2026 年 5 月 13 日，安全研究机构 depthfirst 联合 F5 披露了一个编号为 CVE-2026-42945 的 NGINX 严重漏洞，代号 NGINX Rift，CVSS v4.0 评分高达 9.2（严重级）。攻击者无需任何认证，只需发送一条精心构造的 HTTP 请求，就可能实现远程代码执行（RCE），直接控制你的服务器。

    更令人脊背发凉的是，这段有问题的代码，从 2008 年起就藏在 NGINX 代码库里了，整整潜伏了 18 年。18 年间就没人发现，直到最近。我有理由相信，这次还是 AI 的功劳。

    文章配图参见 https://mp.weixin.qq.com/s/O8K8rZagP3YKz7rGGilGUA。

    18 年前的定时炸弹

    果不其然，我看了一些老外的讨论，这个定时炸弹的发现过程果真还是 AI 自动化扫描 6 小时揪出的“老狐狸”。

    2026 年 4 月 18 日，depthfirst 团队使用其内部自主安全分析系统对 NGINX 源代码进行扫描。仅用 6 小时，系统就识别出 5 个安全问题，其中 4 个获得 NGINX 官方确认。

    最严重的 CVE-2026-42945 可追溯到 2008 年，影响 NGINX 开源版 0.6.27 至 1.30.0 的几乎所有标准构建版本。由于 NGINX 承载全球约 三分之一的网站，这次事件影响面极其广泛。

    这个漏洞出现的技术根因是两阶段执行的“状态错位”。

    漏洞出在 ngx_http_rewrite_module 模块中，NGINX 中负责处理 rewrite 指令的脚本引擎。

    这个引擎在处理 rewrite 规则时，采用两遍执行流程。

    • 第一遍（长度计算）：用全零初始化的子引擎计算输出字符串长度，然后分配对应大小的内存缓冲区。
    • 第二遍（数据拷贝）：用主引擎执行，把数据实际写入第一遍分配好的缓冲区。

    被发现出问题的核心在于，两遍之间的内部状态不一致。

    当 rewrite 指令的替换字符串中含有问号（?）时，引擎内部的 is_args 标志位会被置为 1，但这个标志在两遍之间不会被重置。

    • 第一遍计算长度时，用的是未转义的原始长度（1 个字符 = 1 字节）来分配内存；
    • 但第二遍实际写数据时，主引擎会对 URI 中的特殊字符进行转义扩展，一个特殊字符可以从 1 字节膨胀到 3 字节（如 %XX 编码）。

    其造成的结果是，实际写入量远超已分配的缓冲区大小，直接造成堆缓冲区溢出。

    用大白话说就是，预算按原价算，结账时却按三倍价收，钱包（缓冲区）直接撑爆。

    全球三分之一网站中招

    这个漏洞的影响范围非常的广，预计全球三分之一网站受影响。

    受影响版本清单

    根据 F5 官方公告和 depthfirst 研究报告，以下版本均受影响。

    产品受影响版本
    NGINX 开源版0.6.27 至 1.30.0
    NGINX PlusR32 至 R36
    NGINX Instance Manager2.16.0 至 2.21.1
    F5 WAF for NGINX5.9.0 至 5.12.1
    NGINX App Protect WAF4.9.0 至 4.16.0、5.1.0 至 5.8.0
    NGINX Ingress Controller3.5.0 至 3.7.2、4.0.0 至 4.0.1、5.0.0 至 5.4.1
    NGINX Gateway Fabric1.3.0 至 1.6.2、2.0.0 至 2.5.1

    据威易网报道，超过 254 万中国网站可能受影响。

    漏洞触发条件

    并非所有 NGINX 服务器都“裸奔”，漏洞触发需要三个条件同时满足。

    1. 同一 location 上下文中连续使用 rewrite + set 指令；
    2. rewrite 替换字符串中包含问号 ?；
    3. set 指令引用正则捕获变量（如 $1、$2）。

    典型高危配置示例如下所示。

    location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

    这种配置在处理旧版 URL 迁移、API 网关路由时非常常见，却恰恰成了攻击入口。

    漏洞复现

    下面简单说一下这个漏洞的复现，从 DoS 到 RCE 的完整链条。

    拒绝服务（DoS）复现

    研究人员已公开 PoC，演示了漏洞触发后 NGINX Worker 进程崩溃并被 Master 进程重启的过程。

    # 运行 PoC 前
root       7  nginx: master process
nobody    99  nginx: worker process

# 运行 PoC 2 秒后
root       7  nginx: master process
nobody  2693  nginx: worker process  ← Worker PID 改变，说明原进程已崩溃重启

    通过构造包含大量加号（+）等特殊字符的 URI，可以强制转义函数将每个字节扩展为三个字节，从而精准控制溢出大小。

    远程代码执行（RCE）原理

    depthfirst 团队开发了完整的 RCE 概念验证，利用链非常精妙。

    1. 堆布局控制：利用 NGINX 多进程架构（Worker 从 Master fork，内存布局确定），通过”跨请求堆风水”技术精准控制堆布局；
    2. 内存池覆盖：溢出覆盖相邻内存池的 cleanup 指针；
    3. 伪造结构体喷射：通过 POST 请求体喷射包含 system() 函数指针的伪造 ngx_pool_cleanup_s 结构体；
    4. 触发执行：关闭受害者连接，触发 ngx_destroy_pool 遍历 cleanup 链表，执行攻击者注入的命令。

    验证的一个关键点是，在关闭 ASLR（地址空间布局随机化）的系统上，可实现稳定的未认证 RCE。即使 ASLR 开启，攻击者也可通过重复请求逐步覆盖指针字节，尝试绕过防护。

    修复建议

    漏洞发现后，各大安全机构以及社区里，都推荐立即行动，刻不容缓。

    修复建议方面，我综合了社区里的相关讨论，整理了 3 个方案，供大家参考！

    方案一，首选升级版本

    F5 已于 2026 年 5 月 13 日发布安全补丁，强烈建议立即升级。

    • NGINX 开源版：升级至 1.30.1 或 1.31.0
    • NGINX Plus：升级至 R36 P4+ 或 R32 P6+

    方案二，配置级临时缓解

    若你使用的是 OpenResty、宝塔面板等衍生版本，暂无官方补丁，无法立即升级时，可手动修改配置。

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

    # 危险写法（未命名捕获）
location /api/ {
    rewrite ^/api/(.*)$ /v2/index.php?data=$1;
    set $tracking_id $1;
}

# 安全写法（命名捕获）
location /api/ {
    if ($uri ~ ^/api/(?<captured_data>.*)$ ) {
        set $tracking_id $captured_data;
        rewrite ^/api/.*$ /v2/index.php?data=$captured_data break;
    }
}

    涉及的原理是，使用命名捕获组（?<name>）可规避该特定的溢出逻辑。

    方案三，系统级加固

    • 确保 ASLR 开启：执行 cat /proc/sys/kernel/randomize_va_space，确认返回值为 2。这虽不能阻止溢出，但能大幅增加 RCE 难度；
    • 监控异常请求：关注包含大量 +、%、& 等可转义字符的异常 HTTP 请求 URI，以及 POST 请求体中的可疑二进制结构。

    18 年老坑为何今天才被发现

    这次事件最值得反思的，是漏洞的发现方式，depthfirst 的自动化系统仅用 6 小时就找到了这个隐藏 18 年的问题。

    这揭示了一个残酷现实。

    传统人工程码审计，面对 NGINX 这类数百万行 C 语言代码的复杂项目，早已力不从心。

    即使是运行超过十年的“稳定”开源组件，也可能隐藏致命缺陷。对于企业架构师和安全工程师而言，这再次印证了“深度防御（Defense in Depth）”与“及时补丁管理”的基石地位。

    时间线回顾

    下面这个表格是这次漏洞发现的整个时间线。

    日期事件
    2026-04-18depthfirst 自动化系统扫描 NGINX 源码，发现 5 个问题
    2026-04-21通过 GitHub 安全公告向 NGINX 报告
    2026-04-24NGINX 确认其中 4 个问题
    2026-04-28通知 NGINX 已开发出可运行的 RCE PoC
    2026-05-05向 NGINX 分享 RCE PoC 及演示视频
    2026-05-13F5 发布 NGINX 安全公告，漏洞公开

    结语

    CVE-2026-42945 是一次教科书级的“老漏洞新发”案例。它提醒我们，在互联网基础设施的核心组件中，没有“足够安全”的过去，只有“尚未发现”的隐患。

    如果大家的生产环境还在运行 NGINX 1.30.0 及以下版本，且配置中使用了 rewrite + set 的组合，建议大家立刻去升级。

    由于相关 PoC 已公开，攻击只是时间问题。而 AI 带来的改变或影响，以及涉及到漏洞安全领域了。

    业余草公众号

    最后，欢迎关注我的个人微信公众号：业余草（yyucao）！可加作者微信号：xttblog2。备注：“1”，添加博主微信拉你进微信群。备注错误不会同意好友申请。再次感谢您的关注！后续有精彩内容会第一时间发给您！原创文章投稿请发送至532009913@qq.com邮箱。商务合作也可添加作者微信进行联系！

    本文原文出处：业余草： » Nginx 惊现 RCE 漏洞，一条 HTTP 请求，影响全球 1/3 网站

    相关文章推荐