这两天有被React的一个反序列化RCE漏洞刷屏，官方CVSS直接拉满10.0分，和当年的Log4j持平。一时间不少传闻声称其为现代前端的Log4j，引起了不少公司开发者恐慌，于是乎大家一觉起来就是各种的查文献打补丁...。在此同时，网上也有传出不少质疑声，有人测试后发现该漏洞并宣传的那样，相反漏洞利用是需要一定条件的。于是我决定抽时间深入研究一下这个漏洞。
react-server-dom-webpack < 19.2.0、react-server-dom-turbopack < 19.2.0该漏洞产生的原因如下，在 [email protected] 中，服务端解析 Server Action 的关键函数是 requireModule（伪代码）：
function requireModule(metadata) {
var moduleExports = __webpack_require__(metadata[0]);
// ...
return "*" === metadata[2]
? moduleExports
: "" === metadata[2]
? moduleExports.__esModule
? moduleExports.default
: moduleExports
: moduleExports[metadata[2]]; // ← 漏洞点
}
漏洞产生的核心是 moduleExports[metadata[2]] 这部分，没有对 metadata[2] 这部分进行校验，导致攻击者不仅能访问模块自己的导出属性，还可以访问原型链上的属性（如 constructor、__proto__ 等），当攻击者构造 metadata[0] 后（如将其指向为 vm），便可再次构造 metadata[2] 进而实现导出指定模块中的危险方法，如 vm.runInThisContext，进而造成漏洞利用。
我在分析时候，参考了 ejpir 提供的测试环境以及漏洞利用，以 vm_runInThisContext 这条 Code Execution gadget 为例进行了分析，过程如下（注意，真实环境下漏洞利用过程会有一定区别！）：
首先，发送带有 payload 的请求后，断点到获取请求位置如下：
随后程序执行到 const formData = parseMultipart(buffer, boundaryMatch[1]); 位置，跟入 parseMultipart
parseMultipart 将请求体数据提取后返回给 formData
跟入 const actionFn = await decodeAction(formData, serverManifest); 漏洞产生位置
跟入 loadServerReference
下面就到了漏洞产生核心代码位置 requireModule，跟入
返回将 id 值以 # 的前后作为模块方法，并将 bound 参数值作为方法参数返回
跟入 actionFn，执行最终 payload
至此，漏洞利用结束！
这个漏洞本身仍是对输入校验不严格导致的，这点和Log4j、fastjson如出一辙。我在上面测试的是vm_runInThisContext，实际该漏洞有多个gadget可利用，如
vm#runInThisContextvm#runInNewContextchild_process#execSyncchild_process#execFileSyncchild_process#spawnSyncfs#readFileSyncfs#writeFileSync#constructor#__proto__#prototype攻击者可以利用此漏洞实现：
vm#runInThisContext 或 child_process#execSync 执行任意系统命令fs#readFileSync、fs#writeFileSync 读取/写入任意文件.bashrc、覆盖应用文件等.env、私钥、数据库凭证等）基于此，可以给出相关的防御措施，如下
基于此，临时防御可以从这些角度出发，可以在waf上配置拦截这些危险字段的规则，进而及时拦截恶意攻击。另外也可以在nginx上进行匹配拦截，如下
# Nginx 配置示例
location /formaction {
# 拦截包含危险模块引用的请求
if ($request_body ~* "(vm#|child_process#|fs#|module#)") {
return 403;
}
# 拦截原型链污染尝试
if ($request_body ~* "(#constructor|#__proto__|#prototype)") {
return 403;
}
}
目前官方已发布安全更新，立即升级到安全版本！：
# 升级 react-server-dom-webpack
npm install react-server-dom-webpack@>=19.2.0
# 升级 react-server-dom-turbopack
npm install react-server-dom-turbopack@>=19.2.0
# Next.js 用户
npm install next@>=15.0.5
修复版本：
react-server-dom-webpack: >= 19.2.0react-server-dom-turbopack: >= 19.2.0next.js: >= 15.0.5我在分析上面漏洞时候，参考了 whiteov3rflow 的相关exp，进一步编写了测试环境的漏洞检测工具，并放在了github仓库当中
需要自检的同学访问即可获取(注意，由于原作者测试环境缘故，目前可能仅适用于原测试环境，待后续完善，需要的同学也可以拿去自改...)，注意需要合法授权使用，禁止进行未授权破坏！
截至当下，2025.12.5 ,我在网上看到的情况是，该漏洞"风声"如过山车般起起伏伏，时而"核弹"，时而"水洞"，没一会儿又转变为"核弹"...,相关的漏洞利用方式更是层出不穷。目前根据相关消息来看，"核弹"可能会坐实，只不过影响范围相对与log4j小而已，但无论如何，所有涉及朋友都应尽快更新，以绝后患!!!
另外给开发朋友一个安全忠告，永远不要相信用户的输入，log4j、fastjson以及当下的ReactRCE均是因为这一点躺枪了，因此在实际业务开发时候对于危险位置一定要采用沙箱或者白名单等方式进行严格校验，避免悲剧发生！！！
纸上得来终觉浅，绝知此事要慎行。