从React2Shell到MongoBleed：让MTTR减少13个小时
从React2Shell到MongoBleed：让MTTR减少13个小时
作者：让天下没有难做的安全 | 发布时间：2025年12月30日 15:01
原文链接：微信公众号
最近安多多客户反馈，还是修不完的漏洞，做不完的应急。
月初wiz 把 React 爆出核弹级 RCE（CVE-2025-55182），上周 MongoDB 又炒作个所谓“大出血”（MongoBleed, CVE-2025-14847）。
安多多访谈过太多客户大小安全团队在这些漏洞面前的表现。最让我观察到有趣的不是漏洞本身有多精妙危害多大，而是应对漏洞时的“混乱低效”痛点。
今天不聊技术细节，想跟各位陈述两个案例。一个关于“惨痛的教训”，一个关于“极致的效率”。
让我们先看看react的时间线
2025年11月29日 安全研究员 Lachlan Davidson私下向 React 核心团队报告。
2025年12月3日（公开披露 / 1-Day）React 团队发布了修复版本。
几乎在公告发布的同一天，Google 和 AWS 的威胁情报团队就监测到了在野（In-the-wild）的扫描和尝试性攻击，说明黑客社区逆向补丁的速度只有 1h 到 1day。
2025年12月5日 - 12月6日 POC 出现，美国 CISA 将该漏洞加入“已知被利用漏洞（KEV）”目录，大家重视起来了 。
根据 安多多在12月底的测绘数据，排除蜜罐后约有 31% 的云环境仍检测到易受攻击的实例，主要是企业内部系统对外、旧的前端页面，测试环境三种情况。还有不少已经有 webshell 的站点，修复工作不仅是打补丁升级，更需要进行“入侵排查”。
**
01 真实攻防对企业安全负责人和业务都是艰难的
**
先说个扎心的案例，在 React2Shell（CVE-2025-55182）爆发的那个周四，某出行行业大厂的安全团队（我们就叫它 A 厂吧）经历了一场包含周五、周六日的全方位卷。
A 厂有大概 40 人全功能安全团队，6 号早上反馈历史漏洞都修复完成，看起来响应很快是吧。
但在 7 号 凌晨 2:15，新加坡地域的一个容器有反弹 shell，机器负责人是一名半年前就已离职的架构师：）。
告警电话拉起 SRE，反馈这台机器挂在一个临时的 SLB下面，为了支持某次新车发布会临时开的，发布会结束了，但负载均衡和后端的容器一直没关，现在不知道背后的实例，无法变更。
8:00：7 号早上，安全负责人直接在全员大群里“全员寻人”，惊动了业务线CTO，搞清楚这是 6 号早上做的变更发布，不在采集范围内走了审批备份，中午 15 点才搞定销毁隔离。
在这 13 个小时里，黑客不仅在挖矿，还以这台“没人认领”的机器为跳板，尝试扫描 A 厂内网的自动驾驶训练数据集（最终证实是盲目挖矿）。
为什么？因为没人知道这台机器是谁的，为什么没有修复。
这简直是无数甲方负责人的缩影：
资产不全： 业务侧开了个测试容器，CMDB 里根本没有记录。
推修无力： 发了工单没人认，认了之后没人修，修了之后没法验。
盲目自信： 以为外网守住了，结果内网一台“漏网之鱼”被横向移动，直接打穿。
在 React2Shell 事件中，A 厂虽然按照 log4j 对待但因为业务的问题，流程混乱、资产不清，硬生生把一场闪电战打成了消耗战。从此不敢以为自己是新型公司没有历史资产包袱。
02 图+AI，优先确认对外网暴露的，有敏感数据的，有漏洞的 mongodb
再同样看看该客户，怎么使用安多多应对最近的 MongoBleed (CVE-2025-14847) 的。
这是一个典型的未授权内存泄露漏洞，无需认证就能读取堆内存数据。对于拥有大量云原生数据库的业务来说，需要高度重视。
但这次，剧本完全不同。
业务 CISO 同安多多确认该情报高危，影响 ISO 27001、27002、PCIDSS、等保三级
只看了两个结果数据：
MTTD（平均检测时间）：< 1 小时
MTTR（平均响应时间）：< 2 小时
他们是怎么做到的？
第一步：全景资产测绘，秒级定位
当 MongoBleed 爆发时，没有去翻 CMDB表格，而是直接打开了安多多的SaaS，看到CSPM（云安全态势管理）看是否有规则，有。
**
**
是否有修复建议，有，都是基于 AI 验证的。
第一步：安多多自动关联了所有云上 MongoDB 资产，并精准识别出哪些开启了 zlib 压缩（这是漏洞触发的关键条件）。
结果： 3 分钟内，确认云上腾讯云、阿里云的不受默认配置影响，主要是主机自己搭建的服务，拉出了所有受影响的，有指纹的 58 个实例，包括那些藏在 K8s 集群ingress的临时测试库。
第二步：无代理检测，不背业务阻力
业务部门最烦安全装 Agent，怕影响性能。
CSPM 采用无代理（Agentless）检测技术，通过快照扫描，在不干扰业务运行的情况下，直接发现了配置的缺陷，甚至有云函数 FC 粒度的低版本 mongo 代理。
结果： 0 卡点，业务方甚至不知道扫描已经完成了。
第三步：攻击路径分析，聚焦 1% 的真风险
58 个实例都有漏洞，先修哪个？是否有汇报上升的重点？
攻击路径分析可视化告诉安全和业务团队：只有 3 个实例直接暴露在公网，且连接了核心生产数据，且没有 nids防御（有 waf 也无法防御）。
结果： 优先级一目了然，优先和业务确认这 3 个实例的公网访问，并禁用了 zlib 压缩，风险瞬间缓解，剩下的慢慢修。
03 本质是与假想敌时间赛跑
把 A 厂的前后反馈放在一起看，给安多多的经验教训是:
A 厂是改进点是技术方向吗？不是，他们团队响应策略、复现漏洞、处理后续的 react拒绝式漏洞很成熟。
阻碍他们取得更大的成功在于“可见性”和“怎么用 AI”上。
在云原生+AI时代，资产是动态的，边界是模糊的，业务是推不动的。
不管是 React2Shell 还是 MongoBleed，还是后续的 xxBleed：
资产视角是底气： 你必须比黑客更早知道你的资产在哪里，配置是什么。
给业务更快的响应： mttr 超过 1 天的处置时间在今天就是不及格，把 MTTD 压到分钟级才是办法，不然就会被入侵。
不要为了合规做安全： 很多工具买来是为了过等保，投人运营，但在 0day 面前，只有那些能真正跑通“发现-定位-阻断”闭环的产品，才有价值。
安多多-Wiz级多云安全平台，资产真实风险一张图看清，正式开放使用
帮助文档：安多多云安全平台帮助中心https://lv8u92t29eh.feishu.cn/docx/MHnKdjZKgoZzpsxAsYcc5hAenzg?from=from\_copylink
微信群聊和微信客服: anduoduo2025