Envoy支持Go Wasm插件，就真的更安全了吗？

注：本文在大模型辅助下完成。

这几年，随着云原生和Service Mesh的发展，Envoy已经成为最主流的网关与代理之一。

与此同时，一个观点也开始越来越流行：

“Envoy已经支持Go Wasm插件，因此相比传统Nginx会更加安全。”

这个观点有一定道理。

因为：

Go Wasm插件，在设计上能够显著降低插件扩展层的风险。

但如果进一步推导成：

“Envoy因为支持Go Wasm，所以已经基本解决了内存安全问题。”

那可能会产生比较大的误解。

因为：

Go Wasm解决的，主要是“插件扩展层”的安全问题； 而不是Envoy主体作为C++程序的内存安全问题。

这两者，其实是完全不同的两个层级。

一、为什么大家开始重新关注网关的“内存安全”问题？

过去几年，“内存安全（Memory Safety）”正在重新成为基础设施领域最热门的话题之一。

尤其对于：

• API Gateway
• Ingress
• Service Mesh Gateway
• AI Gateway

这类互联网边界系统来说，行业对“内存安全”的关注度正在明显提升。

而这种变化的背后，其实有三个非常重要的原因。

1. NSA开始公开“劝退”C/C++

2022年以来，美国国家安全局（NSA）连续公开强调：

应尽可能从C/C++这样的“内存不安全语言（Memory Unsafe Languages）”，迁移到Memory Safe Languages。

NSA给出的理由非常直接：过去十多年里，大量严重漏洞本质上都来自 Buffer Overflow、Heap Overflow、Use-after-free、Double free 和 Memory Corruption。

而这些问题，几乎都与C/C++允许直接操作裸内存有关。

尤其对于网关、代理、Web Server、API入口这类直接暴露公网的系统来说，问题会被进一步放大。攻击者往往只需要发送一个特殊请求，就可能触发 Crash、内存破坏，甚至远程代码执行（RCE）。

这也是为什么，NSA开始把Memory Safe Infrastructure提升到了战略层面。

2. CVE-2026-42945再次引发行业警觉

真正让很多人重新开始讨论这个问题的，其实是最近Nginx曝出的CVE-2026-42945。

根据公开信息，这是一个典型的Heap Buffer Overflow漏洞，更关键的是，它已经在代码中潜伏了接近20年。

这其实非常值得行业警惕。

Nginx已经是全球最成熟、最广泛使用的网关之一：长期生产验证、大规模安全审计、顶级工程团队、超长生命周期。但即便如此，内存漏洞仍然可能长期隐藏。

这实际上说明：

对于C/C++这种允许直接操作内存的语言来说，即便工程能力再强，也很难彻底避免内存安全问题。

而Envoy与Nginx面临的，其实是同一种结构性风险。它们的核心数据面都建立在C/C++之上，共享同一类内存安全缺陷的土壤。Nginx的教训告诉我们：即便工程实践再成熟，C/C++的内存漏洞依然可能长期潜伏——Envoy也不会例外。

对于Nginx、Envoy、Ingress、API Gateway这类公网入口系统来说，这种风险会尤其敏感。

3.大模型正在急剧降低漏洞发现成本

还有一个容易被忽略，但可能影响更大的趋势：AI正在显著降低漏洞挖掘成本。

过去，发现复杂Heap Overflow或者Use-after-free，往往需要资深安全研究员进行长时间的代码分析、协议理解和复杂调试。

但今天，随着大模型能力不断增强，AI已经能够辅助：

• 分析复杂代码路径，识别危险的生命周期管理；

• 理解协议状态机，自动生成针对HTTP/2、QUIC等复杂协议的模糊测试（Fuzzing）输入；

• 在静态分析中标记潜在的UAF和双重释放模式。

这意味着，大量历史C/C++基础设施中的隐藏漏洞，未来可能会被更快、更大规模地发现。

而网关、Proxy、Ingress又恰恰是最容易被远程攻击的一类系统。因此，整个行业开始越来越关注：网关主体本身是否应该继续建立在“内存不安全语言”之上。

二、为什么Go Wasm插件会让人觉得“更安全”？

这个观点其实有一部分是正确的，因为Wasm本身确实是一个非常优秀的隔离机制。

