文章总结： 文章分析了CVE-2025-55182React2Shell漏洞的WAF绕过技术，包括负载位置绕过、编码规避、协议特性规避等多种方法，展示了攻击者与防御方的快速对抗。文章指出WAF难以彻底防御的根本原因，并建议通过打补丁、网络隔离和运行时防护等多层次措施进行防御，强调应从边界检测转向运行时可信执行的安全理念。
综合评分： 94
文章分类： 漏洞分析,WEB安全,渗透测试,应急响应,安全建设
React2Shell WAF大战小结
原创
rayh4c
先进攻防
2025年12月9日 17:56
北京
React2Shell WAF大战小结
前言
CVE-2025-55182（React2Shell）是 2025 年最具破坏性的 Web 框架级 RCE 漏洞之一。漏洞本质在于 React Server Components 的 Flight 协议在处理 multipart/form-data 请求时，对用户可控输入进行了不安全的反序列化，导致攻击者可直接在服务器端构造任意 gadget chain 并执行系统命令。
自 2025 年 11 月 29 日披露以来，WAF 成为最广泛采用的应急缓解手段。Vercel、Cloudflare、AWS、Akamai、Fastly 等主流厂商均在 24 小时内上线了WAF规则。然而，短短10天内，这些规则被反复绕过，攻击者与防御方的对抗呈现出极高的迭代速度。
WAF 拦截核心逻辑回顾
当前主流 WAF 对 React2Shell 的拦截主要依赖以下三类特征：
- 关键字匹配：constructor、prototype、proto、_response、X-Action-Redirect 等
- 协议特征匹配：Flight 协议特有的 JSON 序列化结构、multipart 边界特征
- 行为异常：超大 POST 体、异常数学运算响应等
攻击者正是针对这三类检测机制逐一突破。
已公开 WAF 绕过思路分类
1. 负载位置与检查边界绕过类
- 超大垃圾数据前置：将真实恶意负载置于 128KB～1MB之后，利用多数 WAF 默认只检查前段内容
- 超大请求体整体绕过：构造 1MB～8MB 完整请求体，触发 WAF “超过检查阈值则放行或仅浅层检查” 的逻辑
- 分块传输利用：故意触发 Transfer-Encoding: chunked 并在中间 chunk 插入恶意负载，部分 WAF 重组不完整
2. 编码与字符集规避类
- Unicode 变种编码（UTF-16LE / UTF-16BE / UTF-32）：在 multipart 字段显式声明 charset=utf-16le，busboy 等解析器会自动解码，而多数 WAF 仍按 UTF-8 检查
- 十六进制 / 八进制 / Unicode 转义混合：将敏感字符串完全打散为转义序列
- 双重甚至三重 URL 编码：利用 WAF 解码层数与后端不一致
- HTML 实体与 JavaScript 转义混合：在 JSON 字符串内部使用 constructor 等
3. 协议与语法特性规避类
- 非原型链反射路径：完全抛弃 proto/prototype 污染，转而使用 Object.getOwnPropertyDescriptor、Reflect.construct 等合法 API 达到同等效果
- JSON 键名与结构变形：将 “constructor” 拆分为数组后拼接、或使用计算属性名 [“con”+”structor”]
- Flight 协议深度嵌套与冗余包装：利用 Flight 支持的循环引用、Symbol、Map/Set 等结构制造极深嵌套，使签名难以命中
- 合法 multipart 参数伪装：将恶意 gadget 隐藏在 filename、Content-Disposition 等次要字段中
4. 请求结构与流程规避类
- 路径规范化差异：使用 ../、/./、//、%2e%2e/ 等变体，WAF 规范化不彻底而后端已处理
- HTTP 方法与头字段混淆：部分 WAF 对 HEAD、OPTIONS、PATCH 方法规则较松，或对 X-HTTP-Method-Override 处理不一致
- 代理链与分布式扫描：通过住宅代理、CDN 回源、云函数中转等方式分散稀释特征，规避单 IP/ASN 限速规则
5. 运行时环境针对性绕过
- Windows 专属 AMSI 绕过链：在 PowerShell 环境中先通过反射将 AmsiInitFailed 置为 true，随后执行下载任意荷载
- Linux 环境无文件 RCE：直接在内存中执行 curl | bash、perl -e、python -c 等，避免写入磁盘触发 EDR
- 容器逃逸组合技：利用 React2Shell 获得初始 RCE 后，通过挂载 hostPath 或 privileged 容器实现横向移动
绕过技巧演进时间线
- Day 0–1：原始 PoC，关键字明文，全部被第一版 WAF 规则拦截
- Day 2–3：垃圾数据填充 + 超大负载，绕过 Cloudflare / AWS 早期规则
- Day 4–5：Unicode charset + 反射非原型链，同时击破 Vercel 与 Cloudflare 第二版规则
- Day 6–7：JSON 深度混淆 + 计算属性名 + 嵌套 Map/Set，多数签名彻底失效
- Day 8–10：多阶段代理链 + AMSI 绕过 + 内存执行，形成完整自动化攻击链
为什么 WAF 难以彻底防御？
- 协议复杂性：Flight 本身就是为高性能设计的动态序列化协议，合法流量与恶意流量边界模糊
- 多层解码差异：WAF → CDN → 负载均衡 → 框架解析器，每一层解码深度不一致
- 性能权衡：若 WAF 对所有请求进行完整 Unicode 解码 + 深度 JSON 解析 + 全量正则，会导致严重延迟，线上业务无法承载
- 规则滞后性：攻击者单次变异只需几分钟，而厂商审核、上线新规则通常需要数小时至数天
真正有效的防御优先级
- 打补丁修复
立即升级到 React 19.0.1+ / 19.1.2+ / 19.2.1+ 和 Next.js 15.0.5+ / 16.0.7+，从协议层杜绝反序列化 - 网络层隔离
将所有 RSC 相关端点（/_rsc、/api 等）放入零信任网络，仅允许可信来源访问 - 运行时防护（RASP）
部署支持 Node.js/JavaScript 的运行时自保护方案，实时监控 eval、Function、child_process 等危险 API - 强化WAF技术（这只是辅助缓解手段，所以只能排最后，同时吐槽一下WAF策略出的问题）
- 强制对所有 POST 请求进行完整解码（包括多次 URL 解码 + Unicode 规范化），这个方案不太现实，加了这个检查，业务也没有什么性能空间了。
- 将 multipart 检查阈值提升至 8MB 以上，Cloudflare调整这个策略马上就出了全球事故。
- 增加反射 API 调用行为规则（如 Reflect.construct + Function），等待业务的是无尽规则升级和专家运营成本。
- 监控响应头 X-Action-Redirect 出现非预期内容（如 uid=、root:x、11111 等），只能发现部分恶意行为。
总结
React2Shell的WAF绕过大战再次证明：在现代复杂协议面前，基于静态签名的传统 WAF 正在接近防御上限。攻击者只需在编码、结构、位置三个维度上做微小变异，即可让规则失效。
真正的长期解法只有两条：
一是框架与协议本身从设计上拒绝不安全反序列化；
二是防御体系从“边界检测”转向“运行时可信执行”。
建议所有安全团队将 React2Shell 视为“已沦陷”前提进行防御纵深建设，而非寄希望于单一WAF规则。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：先进攻防 rayh4c《React2Shell WAF大战小结》