CVE-2025-55182 - React Server Components RCE

NOTE: 由 AI/Claude 编写

https://github.com/ejpir/CVE-2025-55182-bypass

TL;DR

CVE-2025-55182 是 React 的 Flight 协议中的一个严重 RCE 漏洞。该攻击链利用路径遍历 + 伪造 chunk 注入 + $B 处理器滥用来执行 Function(attacker_code)。

特别感谢 maple3142 提供的可用利用链！

---

The Exploit

攻击概述

该漏洞利用程序使用三个表单字段来构造恶意载荷：

1. 创建一个具有自引用 then 的伪造 chunk 对象（字段 1 $@0 → 字段 0）
2. 嵌入一个伪造的 _response，其 _formData.get 被设置为 $1:constructor:constructor
3. 触发 $B 处理器，该处理器调用 response._formData.get(response._prefix + id)
4. 路径遍历将 _formData.get 解析为 Function，从而执行 Function(code)

利用流程```

┌─────────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────────┘

### 关键组件

| 组件 | 用途 |
|-----------|---------|
| `then: "$1:__proto__:then"` | 自引用 thenable；第 1 块（`$@0`）指回第 0 块 |
| `status: "resolved_model"` | 使对象看起来像有效的 React chunk |
| `reason: -1` | 将 rootReference 设为 undefined（避免引用冲突） |
| `value: '{"then":"$B1337"}'` | 触发 `$B` 处理器的嵌套载荷 |
| `_response._prefix` | 包含 RCE 代码字符串 |
| `_response._chunks: "$Q2"` | 空 Map，防止 chunk 处理期间崩溃 |
| `_response._formData.get` | 通过 `$1:constructor:constructor` 指向 `Function` |

### 组件深入解析

#### 表单字段结构

该漏洞利用使用三个带有循环引用的表单字段：```
Field 0: {"then":"$1:__proto__:then", "status":"resolved_model", ...}
Field 1: "$@0"    ← references back to field 0
Field 2: []       ← empty array for _chunks Map

自引用 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!)

**Why this is critical:**

1. `then` resolves to `Chunk.prototype.then` - a real callable function
2. This makes the fake object a valid thenable
3. When awaited, JS calls `obj.then(resolve, reject)`
4. `Chunk.prototype.then` executes with fake object as `this`:```javascript
Chunk.prototype.then = function (resolve, reject) {
  switch (this.status) {  // this.status = "resolved_model" ✓
    case "resolved_model":
      initializeModelChunk(this);  // fake object passed!

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

**如果没有自我引用**，伪造的 `_response` 将永远不会被使用。自我引用使 `Chunk.prototype.then` 将攻击者的对象视为真正的 Chunk。

#### 两阶段 Thenable 触发器（`value`）

`value` 字段包含一个嵌套的 JSON 字符串，其中包含另一个 thenable：```json
{"then":"$B1337"}

阶段 1： 外部对象的自引用 then 触发分块处理

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

`_formData.get` 为 `"$1:constructor:constructor"` → `getOutlinedModel()` 解析为 `Function`。

于是变成：`Function(code + "1337")` → 有效的 JS，因为 `1337` 只是一个尾随表达式。

#### 防御性填充（`_chunks`）

伪造的 `_response` 需要一个有效的 `_chunks` 属性以防止崩溃：```
Form field "2": []           ← empty array
_chunks: "$Q2"               ← $Q = Map type, creates new Map([])

React 的内部代码在处理过程中可能会访问 response._chunks.get() 或 response._chunks.has()。空的 Map 可以满足这些调用而不产生错误，从而使执行流程能够到达易受攻击的 $B 处理程序。

---

易受攻击的代码路径

路径	函数	漏洞利用中的用途
路径遍历	getOutlinedModel()	将 $1:constructor:constructor 解析为 Function
伪造 _response 注入	initializeModelChunk()	使用攻击者的 chunk._response
$B 处理程序	parseModelString()	调用 _formData.get(_prefix + id) → RCE

decodeReply() 是入口点，其本身并不存在漏洞。

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

**伪造响应用法** (`initializeModelChunk()`):```javascript
value = reviveModel(
  chunk._response,  // Uses chunk._response directly!
  { "": rawModel },
  ...
);

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

---

## 修复 (19.2.1)

该补丁包含多项修复：

1. **`initializeModelChunk()` 中的 `RESPONSE_SYMBOL`** - 关键修复   ```javascript
   // BEFORE: chunk._response (attacker can set via JSON)
   value = reviveModel(chunk._response, ...);

   // AFTER: Symbol lookup (cannot be forged via JSON)
   var response = chunk.reason[RESPONSE_SYMBOL];
   value = reviveModel(response, ...);

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

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

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

---

影响与版本

影响评估

能力	状态	备注
原型链遍历	✓ 已确认	通过 $1:constructor:constructor
访问 Function 构造函数	✓ 已确认	无需 manifest
完整 RCE	✓ 已确认	通过伪造 chunk + $B 处理程序

受影响版本

• 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 规则无法可靠地检测此漏洞。了解这些局限性对于安全团队评估自身防御态势至关重要。

核心问题：多层编码

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

层	解析器	解码内容
JSON 结构	JSON.parse()	\uXXXX Unicode 转义
JavaScript 代码	Function() 构造函数	\uXXXX、\xXX、八进制、fromCharCode()

这导致了根本性的错配：WAF 看到的是编码后的字节，但应用程序看到的是解码后的字符串。

签名需要匹配的内容

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

字面量模式	Unicode 等价形式	WAF 检测
constructor	\u0063onstructor	绕过
__proto__	\u005f\u005fproto\u005f\u005f	绕过
resolved_model	\u0072esolved_model	绕过
$@（循环引用）	$\u0040	绕过

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