我有一支技术全面、经验丰富的小型团队，专注高效交付中等规模外包项目，有需要外包项目的可以联系我
Web 安全很多时候像“后台静默更新”。
我们打补丁、升版本、跑 lint、继续写需求——一切看起来都很正常。但总有那么一两次，整个生态会突然被迫停下来：不许装忙，不许装没看见。
最近的 React2Shell 就是那次“全体起立”。它把社区逼得开始认真扒开 React Server Components（RSC）到底怎么在底层跑、怎么解析请求、怎么把“看起来像数据的东西”变成“会动的东西”。
然后，新的结果来了：两处新的 RSC 漏洞被挖出来了，而它们正是 Next.js 等框架赖以运行的那套实现的一部分。
这两个漏洞分别是CVE-2025-55184和CVE-2025-55183。它们由一位外部研究者通过Vercel 与 Meta 的漏洞赏金项目提交并披露。并且目前没有证据表明它们已在真实世界被大规模利用——尽管如此，它们依然值得每一个使用 RSC 的团队花时间弄清楚。
这篇文章会拆开讲：漏洞是什么、影响谁、为什么重要、以及开发者该怎么保护自己的应用。
为什么现在必须在意
React Server Components 不是“一个新语法糖”，而是 React 生态里最具影响力的结构性变化之一。
它承诺的好处很诱人：把一部分逻辑移到服务器，减小客户端包体、改善 hydration、并且让你访问数据像呼吸一样自然——不用把一堆不必要的 JavaScript 运到浏览器里。
然而，新抽象带来的从来不只有便利，还有新的攻击面。
React2Shell 的 PoC 一出来，大家才被迫认真审视：RSC 请求到底是怎么被解析的？框架面对“意外输入”时到底稳不稳？而这股调查并没有在第一颗炸弹爆炸后停止。研究者继续深挖，结果又挖出了两处需要立刻修补的问题。
好消息是：这两处都需要精心构造的请求，而且目前没有公开的“已在野利用”证据。更好的消息是：这说明安全社区正在真实地参与修复 RSC 生态，而不是等着下一次灾难发生。于是，我们得到的是更清晰的风险边界，以及更及时的补丁落地到框架中。
CVE-2025-55184
通过恶意 RSC Payload 造成拒绝服务（DoS）
严重性：高影响：服务器卡死、CPU 飙高类型：拒绝服务（Denial of Service）
这两个里更“危险”的往往不是泄密那个，而是这一类：它不偷东西，但能让你整台服务直接停摆。甚至可能只需要一条恶意请求——就够了。
我们把它讲清楚。
这个漏洞允许什么
攻击者可以向任何会处理 App Router 请求的端点发送一个特制的 HTTP 请求，让服务器出现：
反序列化 payload 时无限挂起
CPU 资源被锁死、耗尽
后续正常流量被阻塞，应用整体变得不可用
最关键的是：不需要登录、不需要会话、不需要认证。你甚至不用“进入系统”，就能让系统喘不过气。
它为什么会发生
RSC 依赖一种特殊的序列化格式，用来在客户端与服务端之间传输组件边界、props、action 标识等信息。正常情况下，这套格式被认为是结构化且可控的。
但问题出在：当服务器去反序列化“不可信输入”时，某些数据模式会触发无限处理循环或极端耗时的路径。于是你的服务端线程被拖住，CPU 被拉满，整个实例像被按住喉咙一样发不出声音。
更麻烦的是：最初的修补只是加了一些“护栏”，看起来挡住了一部分 DoS 向量，却没挡住全部。这个不完整的修复，后来又引出了一个后续漏洞：CVE-2025-67779。
谁会受影响
凡是通过 App Router 处理 RSC 请求的框架版本，都可能中招，包括但不限于：
Next.js
使用 React Server Components 的自研框架
任何把外部输入交给 RSC handler 解析的服务器
只要你在用 RSC，就应该默认：在打上补丁之前，你曾经处于风险区。
真实世界里它会长什么样
DoS 很少是“无聊的恶作剧”。它经常被用来：
打掉竞争对手的关键服务
在大促、发布会、热门事件期间制造中断
配合勒索与要挟
作为更深层攻击前的探测与压测
它不一定给你“远程执行代码”的戏剧性结果，但它能让你的生产环境停止工作。而对业务来说，“停摆”本身就足够致命，所以它被评为高危并不夸张。
CVE-2025-55183
暴露已编译的 Server Action 源码
严重性：中影响：源码泄露类型：信息暴露（Information Exposure）
如果说上一个像“把你家电闸直接拉掉”，那这一个更像“把你家钥匙的结构图贴到门口”。
它不一定让服务器立刻倒下，但它会暴露一件你绝对不想公开的东西：Server Actions 的已编译代码。
这个漏洞允许什么
攻击者对任意 App Router 端点发起恶意请求，可能导致服务器响应里包含：
被访问的 Server Action 的已编译代码
action 的处理逻辑轮廓
后端操作的结构与流程
它通常不会直接吐出环境变量、密钥或私钥——除非你把这些东西硬编码进 Server Action（大多数人不会，但也不是绝无可能）。
为什么这事仍然很要命
就算没有直接泄露“密码”，业务逻辑本身也是敏感资产。被别人看到了，你可能会暴露：
API 的访问模式与节奏
内部校验与过滤步骤
数据库查询形状与路径
feature flag 的判断条件
认证流程与边界细节
这些信息对攻击者来说价值极高，因为它能把“盲打”变成“按图索骥”。
它为什么会发生
根因仍然和 RSC 请求的解释方式有关：当发送某些畸形或刻意构造的 payload 时，服务器会返回对 Server Action 的某种序列化表示，结果“多说了不该说的”，把源码级信息暴露了出来。
谁会受影响
同样地，只要你通过 App Router 使用 RSC，这类风险就可能存在。
真实世界的影响
源码泄露意味着攻击者能更快、更准地理解你的：
应用逻辑
可能存在的下一处漏洞
内部架构
数据流假设
它不一定立刻造成“爆炸”，但它会扩大攻击面，让很多团队依赖的“朦胧安全感”（哪怕你知道安全不能靠遮掩）瞬间塌掉。
这两个漏洞是怎么被发现的
这整个发现过程本身，其实也在提醒我们：开放生态为什么能活得更久。
React2Shell 把社区讨论点燃之后，一位独立安全研究者顺着讨论继续往下挖，深入研究 RSC 通信层是如何解释数据、如何处理边界情况的。随后，他们在 Vercel 与 Meta 的漏洞赏金机制下进行了负责任披露，把两个问题提交给维护方。
这给了维护方一个关键窗口：在不把生态暴露给更大风险的前提下，完成修复、验证，并准备安全版本发布。
相关公司也公开致谢，强调安全是协作而不是闭门造车——这点在今天尤其重要。
开发者现在应该做什么
即便暂时没有“已在野利用”的信号，所有在做现代 React 的团队也不该观望。你可以按下面步骤走：
1）立刻升级
按你的框架补丁说明走。Next.js 以及相关依赖已经发布了修复版本。请同时更新：
框架本身
RSC 处理相关包
自定义 server 集成部分（如果你做了二次封装）
2）不要把 RSC 端点毫无遮拦地暴露在公网
确保做到：
非公开路由有访问控制
开启限流（rate limiting）
通过 WAF 过滤畸形 payload 与可疑请求
3）审计你的 Server Actions
重点检查：
是否硬编码了任何敏感信息
是否存在“逻辑一旦泄露就会被滥用”的关键步骤
是否包含业务核心算法或规则
必要时，把真正敏感的动作下沉到更严格的后端服务层，而不是都堆在 Server Action 里。
4）监控日志里的异常流量
哪怕没有已知利用，畸形 RSC 请求本身就可能意味着攻击者在探测未打补丁的目标。别等到告警爆炸才回头看。
5）建立“默认安全”的工程文化
RSC 已经是服务器代码了，不是“前端便利功能”。 既然它跑在服务器上，就必须用服务器级别的标准去审视它：权限、边界、输入、失败策略、审计、隔离——一个都不能少。
更大的图景：成长的阵痛，也是生态在变强的证据
React Server Components 是一次进化，但进化意味着复杂度上升。更关键的是：RSC handler 并不是传统 REST API，它用的是一套相对年轻的协议，边界还在扩展，边角还在被极限测试。
好消息是：这些漏洞之所以被发现，是因为社区“足够在意”。透明讨论带来了更多审查，更多审查带来更强的系统——这正是开放生态最有生命力的部分。
所以真正的 takeaway 不是恐慌，而是认知升级：
现代 Web 栈早就不再是清清楚楚的“前端/后端分界线”。React 正在模糊它，于是安全责任也被一起模糊了。任何跑在服务器上的代码，即便它来自一个前端框架，也必须接受与传统后端同等级别的安全审视。
最后总结
CVE-2025-55184和CVE-2025-55183不是“React 失败了”的证据，它们更像是：RSC 生态正在长大、正在被认真对待的信号。
目前没有已知在野利用。修复已发布。社区也在学习并补强防线。
现在真正重要的是：保持更新、保持警觉、并且把 RSC 当成真正的服务器代码去敬畏。
如果你维护的是 Next.js 应用，或者任何用到 RSC 的系统——现在就是你升级、复查、加固安全姿态的最好时机。
安全从来不是某一个人的责任。 而这一次，生态再一次证明：共享责任，真的能救命。
全栈AI·探索：涵盖动效、React Hooks、Vue 技巧、LLM 应用、Python 脚本等专栏，案例驱动实战学习，点击二维码了解更多详情。
最后：
CSS终极指南
Vue 设计模式实战指南
20个前端开发者必备的响应式布局
深入React:从基础到最佳实践完整攻略
python 技巧精讲
React Hook 深入浅出
CSS技巧与案例详解
vue2与vue3技巧合集
