超过 8.7 万台 MongoDB 服务器裸奔在互联网上
摘要：…
安全媒体 BleepingComputer 披露，被称为 MongoBleed 的高危漏洞（CVE-2025-14847），已经在互联网上被大规模利用。
根据设备搜索平台 Censys 的最新统计：
截至 12 月 27 日，互联网上仍有超过 8.7 万台 MongoDB 实例处于可被攻击状态。
这不是理论风险，而是 已经被验证、已经有公开利用代码、已经出现攻击行为 的现实问题。
攻击门槛到底低到什么程度？
一句话概括：
只需要一个 MongoDB 实例的 IP 地址就够了。
Elastic 安全研究员 Joe Desimone 发布了名为 MongoBleed 的 PoC（概念验证）代码，用于演示如何通过该漏洞泄露 MongoDB 进程内存中的敏感信息。
随后，知名安全研究员 Kevin Beaumont 对该 PoC 进行了验证，结论非常直接：
•PoC 真实有效•不需要认证•不需要用户名和密码•可以直接从内存中“翻找” 数据库明文密码、AWS Secret Key、API Key、会话令牌 等。
攻击成本低到 不需要专业安全背景，也能照着说明操作 的程度。
MongoBleed 的根因，依然出在 zlib 压缩数据的处理逻辑 上。
简单来说就是：
MongoDB 在解压网络数据包时，错误地使用了 已分配内存大小，而不是 实际解压后的数据长度。
攻击者可以构造一个“谎报大小”的数据包：
1.声称解压后数据很大2.MongoDB 分配一大块内存3.实际数据很小4.剩余的内存内容被原样返回给客户端
而更致命的是：
这一切发生在认证之前。
也就是说，MongoDB 还没来得及问你“你是谁”， 就已经把内存里的东西送出来了。
更严重的是 泄露的不仅仅只是数据库数据。根据 Ox Security 的分析，被泄露的内存内容可能包含：
•数据库凭证•API / 云厂商密钥•会话 Token•个人可识别信息（PII）•内部日志•配置文件•文件路径•客户端相关数据
这些信息 很多根本不应该长期存在于任何接口返回中， 但却因为内存泄漏，被一次性暴露。
Censys 的统计数据显示，暴露在公网的 MongoDB 实例主要集中在：
•🇺🇸 美国：约 2 万台•🇨🇳 中国：约 1.7 万台•🇩🇪 德国：约 8000 台
这意味着：
•不只是“某些安全意识薄弱地区”•而是 全球范围内的大规模运维现实
云环境同样不安全，云安全平台 Wiz 的遥测数据给出了另一个角度：
42% 的可观测系统中，至少存在一个易受影响的 MongoDB 实例。
更糟糕的是：
•这些实例既包括 公网暴露的•也包括 内部网络中的
而 Wiz 已确认： MongoBleed 已经被真实攻击者用于实战利用。
Recon InfoSec 联合创始人 Eric Capuano 提醒：
打补丁，并不等于问题结束。
原因很简单：
该漏洞攻击过程 不会导致服务异常、不会明显影响性能、日志特征极弱，很多系统可能已经被读过内存，但无人察觉。
Capuano 给出了一种检测思路，查找 同一源 IP，建立了大量连接，但几乎没有任何正常客户端元数据。
但他同时警告：
该检测方式基于当前公开 PoC， 攻击者完全可以稍作修改进行规避。
基于上述研究，THOR APT Scanner 作者 Florian Roth 已推出 MongoBleed Detector，用于解析 MongoDB 日志，识别潜在攻击行为。
但必须说一句现实的话：
检测，永远是亡羊补牢。
MongoDB 已在 12 月 19 日 发布补丁，并明确建议升级至以下安全版本：
•8.2.3•8.0.17•7.0.28•6.0.27•5.0.32•4.4.30
MongoDB Atlas 用户已自动完成修复。对于自建用户，如果无法升级，只能：
•禁用 zlib•改用 zstd 或 snappy
从技术角度看，这个漏洞已经被分析透了、补丁也已经给了。
但现实给出的数字是：
8 万多台 MongoDB，仍然暴露在互联网上。
在漏洞公布 → 补丁发布 → 实际修复之间，永远存在一个巨大的“现实时间差”。
而攻击者，正是专门利用这一点。
