Nginx再曝严重安全漏洞说明了什么?

2026年5月，Nginx再次曝出严重安全漏洞：CVE-2026-42945。

根据公开披露的信息，这个漏洞存在于 ngx_http_rewrite_module 中，属于典型的 Heap Buffer Overflow（堆缓冲区溢出）问题。攻击者可以通过构造特殊HTTP请求，在无需认证的情况下触发Nginx崩溃，甚至在某些条件下实现远程代码执行（RCE）。

更令人震惊的是：

这个漏洞已经在代码中潜伏了整整18年。

对于整个基础设施行业来说，这并不仅仅是一次普通的安全事件。

它实际上再次暴露了一个已经越来越明显的趋势：

基于C/C++这样的内存不安全语言构建网关系统，本质上无法彻底避免类似漏洞的持续出现。

而对于网关这种直接暴露在公网、每天承受海量恶意流量探测的基础设施来说：

“安全性”和“稳定性”，正在比“极致性能”变得更加重要。

一、一个18年的漏洞，说明了什么？

根据漏洞分析，CVE-2026-42945 的根本原因，是Nginx内部 rewrite 模块在处理PCRE正则捕获组时，发生了长度计算与内存拷贝之间的不一致，最终导致堆内存越界写入。

这其实是C/C++世界里最经典的一类问题：

• 缓冲区长度计算错误     
• 指针越界     
• 内存写穿     
• Use-after-free 
• Double free 
• Heap overflow 

问题在于：

这类漏洞并不是“某个程序员写错了代码”这么简单。

而是：

C/C++语言本身允许程序员直接操作裸内存，因此整个系统天然暴露在“内存安全”风险之中。

只要代码规模足够大、生命周期足够长、模块足够复杂，这类漏洞几乎一定会出现。

Nginx已经是全球最优秀的C语言基础设施项目之一：

• 代码质量极高     
• 社区成熟     
• 经历了二十多年生产验证     
• 拥有大量安全审计     

但即便如此，一个高危RCE漏洞仍然能够潜伏18年。

这说明：

“依靠工程规范避免内存漏洞”这件事，本身已经越来越接近不可能完成的任务。

二、为什么网关系统特别危险？

很多系统即便存在漏洞，风险也未必极高。

但网关不同。

无论是：

• API Gateway 
• Ingress Gateway 
• Load Balancer 
• AI Gateway 

它们都有一个共同特点：

直接暴露在公网。

这意味着：

1. 攻击面极大

攻击者无需认证。

只要能够发HTTP请求，就可以尝试触发漏洞。

这也是为什么几乎所有网关类RCE漏洞，都会被定义为高危甚至Critical级别。

2. 网关位于流量入口

网关一旦失守：

• 可以窃取流量     
• 可以篡改请求     
• 可以植入后门     
• 可以横向进入内网     
• 可以攻击后端服务     

很多企业认为：

“网关只是个转发组件。”

实际上：

网关是整个基础设施最核心的边界节点之一。

3. 网关的配置极其复杂

现代网关已经不只是：

• 七层代理     
• 负载均衡     

它们往往还承担：

• WAF 
• OAuth 
• JWT 
• Lua
  脚本 
• 路由改写     
• 动态策略     
• 灰度发布     
• 插件系统     
• AI流量调度 

复杂性正在指数级上升。

而复杂性，正是安全漏洞最大的来源。

三、历史已经反复证明：C/C++网关漏洞会持续出现

这并不是Nginx第一次因为内存问题曝出高危漏洞。

过去十多年里，Nginx已经多次出现：

• Buffer Overflow 
• Integer Overflow 
• Memory Corruption 
• Use-after-free 

而且不仅是Nginx。

另一个云原生时代最核心的网关项目 —— Envoy，也同样如此。

Nginx历史上的典型内存漏洞

1. CVE-2013-2028

这是Nginx历史上最著名的高危漏洞之一。

问题出现在 chunked encoding 处理逻辑中。

攻击者可以通过构造特殊HTTP请求，触发堆缓冲区溢出，进而实现远程代码执行。

这个漏洞当年影响极大，因为：

• 无需认证     
• 可远程触发     
• 影响公网Web服务器 

其本质，仍然是经典的C语言内存边界问题。

2. CVE-2021-23017

这是Nginx resolver模块中的一个1字节内存覆盖漏洞。

