MongoDB CVE-2025-14847 的紧急修复：修补 "MongoBleed" 内存泄漏
- Aisha Washington
- 6月6日
- 讀畢需時 6 分鐘
已更新：6月17日
现在是 2025 年 12 月底。当世界上大多数人都在准备迎接跨年夜时，系统管理员们正在处理一份没人想要的圣诞礼物：MongoDB CVE-2025-14847。
安全研究人员将其命名为“MongoBleed”，这个漏洞并非复杂的远程代码执行链。它是一个简单的、未经身份验证的内存泄漏，由 MongoDB 处理 zlib 压缩头时的故障引起。如果你的 27017 端口暴露在互联网，甚至是不受信任的内部网络中，你的数据（包括身份验证密钥和相邻内存）现在很可能正被读取。
CISA 已于 12 月 30 日将此漏洞添加到其已知已利用漏洞 (KEV) 目录中，确认了野外存在活跃的攻击行为。
我们将技术解决方案放在本文的最顶部。如果你是因为此问题来到这里，请先修复它，稍后再阅读背景信息。
MongoDB CVE-2025-14847 的紧急缓解措施
该漏洞存在于 message_compressor_zlib.cpp 的实现中。它影响了过去十年中发布的几乎所有版本的 MongoDB，具体包括 v3.6 到 v8.2 补丁发布前的版本。
1. 升级路径
如果您可以打补丁，请立即执行。官方修复程序解决了 zlib 协议头中的长度不匹配问题，该问题会导致堆内存泄漏。
安全版本：
v8.2： 升级至 8.2.3 或更高版本
v8.0： 升级至 8.0.17 或更高版本
v7.0： 升级到 7.0.28 或更高版本
v6.0： 升级到 6.0.27 或更高版本
v5.0: 升级至 5.0.32 或更高版本
v4.4: 升级至 4.4.30 或更高版本
旧版本（3.6, 4.0, 4.2）已停止维护（EOL），将不会收到补丁。如果您正在运行这些版本，则必须使用下方的配置变通方案。
2. 配置规避方案（禁用 Zlib）
对于无法脱机升级的系统或旧版本，您可以通过禁用 zlib 压缩来抵御 MongoDB CVE-2025-14847。该漏洞利用依赖 zlib 压缩器来触发内存读取；禁用它即可关闭攻击向量。
编辑您的 mongod.conf（通常位于 /etc/mongod.conf），从 compressors 列表中移除 zlib：
codeYaml
net:
compression:
compressors: snappy,zstd # 确保此列表中不包含 zlib如果您目前依赖默认设置，请显式设置 compressors 以排除 zlib。重启 mongod 服务使更改生效。
3. 网络隔离
此漏洞需要对数据库端口的网络访问权限。如果您的 MongoDB 实例绑定到 0.0.0.0 且可通过公共互联网访问，请使用防火墙（iptables、AWS Security Groups、UFW）仅将受信任的 IP 地址列入白名单。
MongoDB CVE-2025-14847 (“MongoBleed”) 的工作原理
将其与 2014 年臭名昭著的 “Heartbleed” 漏洞相提并论并非只是为了戏剧效果；两者的机制惊人地相似。
MongoDB CVE-2025-14847 是一个堆信息泄露漏洞。当客户端发送一个带有特定畸形头部的压缩数据包时，MongoDB 服务器会尝试对其进行解压。该漏洞存在于服务器计算缓冲区大小的方式中。它返回的是已分配的缓冲区大小，而不是实际的解压数据大小。
因此，当服务器将响应发回客户端时，它包含了实际数据以及填充该分配缓冲区所需的、位于相邻未初始化堆内存中的任何垃圾数据。
这会暴露什么？由于此内存在堆上，它通常包含高度敏感的瞬态数据，包括：
身份验证凭据（密码、哈希）。
API 密钥（AWS 密钥、第三方令牌）。
其他用户最近访问的集合数据。
系统内存碎片。
对于运维团队来说，最可怕的是这不需要有效的用户名或密码。攻击者只需连接到端口并发送畸形数据包。目前在 GitHub 上流传的漏洞利用脚本会自动执行此过程，分块转储内存，直到找到私钥等可识别的字符串。
社区分析：MongoDB CVE-2025-14847 的现实影响
自 12 月 26 日左右发布概念验证 (PoC) 以来，系统管理员和自托管社区一直在对其基础设施进行压力测试。
Ubisoft 事件与凭据轮换
打补丁堵住了漏洞，但无法抹去已经失窃的数据。由于该漏洞允许静默读取内存，你未必能在日志中看到“登录失败”的尝试。你可能会看到与 zlib 相关的异常连接终止错误，但老练的攻击者可以降低这些噪音。如果你曾暴露于该漏洞，请假设你的数据库用户以及内存中存储的任何凭据（如应用程序使用的 AWS 密钥）均已泄露。请立即轮换它们。
Ubiquiti UniFi 控制器
家庭实验室和 MSP 领域的一个主要担忧是 Ubiquiti UniFi Network Application (CloudKeys)，它严重依赖旧版本的 MongoDB（通常为 3.6 或 4.4）。
社区测试表明风险情况不一：
默认 Localhost：大多数标准的 CloudKey 安装会将 MongoDB 绑定到 127.0.0.1。如果你的控制器位于 NAT 之后，且数据库端口 (27017) 未进行转发，则风险仅限于内部威胁。
自定义/Docker 安装：在 Docker 容器或自定义 VPS 设置中运行 UniFi 控制器的用户经常修改绑定 IP 以桥接网络。如果你在没有严格防火墙的情况下这样做，你的控制器数据就会暴露。
“圣诞节漏洞”疲劳
该版本的发布时机引起了运维社区的极大愤怒。虽然 MongoDB（供应商）在 12 月中旬左右就意识到了这个问题，但第三方 PoC 的公开发布发生在假期期间。这迫使值班人员在家庭团聚时间进行紧急补丁修复。
这种在假期发布漏洞的趋势迫使策略发生改变：变更冻结（change freezes）不再意味着“安全冻结”。事件响应计划需要针对法定假期期间披露的高严重性 CVSS 8.7+ 漏洞制定特定协议。
检测攻击尝试
如果你试图确定 MongoDB CVE-2025-14847 是否已被用于针对你的攻击，标准日志可能不足。该攻击看起来像是在压缩阶段失败的合法连接协商。
然而，监控以下异常情况可能会有所帮助：
Zlib 错误激增： 寻找与 message_compressor_zlib 相关的断言失败或错误的突然增加。
连接搅动 (Connection Churn)： 运行漏洞利用脚本的攻击者通常会反复连接以转储内存的不同部分。来自单个未认证 IP 的连接激增是一个危险信号。
PoC 验证： 您可以安全地验证自己的漏洞。使用安全研究社区提供的 python 脚本，对您的服务器（本地）运行检查：python3 exploit.py --host 127.0.0.1 --port 27017 --check。如果返回 "Vulnerable"，请立即应用第一部分中提到的配置更改。
常见问题解答：管理 MongoDB CVE-2025-14847
MongoDB CVE-2025-14847 是远程代码执行 (RCE) 漏洞吗？
不是，它是一个未授权的内存读取漏洞。 攻击者无法直接通过此漏洞执行代码或安装恶意软件，但他们可以窃取登录所需的凭据并 然后执行恶意命令或删除数据。
这会影响 MongoDB Atlas（托管服务）吗？
MongoDB Atlas 已由厂商在公开披露前修复。如果您使用的是托管云服务，通常是受保护的，但您仍应在控制面板中验证您的集群版本是否符合已修复的版本（例如 7.0.28+）。
我无法升级我的 MongoDB 3.6 旧版数据库。我该怎么办？
由于 3.6 版本已停止维护（End of Life）且不会收到补丁，您唯一的选择是在 mongod.conf 文件中禁用 zlib 压缩，或者确保服务器受到严格的防火墙限制，仅允许来自应用程序服务器本地 IP 的流量。
为什么 CISA 的介入对该 CVE 具有重要意义？
CISA 将MongoDB CVE-2025-14847添加到 KEV 目录意味着强制要求要求美国联邦机构在特定截止日期前修复该漏洞。这向私营部门发出了信号，表明该漏洞利用程序是可靠、可用且正被威胁行为者积极用于入侵系统的。
我可以使用 WAF 来拦截此漏洞利用吗？
标准的 Web Application Firewalls (WAFs) 通常检查 HTTP/HTTPS 流量。由于 MongoDB 使用自定义二进制协议，标准 WAF 无法识别此类流量。您需要数据库防火墙或严格的网络分段 (ACLs) 来阻止对该端口的访问。
