文章总结： 本文深度分析了CVE-2025-55182React4Shell反序列化漏洞的触发原理，解释了为何需要POST请求、next-action头和multipart/form-data请求类型。文章详细介绍了从请求处理到反序列化的完整流程，包括handleAction函数、getServerActionRequestMetadata函数的作用，以及busboy库在处理请求时的关键角色。作者通过调试追踪了代码执行路径，揭示了漏洞触发的技术细节，并预告将在下一篇文章中继续分析原型链污染过程。
综合评分： 89
文章分类： 漏洞分析
人工深度调试剖析 CVE-2025-55182 React4Shell 反序列化漏洞（一）
原创
KCyber
自在安全
2025年12月7日 15:01
北京
发现 React2shell 漏洞的人真是太厉害了。目前漏洞 POC 已经公开，但是网上关于该漏洞的分析充满了各种 AI 味，为了深入理解漏洞原理，我还是坚持做一下纯手工调试分析。
实话说自己对新版本 JS 的一些语法糖也不熟悉，因此还需要不断学习。接下来一段时间，我将从漏洞触发原理、利用方法、WAF绕过等多个维度进行分享。今天先分析其中最基础的部分–解析请求如何触发反序列化流程？并尝试回答以下几个问题：
- • 为什么必须是
POST请求？ - • 为什么必须有
next-action头？ - • 为什么必须是
multipart/form-data请求？
在 React 中，renderToHTMLOrFlightImpl 函数负责完成 html 渲染输出，当 http 请求经过其进行处理时，将进入 handleAction 来完成 action requests 处理，此时调用栈如下：
进入 handleAction后，首先会调用getServerActionRequestMetadata函数提取请求元数据。在getServerActionRequestMeatdata函数中，将尝试提取header中的next-action，如果存在且不等于0，返回的isFetchAction取值为true，同时如果Content-Type为multipart/form-data类型，返回值isMultiparAction取值为true ：
回到 handleAction 函数，在后续处理中存在如下判断，如果 isMultiparAction 和 isFetchAction 均为 true ，那么将引入 busboy 这个库来做 http 解析，这个库常用来处理 multipart/form-data 请求，与上面的判断条件一致：
在 decodeReplyFromBusboy 函数中会完成 Flight 反序列化操作，对于 field 类型的请求 (不包含 file 上传)将通过 resolveField 进行处理：
busboyStream.on("field", function (name, value) {
0 < pendingFiles
? queuedFields.push(name, value)
: resolveField(response, name, value);
});
继续往下调试，在 initializeModelChunk 函数中将依次对请求参数进行 json 格式化处理，并进入 reviveModel 函数进行反序列化递归处理：
这其中需要重点关注被调用的 parseModelString 函数，对首字符是否为 $ 进行了判断，并根据第二个字符的取值采取不同的方式进行处理：
这里就涉及了原型链污染过程，我们留到下一篇继续分析。
由于传播、利用此文档提供的信息而造成任何直接或间接的后果及损害，均由使用本人负责，公众号及文章作者不为此承担任何责任。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：自在安全 KCyber《人工深度调试剖析 CVE-2025-55182 React4Shell 反序列化漏洞（一）》