虽然看起来只是“1-byte overwrite”，但依然可能被利用实现RCE。

这种问题在Rust或Go中几乎不可能自然出现。

因为：

• Go没有裸指针运算 
• Rust有Borrow Checker 
• 两者都具备边界检查机制     

3. CVE-2026-42945

这次的问题更加具有象征意义。

因为：

一个18年都没有被发现的Heap Overflow，意味着“人工审计+测试”已经不足以保障C/C++基础设施的安全。

尤其在AI辅助漏洞挖掘越来越成熟之后，大量历史代码中的隐藏漏洞，未来可能会被更快速地发现。

Envoy也长期受到内存安全问题困扰

很多人会认为：

“Envoy属于现代云原生架构，因此天然更安全。”

但现实并非如此。

虽然Envoy在架构设计、可扩展性、热更新、服务治理等方面远远领先传统网关，但由于其核心仍然基于C++实现，因此同样长期受到内存安全问题的困扰。

过去几年，Envoy已经多次曝出：

• Heap Overflow 
• Use-after-free 
• Integer Overflow 
• Crash 
• Memory Corruption 

等问题。

这些问题说明：

即便是现代化C++工程体系，也无法从根本上消除内存安全风险。

Envoy历史上的典型内存漏洞

1. CVE-2019-9901：HTTP/2实现导致的资源耗尽与崩溃

这是Envoy较早期的高危漏洞之一。

攻击者可以通过构造特殊HTTP/2请求，导致Envoy出现异常资源消耗并最终崩溃。

虽然这个漏洞主要表现为DoS，但其根源仍然与底层内存与状态管理复杂性有关。

问题的关键在于：

• HTTP/2协议状态机极其复杂 
• C++实现中存在大量生命周期管理 
• 多线程与异步回调进一步增加了风险     

这也是为什么：

现代协议栈越来越容易成为内存漏洞高发区。

2. CVE-2021-43824：Use-after-free风险

该漏洞涉及Envoy在连接关闭与异步事件处理过程中的生命周期管理问题。

在特定条件下：

• 对象已经被释放     
• 但异步回调仍然继续访问该对象     

最终可能导致：

• 崩溃     
• 非法内存访问     
• 潜在远程代码执行风险     

这类问题正是C++最典型、最难彻底解决的问题之一：

Use-after-free

因为：

在复杂异步系统中，人脑很难完全推导所有对象生命周期。

而Rust之所以受到越来越多基础设施项目重视，一个核心原因就是：

Rust在语言层面直接禁止了绝大多数Use-after-free问题。

3. CVE-2023-35945：内存越界导致崩溃

该漏洞涉及HTTP头处理逻辑中的异常边界情况。

攻击者可以通过特殊请求触发：

• 越界访问     
• 崩溃     
• 服务不可用     

虽然最终没有形成完整RCE链，但本质仍然属于：

内存边界安全问题

而这种问题在C/C++项目中极其常见。

4. Envoy历史上频繁出现的Crash类漏洞

除了正式编号的CVE之外，Envoy历史上还长期存在大量：

• segmentation fault 
• invalid memory access 
• heap corruption 
• assertion crash 

修复记录。

尤其在：

• HTTP/2 
• gRPC 
• QUIC 
• filter chain 
• dynamic config 

等复杂模块中，问题更容易出现。

原因其实非常直接：

C++允许开发者手工控制对象生命周期，而复杂网关系统天然存在海量异步状态。

两者叠加之后：

即便工程体系再优秀，也很难完全避免问题。

Envoy的问题，其实不是Envoy的问题

这里有一个非常关键的认知：

Envoy的问题，并不意味着Envoy团队能力不足。

恰恰相反。

Envoy已经是全球工程质量最高的基础设施项目之一：

• Google / Lyft背景 
• CNCF毕业项目 
• 大规模生产验证     
• 大量安全审计     
• 持续Fuzz测试 

但即便如此：

内存问题仍然会不断出现。

这恰恰说明：

问题的根源，越来越不是“工程规范”，而是“语言本身”。

四、为什么Go和Rust正在成为网关的新方向？

这几年，一个非常明显的趋势是：

越来越多的新一代基础设施，正在主动远离C/C++。

包括：

• 云原生组件     
• API Gateway 
• AI Gateway 
• Service Mesh 
• Kubernetes生态 

