作者：澄潭
CVE-2026-42945，CVSS 9.2，影响 Nginx 0.6.27 到 1.30.0，一个存在了 18 年的堆溢出漏洞。它不是什么精巧的攻击链，而是一个最朴素的状态管理疏忽。但正是这种“低级错误”，让我们有机会重新审视网关的安全设计哲学。
漏洞原理：两阶段执行之间的状态幽灵
▍Nginx 的脚本引擎
Nginx 的 rewrite 和 set 指令不是简单的字符串替换。它们被编译成一系列操作码（opcodes），由 Nginx 内部的脚本引擎执行。这个引擎采用了一个经典的性能优化设计——两阶段执行（two-pass）：
- 第一次执行（长度计算）：遍历所有操作码，计算出最终字符串的总长度，一次性从内存池分配刚好够大的 buffer。
- 第二次执行（数据拷贝）：再遍历一遍，把实际数据写入刚分配的 buffer。
这个设计避免了反复 realloc，在 C 语言级别是很合理的优化。但它有一个隐含的前提条件：两次遍历看到的引擎状态必须完全一致。
▍致命的状态泄漏
考虑这个再普通不过的 Nginx 配置：
location ~ ^/api/(.*)$ { rewrite ^/api/(.*)$ /internal?migrated=true; set $original_endpoint $1; }
rewrite 的替换串里有一个 ?。Nginx 看到 ?，会认为后面的部分是 query string，于是调用 ngx_http_script_start_args_code()，把引擎的 e->is_args 标志永久设为 1。
接下来执行 set $original_endpoint $1。这里引用了正则捕获组 $1，触发 ngx_http_script_complex_value_code()。关键来了——这个函数为了计算变量值的长度，创建了一个全新的、零初始化的子引擎 le：
ngx_memzero(&le, sizeof(ngx_http_script_engine_t)); // 完全清零 le.ip = code->lengths->elts;
因为 le.is_args 是 0，长度计算时走了“不转义”的分支，返回原始长度。
但拷贝阶段用的是主引擎 e，它的 is_args 还是 1。于是拷贝代码走了“需要转义”的分支，把 URI 中的 +、&、= 等字符从 1 字节展开成 3 字节（如 + → %2B）。
分配了 raw_size 的 buffer，写入了 raw_size + 2*N 字节的数据。堆溢出。
▍为什么 18 年没被发现？
这个问题比漏洞本身更有意思：
1. 触发需要三重条件同时满足：rewrite 带 ?、set 引用捕获组、请求 URI 包含大量需要转义的字符（+&=）。缺一个都不会溢出。
2. 大部分溢出是无声的：Nginx 的内存池是块状分配的，小溢出大概率落在 padding 或相邻 chunk 的 metadata 上，不会立即 crash。
3. Worker 崩溃不等于漏洞暴露：多进程架构下，worker crash 后 master 自动拉起新 worker，运维很难注意到偶尔的 segfault 是攻击还是偶发 bug。
4. two-pass 状态一致性不在审计视野内：静态分析工具检查内存安全，人工审计检查逻辑正确性，但“两个执行阶段之间的隐式状态契约被打破”这种问题，两者都很难捕获。
状态机的隐式契约被新功能打破了，而这份契约从来没被写下来过。2008 年写 rewrite 引擎时，is_args 的语义是“当前在处理 query string 部分”，设了就不需要重置——因为同一个处理流程里不会再次进入 complex value 逻辑。后来 set 指令支持了捕获组引用，才打破了这个假设。
根因：指令式配置的内在风险
Nginx 的 rewrite、set、if 等指令，本质上是在用配置语言模拟一门命令式编程语言。它有变量赋值、正则捕获、条件分支、循环（last/break），甚至有隐式的状态机。
这种设计在灵活性上是成功的——你几乎可以用 nginx.conf 实现任意的请求处理逻辑。但它也带来了根本性的问题：
指令之间的交互效应（interaction effect）是不可预测的。rewrite 改了引擎状态，set 读到了被改过的状态，没有任何文档或机制来约束这种跨指令的状态传播。这不是 Nginx 独有的问题，所有试图把编程能力塞进配置语言的系统都会遇到——只是在 Nginx 这里，后果是 RCE。
Envoy 的安全哲学：声明式配置
Envoy 选择了完全不同的路线。它的配置是声明式的：
route: match: regex: "^/api/(.*)$" rewrite: regex_rewrite: pattern: regex: "^/api/(.*)$" substitution: "/internal/\\1"
没有变量、没有赋值、没有状态机。每个路由规则是独立的、自包含的。rewrite 的匹配和替换在一条规则里完成，不存在“先 rewrite 改了全局状态，后面 set 读到脏状态”的可能。
这种设计从根本上消除了状态泄漏类漏洞的攻击面。Envoy 的 route 配置不需要维护跨规则的引擎状态，自然也就不存在两阶段不一致的问题。
但声明式配置也有代价——灵活性不足：
- 捕获组只能在当前规则的 substitution 里用，不能保存成变量传给后续逻辑。
- 无法表达“先 rewrite URI，再把捕获组注入到请求 header 传给上游”。
- query string 的操作能力有限——
query_parameters只是匹配条件，不是改写工具。 - 没有条件分支和循环，复杂的请求处理逻辑无法表达。
对于简单的路由重写，Envoy 绰绰有余。但对于从 Nginx 迁移过来的复杂配置，尤其是那些依赖 rewrite + set + 捕获组传递的场景，Envoy 原生的 route 配置力不从心。
Higress WASM 插件：用代码替代指令
Higress 的 WASM 插件机制提供了一个优雅的解法——既然指令式配置有状态管理的隐患，声明式配置又不够灵活，那就用真正的代码来解决问题。
以 nginx rewrite + set 的等价能力为例，一个 Higress WASM 插件的实现大概是这样的：
func onHttpRequestHeaders(ctx wrapper.HttpContext, config PluginConfig) types.Action { // 1. 获取请求 path path, _ := proxywasm.GetHttpRequestHeader(":path") pathPart, query := splitPathQuery(path) // 2. 正则匹配 for _, rule := range config.Rules { matches := rule.Regex.FindStringSubmatch(pathPart) if matches == nil { continue } // 3. 构建新 path（替换捕获组） newPath := expandCaptures(rule.Replacement, matches) // 4. 处理 query string newQuery := mergeQuery(query, rule.QueryAppend, rule.QueryTemplate, matches) // 5. 保存变量（等价于 nginx set） for _, v := range rule.SetVars { value := matches[v.CaptureGroup] // 给后续插件用 proxywasm.SetProperty([]string{v.Name}, []byte(value)) // 给上游服务用 proxywasm.AddHttpRequestHeader("X-Rewrite-"+v.Name, url.QueryEscape(value)) } // 6. 写回修改后的 path fullPath := joinPathQuery(newPath, newQuery) proxywasm.ReplaceHttpRequestHeader(":path", fullPath) if rule.Break { break } } return types.ActionContinue }
这段代码做的事情和 Nginx 的 rewrite + set 完全等价，但有几个本质区别：
▍1. 没有两阶段状态不一致的陷阱
每个请求进来，插件函数被调用一次。path 读一次、正则匹配一次、新路径算出来、写回。不存在“先算长度再拷贝”的两阶段设计，自然不存在两阶段状态不一致的可能。
▍2. 运行在 WASM 沙箱中
这是最关键的一点。WASM 插件运行在一个沙箱化的虚拟机里：
- 内存隔离：插件的内存空间与网关进程完全隔离。即使插件代码有 buffer 计算错误，溢出也只发生在 WASM 虚拟机的线性内存中，不会影响宿主进程（Envoy）的堆。
- 能力受限：WASM 插件只能通过 Proxy-WASM SDK 提供的 API 与网关交互——读写 header、读写 property、发 HTTP 请求。它不能直接操作宿主进程的内存，不能调用宿主的函数，不能访问文件系统。
- 故障隔离：插件 panic 或崩溃，影响范围仅限于当前请求。不会导致整个 worker 进程 crash，更不会导致 RCE。
对比 Nginx 的 C 模块——任何内存错误都是直接发生在 worker 进程的地址空间里，堆溢出可以直接覆盖相邻的函数指针，自然的攻击路径就是 RCE。
▍3. 代码逻辑是显式的
Nginx 的指令之间有隐式的状态传播（is_args flag 就是一个例子），这种传播既没有文档，也不容易从配置文本推断出来。
WASM 插件里，所有逻辑都是显式的 Go 代码。变量的赋值和传递一目了然，不存在“一个指令的副作用悄悄影响另一个指令行为”的可能。代码审查和测试都比审查 Nginx 配置容易得多。
安全架构的三个层次
从这个漏洞出发，我们可以看到网关安全架构的三个层次：
这不是说 Envoy 或 Higress 没有漏洞。任何软件都有 bug。但不同的架构设计决定了漏洞的爆炸半径：
- Nginx 指令式的状态泄漏 → 宿主进程堆溢出 → RCE。
- Envoy 声明式的配置 → 即使有 bug 也是配置解析层面，不涉及运行时状态泄漏。
- Higress WASM → 即使插件有 bug，也困在沙箱里，最坏情况是当前请求 500。
写在最后
CVE-2026-42945 不是最后一个“隐藏在配置语言中的安全漏洞”。任何试图把图灵完备的能力塞进配置格式的系统，都会面临状态管理的复杂性。Nginx 的 rewrite 模块在 2008 年是合理的工程选择，18 年后的今天，我们有更好的选择。
Envoy 用声明式配置消除了状态泄漏的攻击面，但牺牲了灵活性。Higress 的 WASM 插件在保留灵活性的同时，通过沙箱隔离从根本上限制了漏洞的影响范围。
用代码替代指令，用沙箱替代信任。这可能是网关安全演进的正确方向。
如果你正在从 Nginx 迁移到 Higress，Higress 社区已经有了一个 nginx-rewrite-compatible[1]WASM 插件，完整覆盖了 rewrite + set 的所有能力，可以直接替换存在漏洞的 Nginx 配置。
参考资料：
[1] nginx-rewrite-compatible
[2] CVE-2026-42945 详细分析
https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability
[3] Higress WASM 插件开发文档
