就在上周 React 团队刚刚紧急修复了一个可导致远程代码执行（RCE）的严重漏洞后，安全研究人员又在 React Server Components（RSC）中发现了两个新的安全问题——一个高危的拒绝服务（Denial of Service, DoS）漏洞，以及一个中危的源码泄露（Source Code Exposure）漏洞。这些新漏洞虽然不支持远程代码执行，但仍然可能对使用 RSC 的应用造成显著影响。咱今天就来和大家聊聊这次披露的细节、受影响范围，以及如何快速应对。
安全的世界总是这样，一波未平，一波又起。但每一次修补，都是我们向更稳健系统迈出的一步。
拒绝服务：无限循环让服务器“卡死”
此次披露的两个高危 CVE（CVE-2025-55184 与 CVE-2025-67779）都指向同一个问题：攻击者可以通过构造恶意 HTTP 请求，在服务器反序列化 React Server Functions 时触发无限循环，从而耗尽 CPU 资源，使服务不可用。
值得注意的是，即使你的应用没有显式定义任何 Server Function，只要启用了 React Server Components，就可能暴露在这个风险之下。最初的修复（如 19.0.2、19.1.3、19.2.2）被证明并不完整，因此 React 团队紧急发布了 19.0.3、19.1.4 和 19.2.3 版本以彻底堵住漏洞。
如果你正在使用 Next.js、Waku、@parcel/rsc 等支持 RSC 的框架或构建工具，请务必确认依赖的 react-server-dom-* 包是否已升级至安全版本。
源码泄露：Server Function 的秘密藏不住了？
另一个中危漏洞（CVE-2025-55183，CVSS 5.3）则更为隐蔽：当 Server Function 接收某些特定结构的输入时，其内部实现代码（包括硬编码的密钥！）可能会被意外序列化并返回给客户端。
举个例子：
'use server';
export async function serverFunction(name) {
const conn = db.createConnection('SECRET KEY');
const user = await conn.createUser(name);
return { id: user.id, message: `Hello, ${name}!` };
}
在漏洞触发的情况下，攻击者可能收到类似这样的响应：
1:{"id":"tva1sfodwq","message":"Hello, async function(a){...let b=i.createConnection(\"SECRET KEY\");...}!"}
虽然运行时环境变量（如 process.env.SECRET）不会被泄露，但硬编码在函数体内的敏感信息却可能暴露无遗。这再次提醒我们：永远不要在源码里写密钥！
谁需要立刻行动？
根据官方说明，以下包的以下版本均受影响：
react-server-dom-webpackreact-server-dom-parcelreact-server-dom-turbopack
受影响版本包括：19.0.0 到 19.2.2（含）。
安全版本为：19.0.3、19.1.4、19.2.3。
如果你的应用没有使用 React Server Components，或者你的项目不依赖上述包（例如纯客户端 React 应用、传统 SSR 架构），那么你不受影响。React Native 用户若未在 monorepo 中引入这些包，也无需操作。
不过，为了保险起见，建议运行 npm ls react-server-dom-webpack（或其他对应包名）检查是否存在间接依赖。
尾声：安全是一场持续的修行
从 Log4Shell 到如今的 React Server Components，我们可以看到一个共通的模式：初始修复往往只是起点，真正的安全需要社区的持续审视与迭代。感谢 Andrew MacPherson、RyotaK 和 Shinsaku Nomura 等研究者的贡献，正是他们的细致挖掘，才让隐患得以及时暴露。
咱始终相信，技术之美不仅在于创造，更在于守护。愿每一位开发者都能在代码世界里，既写出灵动的功能，也筑起坚固的防线。