React RCE 漏洞（CVE-2025-55182）：问题所在及成因

React RCE 漏洞（CVE-2025-55182）– 问题与成因

2025 年 12 月初公开的 React Server Components 漏洞（CVE-2025-55182，亦称 React2Shell / React4Shell）被评为 CVSS 10.0，是一项极其严重的安全问题，能够在 无任何身份验证 的情况下实现远程代码执行（RCE）。已公开 PoC 以及实际扫描与攻击尝试。

本文将 “谁、为何、风险范围” 进行更系统化的整理。

一览总结

核心问题 React Server Components（RSC）使用的 Flight 协议反序列化逻辑缺陷，导致攻击者发送被篡改的请求后，服务器可执行任意 JS 代码。
受影响的主要组件
react-server-dom-webpack / -parcel / -turbopack 19.0 / 19.1.0 / 19.1.1 / 19.2.0
这些组件内置于 Next.js 15.x、16.x、14.3.0-canary.77 之后版本（使用 App Router 时）
仅在浏览器运行的“传统 React SPA” RSC/Server Actions/服务器渲染均未使用的纯客户端 React 应用不受影响。
如果你曾使用 Next.js，立即需要做的事

检查项目中 react-server-dom-* / next 的版本
将 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 规则及异常迹象

本次发现的漏洞是什么

React 团队公开的内容可归纳为：

受影响对象：React Server Components（RSC）实现（react-server-dom-*）
漏洞位置：客户端向服务器传输 RSC 数据时使用的 Flight 协议解码（反序列化）逻辑
攻击方式：
攻击者发送 特制的 Flight 负载 至 RSC/Server Actions HTTP 端点
服务器在“信任”并反序列化该数据时，内部模块加载/对象创建逻辑被攻击者输入牵引
结果，服务器环境可执行任意代码（RCE）

关键点在于，无需登录/会话（Unauthenticated）即可攻击。若 Next.js RSC 服务器对外暴露，即从“互联网可访问的那一刻”起即成为扫描与攻击目标。

漏洞产生的精确条件

1. React/Next.js 版本条件

React RSC 相关包
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
受影响版本
19.0、19.1.0、19.1.1、19.2.0
补丁版本
19.0.1、19.1.2、19.2.1
Next.js（App Router 基础）
受影响：
- 14.3.0-canary.77 及以上
- 15.x、16.x（包含 RSC 的默认 App Router 结构）
- 补丁：
- 15.0.5、15.1.9、15.2.6、15.3.6、15.4.8、15.5.7、16.0.7 等

2. 架构/运行时条件

以下条件 全部满足 时，攻击可能性最高。

使用 RSC * Next.js App Router 或其他支持 RSC 的框架
服务器执行 React 代码 * Node.js 等环境下运行 React Server Components/Server Actions
HTTP 对外暴露 * 无论是互联网还是内部网络，只要攻击者能发送 HTTP 请求

相反，以下环境与本次漏洞几乎无关。

CRA/Vite 基础的 纯客户端 React SPA
完全不使用 RSC/Server Actions，仅将静态打包上传至 S3、CDN 等
“React 仅在浏览器中运行，服务器使用完全不同技术栈”（如 React + Django REST、React + FastAPI）

React‑DRF、React‑FastAPI 组合为何相对安全

将 React 与 Django REST Framework 或 FastAPI 等 Python 后端结合使用时，问题不会出现。原因如下。

React 代码不在服务器上执行 * React 仅在浏览器中运行，Django/FastAPI 仅提供纯 HTTP API * 服务器不需要理解 Flight 协议，也不解析 RSC
通信边界清晰 * React ↔ 服务器的通信通过 JSON/HTTP API 明确分离 * 服务器不会 require() React 的内部模块，也不会根据客户端传递的 metadata 加载模块
不使用 RSC/Server Actions/Flight 协议 * 本次漏洞的攻击面在于“服务器端 React 代码解析 RSC Flight 负载” * Django/FastAPI 完全不包含该代码