大量项目开始转向：

• Go 
• Rust 

原因非常简单：

内存安全

这是Go和Rust最大的价值。

Go

Go通过：

• GC 
• Slice边界检查 
• 无裸指针默认访问     
• 内存模型限制     

消灭了绝大多数：

• Buffer overflow 
• Use-after-free 
• Double free 

问题。

Rust

Rust则更进一步。

通过：

• Ownership 
• Borrow Checker 
• 生命周期检查     

在编译阶段直接消灭大量内存错误。

这也是为什么：

微软、Google、AWS、Linux Kernel 都在全面推动Rust进入基础设施领域。

五、“性能第一”的时代正在结束

过去二十年，很多基础设施项目都在追求：

• 极致性能     
• 零拷贝     
• 极限QPS 
• 最低延迟     

因此大量系统选择了C/C++。

但今天，行业正在发生变化。

因为：

1. CPU性能已不是瓶颈

现代CPU性能相比十年前已经提升巨大。

很多网关场景：

• 真正瓶颈不在语言     
• 而在网络、上游服务、数据库     

Go网关即便性能比Nginx低20%，很多场景依然完全够用。

2. 稳定性远比极限性能重要

对于企业来说：

“每秒少处理10万请求”

和：

“被RCE攻破”

相比，哪个更严重？

答案显而易见。

3. 运维成本比性能更昂贵

一个高危漏洞带来的成本包括：

• 漏洞修复     
• 紧急升级     
• 流量切换     
• 安全审计     
• 停机风险     
• 合规风险     

这些成本，远高于CPU多消耗20%。

六、为什么BFE这类Go网关值得关注？

这几年，一个值得关注的趋势是：

越来越多国产基础设施开始主动采用Go实现网关。

例如：BFE官方项目

这类系统的核心价值，并不仅仅是：

• 云原生     
• 易扩展     
• Kubernetes友好 

更重要的是：

它们天然具备更高的内存安全性。

当然，这并不意味着：

“Go系统绝对没有漏洞”。

任何复杂系统都会有：

• 逻辑漏洞     
• 权限漏洞     
• 配置漏洞     

但至少：

最危险、最难防御、最容易直接RCE的“内存破坏类漏洞”，会大幅减少。

这对于公网网关来说，意义非常巨大。

七、AI时代，C/C++基础设施将面临更大压力

这次CVE-2026-42945，还有一个非常值得注意的细节：

研究人员表示，该漏洞是借助AI辅助发现的。

这意味着：

漏洞发现的成本正在急剧下降

过去：

• 需要资深安全研究员     
• 花费数周甚至数月     

今天：

• AI可以扫描大量历史代码 
• 自动推导危险路径     
• 自动生成PoC 

未来几年：

大量历史C/C++基础设施中的隐藏漏洞，可能会被持续挖掘出来。

而互联网入口层：

恰恰是最容易被攻击者利用的地方。

八、结语

Nginx这次18年的高危漏洞，并不是一个孤立事件。

它实际上反映了整个基础设施行业正在面对的一次深层转向：

在网络基础设施领域，“内存安全”正在成为比“极致性能”更重要的能力。

过去：

• C/C++代表高性能 
• 高性能代表最佳实践     

但未来：

• Go 
• Rust 
• Memory Safe Infrastructure 

可能才是真正的长期方向。

尤其对于：

• API Gateway 
• AI Gateway 
• Ingress 
• Load Balancer 
• Edge Gateway 

这些直接暴露在互联网边界的系统来说：

“不被攻破”，正在比“快20%”更加重要。

作者简介

章淼，博士，1994年进入清华大学计算机科学与技术系学习，2004年获得博士学位，2004年至2006年在清华大学留校任教，在清华期间曾参与中国第一代核心路由器的研制工作。2012年起在百度工作超过十年，聚焦云网络基础架构的研发工作，是BFE开源项目的发起人。在百度期间积极推动软件工程能力提升，曾担任百度代码规范委员会主席，2021年10月被授予百度代码规范委员会荣誉主席。2022年出版《代码的艺术：用工程思维驱动软件开发》。2023年4月起担任瑛菲网络CEO，聚焦研发面向云和大模型场景的现代化流量管理平台。

欢迎关注BFE开源项目的公众号，获得本项目的更多信息。谢谢！