TL博士
React2Shell (CVE-2025-55182) 造成关键性 RCE风险 横过 React 服务器组件 (RSC) 以及嵌入它们的框架，包括 Next.js因为漏洞存在于内部 RSC 在序列化和反序列化层，攻击者可以发送精心构造的HTTP请求并触发攻击。 未经身份验证的远程代码执行即使团队运行的是默认框架配置，也会出现这种情况。 Next.js 应用程序面临最高的曝光率，因为它们会被接受和处理。 React Flight 默认情况下通过 HTTP 传输有效载荷。
该缺陷影响多个版本。 React 服务器包攻击者无需自定义应用程序逻辑即可利用此漏洞。安全研究人员证实其可靠性接近 100%，早期扫描显示许多云环境都存在漏洞。 Next.js 实例。 各队必须立即修复补丁 并验证其完整的生态系统以缩小规模 React2Shell (CVE-2025-55182) 远程代码执行风险.
11 月 29 日，Meta 的漏洞赏金计划报告了一个严重漏洞，引发了整个 JavaScript 生态系统的紧急响应。
特定 CVE-2025-55182于12月3日披露，现称为 React2Shell 这是一个影响范围极广的最高级别漏洞。 React 服务器组件 以及包含这些漏洞的框架。最初，Next.js 被分配了一个单独的漏洞标识符 (CVE-2025-66478)，但后来 NVD 将其合并到主要的 React CVE 中，作为重复条目。
根本问题在于对可通过 HTTP 请求触发的序列化 RSC 有效负载的处理不安全。这使得恶意攻击者可以发送篡改过的 HTTP 请求，从而导致服务器端运行任意 JavaScript 代码。 由 React 反序列化.
CVE-2025-55182 概述
React 服务器组件已深度集成到现代框架中，并且在许多情况下默认启用。因此，应用程序可能会面临以下风险： React2Shell (CVE-2025-55182) 即使他们从未明确定义服务器函数端点，RSC 实现仍然存在，仅此就足以激活易受攻击的代码路径，并造成重大安全隐患。 RCE风险.
缺陷源于……的方式 React Flight 协议l 处理某些结构化有效载荷。旧版本会尝试遍历有效载荷中提供的对象路径，而不验证其结构是否有效或符合预期。攻击者可以操纵此过程，最终在服务器上执行代码。无需身份验证、特殊配置或应用程序特定的逻辑。由于此问题存在于开箱即用的配置中， standard 部署无需任何特殊条件即可公开。
漏洞利用是指攻击者发送恶意 HTTP POST 请求，滥用“vm.runInThisContext通过服务器操作实现的“机制”。虽然 React 没有直接暴露易受攻击的端点，但 Next.js 却暴露了，从而创建了一个真正的远程攻击途径。
Next.js 接受来自任何请求的 Flight 有效载荷，在未进行适当验证的情况下对其进行处理，并将其传递给 React 的反序列化器。该系统将这些外部输入视为可信输入，这使得攻击者能够实现某些目标。 远程代码执行 通过公开可访问的端点 拥有完整的Node.js进程权限 在目标服务器上。
由于默认配置仍然容易受到影响，因此严重性会显著增加。 React2Shell (CVE-2025-55182) 和结果 RCE风险。 一个 standard 您使用 Next.js 创建的应用程序 create-next-app 无需任何自定义代码或配置更改即可暴露自身。安全研究人员证实，该漏洞几乎 100% 可利用，并报告称 39% 的云环境运行着易受攻击的实例，而所有环境中 44% 运行着受影响的公开 Next.js 应用程序。 React2Shell.
了解 React2Shell
存在漏洞的版本涵盖多个发行版：
| 元件 | 受影响的版本 |
|---|---|
| react-server-dom-webpack | 19.0，19.1.0，19.1.1，19.2.0 |
| react-server-dom-parcel | 19.0，19.1.0，19.1.1，19.2.0 |
| react-server-dom-turbopack | 19.0，19.1.0，19.1.1，19.2.0 |
由于许多框架的核心都嵌入了 RSC 支持，应用程序往往会在不知情的情况下继承这些易受攻击的代码。任何包含这些包的框架或打包工具都可能使应用程序暴露于 React2Shell (CVE-2025-55182) 及其远程代码执行 (RCE) 风险之下。这包括：
- Next.js（应用路由）
- React Router RSC 预览
- Vite RSC 插件
- Parcel RSC 插件
- Redwood SDK
- 袜裤
- 世博会
Next.js 受影响尤为严重，因为它默认使用基于 HTTP 的 RSC 相关端点。以……开头的版本 14.3.0 金丝雀版本以及大多数 15.x 和早 16.x 版本中包含存在漏洞的实现。任何运行 Canary 版本的用户都可能受到影响。 14.3.0-canary.77 或者稍后应该 恢复到 稳定版 14.x 分支直到发布已修补的 Canary 版本为止。
已打补丁的 Next.js 版本 包括:
| 元件 | 已打补丁的版本 |
|---|---|
| Next.js | 15.0.5，15.1.9，15.2.6，15.3.6，15.4.8，15.5.7，16.0.7 |
公开的PoC和可靠的检测
漏洞披露后，大量所谓的概念验证开始流传。其中许多要么不准确，要么基于错误的假设。漏洞的最初发现者 Lachlan Davidson 公开证实了这一点。 react2shell GitHub 上流传的 PoC 与 React/Next.js 维护者私下分享的漏洞利用程序不符，而且他本人也提供了相关信息。 自有概念验证.
早期公开尝试的一个主要问题是，它们未能认识到剥削最终会成功。 standard Next.js 部署无需特定的应用程序逻辑或服务器端功能。
多家机构的安全研究人员强调，检测该漏洞不仅仅是识别 RSC 是否存在那么简单。Assetnote 团队发布了一份报告。 可靠的检测方法 配备 扫描器 无需使用任何漏洞利用逻辑即可确认问题。Metasploit 即将推出一项功能。 可用漏洞 针对此漏洞也存在同样的问题。
该检测方法利用了 React Server 如何处理对象属性引用，即使用冒号分隔符。 ReactFlightClientConfigBundlerWebpack.js/requireModule() 函数。当易受攻击的版本处理试图遍历不存在的嵌套对象路径的特殊结构化的多部分有效负载时，会触发可预测的错误响应。诊断请求会发送类似这样的引用模式。 `$1:a:a` 与空对象配对。存在漏洞的实现会尝试将其解析为对未定义值的嵌套属性访问，从而导致异常。服务器会返回 500 状态码，并在响应正文中包含一个独特的错误摘要模式。
export function requireModule<T>(metadata: ClientReference<T>): T {
let moduleExports = __webpack_require__(metadata[ID]);
if (isAsyncImport(metadata)) {
if (typeof moduleExports.then !== 'function') {
// This wasn't a promise after all.
} else if (moduleExports.status === 'fulfilled') {
// This Promise should've been instrumented by preloadModule.
moduleExports = moduleExports.value;
} else {
throw moduleExports.reason;
}
}
if (metadata[NAME] === '*') {
// This is a placeholder value that represents that the caller imported this
// as a CommonJS module as is.
return moduleExports;
}
if (metadata[NAME] === '') {
// This is a placeholder value that represents that the caller accessed the
// default property of this if it was an ESM interop module.
return moduleExports.__esModule ? moduleExports.default : moduleExports;
}
return moduleExports[metadata[NAME]];
}
面临 React2Shell (CVE-2025-55182) 和远程代码执行风险的组织应立即采取的行动
对您的代码库和已部署的应用程序进行全面扫描 查找存在漏洞的软件包版本。特别注意直接依赖 React 服务器的软件包、框架级 RSC 实现（Next.js、Waku、Redwood 等）、使用 `create-next-app` 或类似脚手架工具构建的应用程序以及可能包含过时基础镜像的容器化应用程序。
软件组成分析（SCA) 工具如 Xygeni 的 SCA 可以自动发现软件清单中受影响的依赖项。
立即修补：
请更新至已修复的版本，例如 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）以及任何包含 RSC 的框架包。这些更新引入了对 RSC 有效载荷处理的严格验证，并防止了可利用的不安全属性解引用。
自动化修复工具，例如 Xygeni的自动修复功能可以加速大型代码库的处理过程。
实施临时WAF保护：
当补丁程序在您的部署中传播时 pipeline立即启用Web应用程序防火墙规则以获得保护。主要云服务提供商已发布紧急规则集。 Cloudflare：当 React 流量被代理时，所有层级均可自动受到保护，以及 AWS、Akamai、Fastly、Google Cloud 具备类似的防御规则。立即启用这些控制措施，以便在过渡期间建立保护层。
监控可疑的HTTP流量：
配置日志记录和警报，以检测攻击尝试：格式错误或意外的 RSC Flight 协议负载、RSC 端点上出现异常的 500 错误模式、带有可疑 `Next-Action` 或 `Next-Router-State-Tree` 标头的 POST 请求、使用 multipart 负载重复请求 `/_next/` 路径。
核对您的软件物料清单：
许多框架会透明地捆绑 RSC 依赖项，使其在表面依赖项审查中不可见。请检查您的完整依赖项。 SBOM 确保：不存在对易受攻击的 React 服务器包的传递依赖，框架更新没有无意中引入旧的 RSC 实现。
关闭的思考
React2Shell 漏洞是近年来 JavaScript 生态系统中最严重的漏洞之一，这并非因为其攻击手段复杂，而是因为 RSC 漏洞深深渗透到当今的工具链中。现在整个生态系统都已发布了补丁，团队必须尽快将升级部署到生产环境。
如果您的应用程序直接或间接使用了 React 的服务器功能，则必须将此漏洞视为首要修复事项。