1. Wasm最大的价值是Sandbox

传统插件（例如Native C++ Filter、Lua扩展）通常和宿主共享地址空间、生命周期和内存访问。因此，插件一旦出问题，很容易拖垮整个进程、破坏宿主内存、引发Crash。

而Wasm最大的特点之一就是Sandbox（沙箱）。Wasm运行时通常具备独立内存空间、严格边界检查、受控ABI，且无法直接访问宿主内存。

因此，即便插件崩溃，通常也更容易被限制在Sandbox内部。当然，Wasm sandbox并非绝对不可突破，历史上也出现过运行时逃逸漏洞，但相比Native插件体系，其攻击面已经大幅收缩。

2. Go进一步降低了插件风险

如果Wasm插件本身再使用Go实现，那么安全性还会进一步提升。

因为Go本身具备GC、Slice边界检查、更严格内存模型，且无默认裸指针访问。因此，很多经典问题会天然消失：

• Buffer Overflow
• Double Free
• Use-after-free

所以：

“Go Wasm插件比C++插件更安全”

这个结论，基本成立。

三、但Go Wasm并没有改变Envoy主体的安全属性

这里是整个问题最核心的一点。

很多人容易把“插件安全”直接等同于“整个网关已经安全”。但实际上，这两者完全不是一回事。

1. Envoy最危险的部分并不是插件

真正复杂、危险、容易被攻击的，往往是：

• HTTP/2解析
• QUIC
• TLS
• Header处理
• Stream状态机
• Connection管理
• Async Event Loop

这些网关核心路径，而不是业务插件。

问题在于，这些核心模块仍然运行在C++中。因此，真正高危的Heap Overflow、Use-after-free、Memory Corruption风险依然存在。

Envoy自身的历史已经多次印证了这一点。例如：

• CVE-2026-26311：Envoy HTTP Connection Manager的FilterManager在处理HTTP/2流时，因未正确检查saw_downstream_reset_标志，导致在流已被重置后仍调用Filter回调，形成典型的Use-after-free。攻击者可通过精心构造的HTTP/2帧序列触发Crash或状态破坏——这发生在Envoy最核心的请求处理路径上，与插件无关。
• CVE-2024-27919：Envoy的HTTP/2协议栈在处理CONTINUATION帧时，未能在Header Map超限后重置请求，导致攻击者可通过无限发送CONTINUATION帧引发内存耗尽，最终造成Denial of Service。这同样属于核心协议解析层的内存管理缺陷。

这些漏洞反复说明：

插件层更安全，并不意味着宿主已经安全。

2. Wasm Runtime本身也属于宿主的一部分

还有一个容易被忽略的问题：即便插件是安全的、Go代码没问题，但Envoy核心、Wasm Runtime、ABI桥接层仍然可能存在内存漏洞、生命周期问题和Crash风险。

尤其Wasm与宿主的数据交换本身也是复杂边界，一旦宿主的内存管理出现问题，Sandbox内部的插件再安全也无济于事。

四、Go Wasm真正解决的，其实是“扩展风险”

更准确地说，Go Wasm主要解决的是第三方扩展安全性。

也就是：

“插件不要轻易拖垮整个网关。”

这一点其实非常重要。因为现代网关越来越依赖动态扩展、自定义Filter、多租户插件和第三方逻辑。如果没有隔离机制，整个系统会非常脆弱。

因此，Wasm确实是网关架构的一次重要进步。它显著提升了：

• 插件隔离性

• 扩展稳定性

• 多租户安全性

这一点是毋庸置疑的。

五、如何走向真正的“内存安全网关”？

最近几年，越来越多团队开始尝试Go Gateway、Rust Proxy和Memory Safe Data Plane。

他们想解决的，已经不是插件安全，而是网关主体本身的内存安全。这是两个完全不同层级的问题。

需要承认的是，Envoy作为成熟的Service Mesh数据面，短期内不可能被完全替换。对于已经深度使用Envoy的团队来说，Go Wasm插件仍然有其现实价值——它能有效隔离不可信的第三方扩展，降低多租户场景下的爆炸半径。

但与此同时，一个更重要的范式转移正在发生：在新建系统或下一代网关的选型中，“主体内存安全”正在从“加分项”变成“必选项”。

