最近我们报道了国内安全研究人员参与React2Shell相关漏洞赏金计划，协助Vercel在短时间内更新WAF防护规则，阻断React2Shell攻击绕过防御规则的可能性，并获得30万美元（约合人民币210万元）的奖励。这不仅展现了国内安全研究人员的专业能力与高效响应，也在全球性安全危机中扮演了关键的协同防御角色，同时也引发一个问题：当一项关键漏洞冲击全球开发框架时，整个安全生态系统的协同防御体系是如何运转的？

或许有人会问，面对漏洞的应对，责任究竟该如何界定？经过我们梳理多方信息后，可以得出一个结论：这场从漏洞发现、修复，到各方协助缓解、推动修复的应对过程，本质上是一场跨越各环节的防御接力赛。

第一棒：核心修复与协调披露

以React2Shell为例，研究人员Lachlan Davidson于11月29日通过Meta漏洞奖励计划上报漏洞，次日Meta安全团队确认漏洞后，React团队迅速完成修复方案的开发，并在漏洞公开前的12月3日，与相关生态系统协调进行负责任披露，以便各方在公开前部署缓解措施，为全球尚未及时更新代码的开发者与企业建立起第一道缓冲防线。

第二棒：边缘缓解与WAF的攻防博弈

接下来，这场防御接力赛交棒至防御端的多个关键节点，如云服务商、主机托管商、CDN厂商、WAF厂商等，纷纷通过虚拟补丁的形式，利用WAF对React2Shell的攻击特征（Payload）进行拦截，帮助受影响用户争取更充裕的修复缓冲期，用于版本升级与兼容性测试。

第三棒：风险盘点与通报链

在React2Shell漏洞修复发布与边缘防护机制运行的同时，企业已部署的各类安全产品与服务也会启动各自的通报机制，形成另一条并行的情报链。例如，首当其冲的是企业部署的漏洞管理系统、外部攻击面管理平台或SBOM分析工具，它们会通过管理仪表盘告警、邮件通知，甚至通过API或Webhook集成，提醒企业盘点受影响资产。其他类型的安全厂商也可能同步发出预警，建议用户尽快修复，包括云服务提供商、应用托管平台、WAF厂商，以及SOC、EDR厂商——除了在攻击发生时及时响应，漏洞披露后同样可能为服务客户而主动通知其暴露于风险中的情况。

第四棒：漏洞修复的最后一步

最后还有一个关键环节：漏洞修复的“最后一公里”，始终落在最终用户身上。换言之，漏洞修复从来不是单一主体的责任，而是一场与时间赛跑的协同防御行动。

研究人员还可以持续关注哪些方向？

进一步来看，对于受影响用户而言，各环节是否切实落实，我们认为这是研究人员可进一步深入探讨的方向。

在上述第一棒的核心修复层面，研究者上报漏洞后，最关键的是React开发团队的产品安全响应能力，而修复质量将成为重大考验——过去曾有研究人员揭露厂商或维护者修复不彻底，导致漏洞仍可被绕过。

以本次事件为例，确实有研究人员在审查React2Shell（CVE-2025-55182）的初始修复后，发现仍存在绕过可能，促使React团队在修复发布一周后，又披露了三项新漏洞：CVE-2025-55184、CVE-2025-67779、CVE-2025-55183，指出原修复虽已阻断直接导致RCE的攻击路径，但在特定条件下仍可能被利用引发DoS或信息泄露等风险。随后在2026年1月，研究人员又指出CVE-2025-55184的二次修复仍存在不足，React团队随后通过CVE-2026-23864进一步修补。这意味着，即使已完成初步升级的用户，仍需持续更新至后续修复版本。

在第二棒层面，防御缓解的效果，很大程度取决于WAF规则编写的精准度。例如近期我们报道的Vercel通过漏洞赏金竞赛收集绕过手法、快速更新防护规则，正是为了持续优化这道防线，也让外界更关注WAF在解析语义差异与复杂攻击场景下的攻防博弈。因此，各家WAF提供的虚拟补丁强度与覆盖能力，也成为企业用户关注的重点，值得研究人员持续投入。

至于第三棒层面，相关安全工具与服务的通知是否及时、有效并能推动实际行动，仍是实践中值得持续审视的环节。

当然，漏洞修复的“最后一公里”始终在用户手中。若不修复，风险将持续存在。除非像半导体OT场景中的设备停机时间极短，难以定期更新补丁，对于暂时无法修复的场景，企业则需配合更严密的多层次缓解措施，尽可能缩小攻击面，并在风险承受与业务连续性之间做出务实权衡。