什么是 MongoBleed？
就在2025年圣诞节前后，安全研究人员披露了一个针对MongoDB服务器的严重漏洞，社区将其形象地命名为 MongoBleed。
简单来说，这是一个未授权的内存泄漏漏洞。它的危险程度可以与当年轰动全球的Heartbleed相提并论。攻击者不需要任何用户名或密码，只要能通过网络连接到你的MongoDB端口（默认27017），就能诱骗服务器吐出其内存中的"碎片"。
漏洞原理：通俗版解释
要理解MongoBleed，我们不需要深入汇编语言，只需要理解MongoDB处理数据压缩的一个机制。
MongoDB为了提高网络传输效率，支持对数据包进行压缩，其中一种常用的压缩算法是 zlib。
- 正常流程：当客户端发送一个压缩数据包时，MongoDB服务器会解压它。服务器会根据数据包头部的"长度字段"来分配一块内存，用来存放解压后的数据。
- 攻击流程：攻击者发送一个精心构造的恶意数据包。这个数据包告诉服务器："我要发给你一段压缩数据，解压后有1000字节长，请准备好内存。" 服务器听话地分配了1000字节的内存空间。但是，攻击者实际发送的压缩数据解压后其实只有10字节（或者根本无法解压出有效数据）。
- 漏洞触发：由于MongoDB在处理zlib解压时的逻辑缺陷（zlib协议头长度参数不一致），它没有正确校验实际解压的数据是否填满了那1000字节的内存。
- 结果 ：服务器直接把这块内存返回给了攻击者。虽然前10字节是刚才解压的数据，但剩下的990字节是内存中原本残留的"脏数据"。
这些"脏数据"里有什么？可能恰好包含着上一个用户查询的敏感结果、管理员刚刚输入的明文密码，甚至是云服务商的认证Token。
为什么它如此危险？
- 零门槛（Unauthenticated）：这是最致命的一点。攻击者不需要攻破你的防火墙密码，不需要知道数据库账号，只要你的MongoDB端口暴露在公网（或者攻击者已进入内网），就能通过发送特制的数据包进行"抽血"。
- 隐蔽性：这是一种读取操作，不会直接破坏数据库结构，也不会删除数据，因此管理员很难第一时间察觉数据正在被窃取。
- 影响范围广：该漏洞影响了MongoDB的多个主流版本，从较老的3.6版本一直到最新的8.0、8.2系列均有版本受影响。
如何发现自己是否被攻击？
虽然攻击隐蔽，但并非无迹可寻。研究人员发现，利用MongoBleed进行攻击时，会在MongoDB的日志中留下痕迹。
如果您在日志中看到大量的 "Slow query"（慢查询） 记录，且这些查询并不是正常的业务逻辑，这极有可能是攻击者正在反复尝试触发漏洞，榨取内存数据的信号。通常一次默认的MongoBleed攻击测试会产生数千条此类日志。
紧急防御建议
针对这一高危漏洞，飞函安全建议立即采取以下措施：
- 立刻升级：MongoDB官方已经发布了修复版本。请尽快将您的MongoDB Server升级到官方推荐的最新补丁版本（如4.4.30+, 5.0.32+, 6.0.27+, 7.0.28+, 8.0.17+ 等）。
- 禁用 zlib 压缩 ：如果暂时无法重启或升级数据库，可以通过配置禁用MongoDB的网络消息压缩功能中的zlib算法。
- 在配置文件中调整
net.compression.compressors选项，移除zlib。
- 在配置文件中调整
- 网络隔离：永远不要将数据库端口（27017）直接暴露在公网。使用VPN、SSH隧道或严格的安全组规则，限制只有受信任的IP地址可以访问数据库。
结语
MongoBleed再次提醒我们，在追求性能（如开启压缩）的同时，底层代码的边界检查至关重要。对于运维人员而言，在这个"后Heartbleed"时代，保持对基础设施的及时更新和最小权限的网络配置，仍然是保护数据资产的最后一道防线。
本文内容参考自 bigdata.2minutestreaming.com，由《飞函安全观察》整理发布。