综上，“React + 服务器集成框架（Next.js 等）才可能出现此类结构性问题”。而已分离的 React‑SPA + REST API 组合根本不存在触发该漏洞的代码路径。

Flight 协议与服务器端原型污染

更技术化地说，漏洞遵循 Flight 协议反序列化 → 原型污染 → RCE 的典型流程。

1. 有问题的代码模式

概念化的函数示例：

// 漏洞版本（概念代码）
export function requireModule<T>(metadata: ClientReference<T>): T {
  const moduleExports = parcelRequire(metadata[ID]); // 模块加载
  return moduleExports[metadata[NAME]];              // 直接使用客户端输入
}

metadata[ID]：决定加载哪个模块
metadata[NAME]：决定访问该模块的哪个 export

此处 metadata[NAME] 未做任何验证。攻击者将其改为 __proto__、constructor 等敏感键，即可在模块 export 之外触及对象原型链。

2. 原型污染 → RCE

服务器代码在某处执行“普通对象创建”时，已污染的 Object.prototype 属性会随之附加。
若该属性链中包含 spawnSync('sh') 等 shell 执行逻辑，通过新创建的对象即可执行代码。
攻击者仅需一次 HTTP 请求即可实现远程代码执行。

实际修复了什么

React 侧的补丁核心是 “不再盲目信任客户端传递的值”。

最典型的改动是 requireModule 函数。

// 补丁后（概念代码）
export function requireModule<T>(metadata: ClientReference<T>): T {
  const moduleExports = parcelRequire(metadata[ID]);

  // 👇 确认客户端传递的 NAME 是否为实际 own property
  if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
    return moduleExports[metadata[NAME]];
  }

  return undefined as any;
}

这一行即可阻止：

__proto__、constructor 等原型链键因非 own property 而被拒绝访问。
从而 切断了原型污染到 RCE 的关键攻击向量。

补丁中还包括：

加强 Flight 负载结构校验
限制特定危险字段的使用
对相关代码路径添加额外防御逻辑

核心在于上述“验证添加”。

Next.js 将 React 扩展至服务器时产生的结构冲突

React 原本是“浏览器端 UI 库”。但随着 RSC 与 Server Actions 的出现，React 已不再仅限浏览器。

Next.js 将这些功能整合，形成：

客户端组件 + 服务器组件 + 服务器动作 在同一应用中无缝交互。
结果，客户端发送的数据可直接触及服务器模块加载/代码执行路径。

安全模型随之失衡。

前端假设迁移至服务器的问题

前端环境通常：

代码打包 静态且不可变
模块加载在构建时确定
运行时用户不更改模块名或 export 名

因此，

moduleExports[userInput]

在前端看似不危险。

但在服务器：

输入始终是 不可信网络数据
模块加载/对象创建直接关联服务器资源、文件、进程
在反序列化/动态加载中混入用户输入即为 RCE 典型候选

真正需要的安全模型是：

对 Flight 负载进行 严格的模式校验
对客户端可控值采用 白名单 访问
采用 HMAC 等 请求签名/完整性校验
在服务器端假设 RSC 始终接收不可信输入

但实现时，传统 React（仅前端）信任模型被直接迁移至服务器，导致本次结构性漏洞的暴露。

结论：前后端边界模糊时，安全模型需重新设计

本次 React/Next.js 漏洞不只是单一 bug，而是：

React 从前端库演变为服务器执行路径，导致原有“前端信任模型”失效。

传统 React + DRF/FastAPI 结构：

“React 仅在浏览器中运行”
“服务器仅提供 HTTP API”

在此架构下，类似漏洞无触发点。

相反，Next.js 之类的 服务器端 React 序列化/反序列化协议深度耦合，功能与 DX 提升的同时，必须同步设计新的安全模型与校验机制。

未来，前后端边界消失的框架将继续出现。本事件提醒我们：便利性与安全边界必须同步优先。