1. Go和Rust，本质上是在解决同一个问题

对于网关系统来说，Go和Rust虽然路线不同，但目标其实是一致的：尽可能减少内存破坏类漏洞。

这才是最核心的变化。

过去，行业默认认为“高性能网关必须使用C/C++实现”。但最近几年，越来越多团队开始意识到：对于API Gateway、Ingress、AI Gateway、Edge Gateway这类公网入口系统来说，真正危险的并不是QPS少了20%或延迟多了几毫秒，而是RCE、Heap Overflow、Use-after-free、Memory Corruption这类能够直接导致系统被攻破的问题。

因此，越来越多新一代网关开始尝试Go Gateway、Rust Proxy、Memory Safe Data Plane，本质上都是在推动网关主体本身走向内存安全语言。

只有宿主本身具备内存安全能力，才能真正降低内存破坏、非法访问和生命周期错误所带来的系统性风险。

2. Go路线：更强调工程稳定性与开发效率

很多Go网关（例如BFE开源项目、部分AI Gateway、云原生控制面、Kubernetes生态组件）更强调：

• 工程效率

• 易维护

• 快速迭代

• 更低复杂度

• 更稳定的团队协作

Go通过GC、Slice边界检查、更严格内存模型和默认避免裸指针访问，已经天然消灭了大量Buffer Overflow、Double Free、Use-after-free问题。

对于很多网关场景来说，这已经能够显著降低安全风险。

而且，现代CPU性能已经非常强。很多企业越来越发现：网关真正的瓶颈，往往并不在语言性能本身。因此，相比极限性能，安全、稳定、可维护性开始变得更加重要。这也是为什么越来越多新一代网关开始采用Go。

3. Rust路线：进一步追求“高性能+内存安全”

Rust则代表另一条路线。它希望做到：

既保持接近C/C++的性能，又尽可能消灭内存安全问题。

因此，Rust更适合Proxy核心、高性能数据面、协议栈和极低延迟场景。

Rust通过Ownership、Borrow Checker和生命周期检查，在编译阶段阻止大量非法内存访问。因此，它在理论上能够进一步降低底层风险。

不过，Rust也存在学习曲线更陡、开发复杂度更高、工程门槛更高的问题。因此，并不是所有团队都会选择Rust路线。

4.真正的重点，其实不是Go还是Rust

这里其实有一个更关键的问题：

未来网关行业真正的变化，可能不是“Go vs Rust”。

而是：

是否继续使用“内存不安全语言”作为公网网关主体。

这才是核心。

因为对于API Gateway、Ingress、AI Gateway、Edge Gateway这类互联网边界系统来说，真正重要的是：

尽可能降低RCE、Heap Overflow、Use-after-free、Memory Corruption这类高危风险。

而在这一点上，Go和Rust虽然实现机制不同，但在“用内存安全语言替代C/C++网关主体”这一目标上，方向是一致的。

六、网关行业真正的变化，可能才刚刚开始

过去二十年，整个基础设施行业一直默认“高性能必须依赖C/C++”。

但今天，这个逻辑正在逐渐变化。尤其对于API Gateway、Ingress、AI Gateway、Edge Gateway这类互联网边界系统来说，越来越多企业开始意识到：

“不被攻破”，可能比“快20%”更重要。

因此，Go Wasm插件当然是一次重要进步。它显著提升了插件隔离性、扩展安全性和多租户稳定性。

但：

它并没有从根本上改变Envoy作为C++网关的内存安全属性。

对于已经使用Envoy的团队，Go Wasm仍然值得采用——它能帮你守住“扩展层”的防线。但如果你正在规划下一代网关，或者重新评估核心数据面的安全基线，那么需要思考的问题已经不是“选什么插件机制”，而是：

“网关主体本身，是否还应该继续用内存不安全的语言来构建？”

而整个行业真正的方向，可能正在逐渐走向：

• Go
• Rust
• Memory Safe Infrastructure

以及：

“默认安全”的下一代网关体系。

相关资料

[1]Nginx再曝严重安全漏洞说明了什么？，BFE开源项目，2026年5月

[2] 从一个隐藏 18 年的 Nginx 漏洞，看网关安全架构的演进，Higress, 2026年5月

作者简介

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