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，聚焦研发面向云和大模型场景的现代化流量管理平台。