文章总结： 文章揭露了MongoDB严重漏洞CVE-2025-14847（MongoBleed），CVSS评分8.7。该漏洞源于Zlib解压逻辑错误，导致服务器返回未初始化内存，攻击者可无需凭证窃取APIKey及密码等敏感数据。影响版本广泛，全球超8.7万实例受波及。建议立即升级至指定安全版本，或临时禁用Zlib压缩并限制公网访问。 综合评分： 93 文章分类： 漏洞分析,漏洞预警,解决方案,数据安全

你的 MongoDB 安全吗？一个压缩算法的 Bug，竟让 API Key 和密码随意泄露

原创

Kit Chung

安全圈动向

2025年12月31日 08:44 广东

大家好，做技术的都知道，最怕空气突然安静，更怕半夜手机突然震动。但比报警更可怕的是什么？是你的数据库大门紧锁，但窗户却开着，被人一把一把地把核心数据往外掏，而你甚至没有任何察觉。

最近，安全圈炸锅了。MongoDB 曝出了一个编号为 CVE-2025-14847 的严重漏洞，CVSS 评分高达 8.7。

国外的安全研究员给它起了个非常形象且惊悚的名字——MongoBleed（MongoDB 滴血）。哪怕你没有账号、没有密码，只要网络能通，攻击者就能远程把你的 MongoDB 内存里的数据“吸”出来。

全球已经有超过 87,000 个实例“暴露”，中国也是重灾区之一。

今天，我就带大家拆解一下这个漏洞的硬核技术细节，看看这行代码到底是怎么写崩的，以及我们该如何自救。

01 这个漏洞到底有多“坑”？

简单说，这是一个未经身份验证的远程信息泄露漏洞。

这就好比你家装了指纹锁，但攻击者根本不走正门。他只要站在门口喊一声（发送恶意构造的数据包），你家窗户就会自动发出一段家里的录音，或者一张银行卡密码条。

这个漏洞的核心在于 MongoDB 处理网络消息压缩的方式上，特别是它默认启用的 Zlib 压缩。

OX Security 和 Wiz 的研究人员发现，问题的根源藏在 MongoDB Server 的 Zlib 消息解压实现文件 message_compressor_zlib.cpp 里。

划重点：

攻击者不需要任何凭证，也不需要用户交互。只要你的 MongoDB 开启了 Zlib 压缩（默认就是开的），并且端口暴露在公网或攻击者能访问的内网，你就中招了。

02 硬核拆解：内存泄露的原理是什么？

作为一名写了多年代码的老司机，看到这个漏洞的成因时，我只能说：细节魔鬼，防不胜防。

这个漏洞属于典型的未初始化内存泄露。

1. 正常的逻辑

当服务器收到一个压缩包时，它应该：

• 第一步：分配一块内存缓冲区。
• 第二步：把数据解压进去。
• 第三步：返回实际解压的数据长度。

2. 出 Bug 的地方

在受影响的 MongoDB 版本中，解压逻辑出了一个致命的差错：

它返回的不是“实际解压后的数据长度”，而是“原本分配的缓冲区大小（output.length()）”。

这会导致什么后果？

3. 攻击场景模拟

想象一下，攻击者发送了一个恶意的、畸形的压缩包：

• 请求：

  “我给你个包，你帮我解压，给我准备一个 10KB 的盒子。”

• 实际数据：

  这个包解压出来其实只有 1KB 的有效数据。

• 服务器 Bug：

  服务器很听话，分配了 10KB 的堆内存（Heap）。它把 1KB 数据放进去了，但是，它把整个 10KB 的盒子都发送回给了攻击者。

关键点来了： 那剩下的 9KB 空间里装的是什么？

是未初始化的堆内存数据！这些内存里可能残留着上一次操作留下的任何东西——用户的明文密码、API Key、Session ID、业务敏感数据……

虽然攻击者一次只能偷一点点“碎片”，但就像蚂蚁搬家一样，只要时间足够长，脚本跑得足够快，他们能把你的数据库内存“拼图”拼个底掉。

03 影响范围：谁在射程之内？

根据 Censys 的扫描数据，目前全球有 87,000+ 个潜在受害者。Wiz 的报告更扎心：42% 的云环境中至少有一个易受攻击的 MongoDB 实例。

受影响的版本非常广泛（基本涵盖了主流使用的版本）：

• MongoDB 8.2
• MongoDB 8.0
• MongoDB 7.0
• MongoDB 6.0
• MongoDB 5.0
• MongoDB 4.4

特别注意： 不仅仅是 MongoDB 本身，任何使用了受影响版本 Zlib 库的工具（比如 Ubuntu 的 rsync 包）也可能躺枪。

04 救火指南：现在该怎么办？

看到这里，我知道你已经准备打开终端连 SSH 了。别急，方案给你准备好了。

第一招：升级！升级！升级！（推荐）

官方已经发布了补丁，请立刻检查你的版本，并升级到以下安全版本（或更高）：

• 8.2.3
• 8.0.17
• 7.0.28
• 6.0.27
• 5.0.32
• 4.4.30

如果你用的是 MongoDB Atlas（云服务），恭喜你，官方已经帮你打好补丁了。

第二招：临时止血

如果你因为业务原因暂时无法重启升级，或者还在走变更流程，可以先用这个“缓兵之计”：禁用 Zlib 压缩。

你可以在启动 mongod 或 mongos 时，通过配置文件，在 networkMessageCompressors 选项中显式地去掉 zlib。

例如，只保留 snappy 或 zstd：

net: compression: compressors: snappy,zstd

（注意：这样做可能会稍微增加一点网络带宽消耗，但为了安全，这点流量算什么？）

第三招：收敛攻击面

老生常谈了，但还是要啰嗦一句：不要把数据库端口直接暴露在公网！

配合防火墙策略，限制 IP 访问；同时，赶紧去查一下 MongoDB 的日志，看看有没有异常的、大量的预认证连接请求。

CVE-2025-14847 再次给我们敲响了警钟：安全不是一道墙，而是一个过程。 哪怕是像 Zlib 解压这么基础的功能，一个小小的逻辑疏忽，都可能导致核心资产的泄露。

这几天大家可能会比较忙，建议各位把这篇文章转发给身边的 DBA 和运维兄弟。早一分钟打补丁，就少一分“删库跑路”的风险。

觉得有帮助？请“转发”或点个“在看”让更多人看到 👇

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全圈动向 Kit Chung《你的 MongoDB 安全吗？一个压缩算法的 Bug，竟让 API Key 和密码随意泄露》