CVE-2025-14847：关于 MongoBleed 漏洞的关键信息

Dec 30, 2025

Akamai Security Intelligence Group

寫於

Akamai Security Intelligence Group

Akamai SIG is a global team of world-class researchers, engineers, strategists, and data scientists with a broad range of expertise and security disciplines. Our data sources include the enormous Akamai Cloud, open sources, collaboration with third parties, and dark web intelligence. We have also developed our own algorithms and tools that help us deliver our research and keep Akamai security solutions up to date.

受影响的 Akamai Hunt 客户已收到包含脆弱资产详细映射及可操作抵御措施的报告。

2025 年 12 月 19 日，一项影响大多数 MongoDB 部署的新漏洞在 MongoDB 公开实例中被披露。
该漏洞被命名为 MongoBleed，存在于 MongoDB 处理 zlib 压缩消息的过程中，可使未经身份验证的客户端从数据库中泄漏未初始化的堆内存。
该 CVE 漏洞的 CVSSv4 评分为 8.7。
2025 年 12 月 29 日，网络安全和基础设施安全局 (CISA) 将 CVE-2025-14847 纳入其“已知被利用的漏洞”(KEV) 目录，证实该漏洞已被主动利用。与此同时，Akamai 遥测数据显示，约 62% 的企业网络中存有 MongoDB 通信流量。

在这篇博文中，我们将对 MongoBleed 漏洞进行技术剖析，概述受影响的 MongoDB 版本（含补丁分析），并提供实用的抵御指南，包括 Akamai Guardicore Segmentation Insight 查询语句，以帮助识别存在漏洞的资产。

跳转到“抵御方案”部分

漏洞详情

MongoBleed 漏洞源于 MongoDB 处理压缩有线协议消息的方式，该功能在默认配置下处于启用状态。

MongoDB 使用以 OP_MSG 操作码标记的消息进行通信，其请求攻击负载以二进制JSON (BSON) 格式编码。当发送压缩消息时，原始的 OP_MSG 攻击负载会被封装在 OP_COMPRESSED 结构体中。

OP_COMPRESSED 消息包含 OP_MSG 攻击负载以及解压后攻击负载的预期大小。


struct OP_COMPRESSED {
    struct MsgHeader {
        int32  messageLength;
        int32  requestID;
        int32  responseTo;
        int32  opCode;
    };
    int32_t  originalOpcode;
    int32_t  uncompressedSize;
    uint8_t  compressorId;
    char     *compressedMessage;
};

攻击者可以操纵 uncompressedSize 字段，使其大于压缩攻击负载的实际大小。由于该值未经验证，这种操纵会导致分配过大的缓冲区，其中填充了未初始化的堆内存数据。

这些泄漏的内存可能包含明文密码片段、凭据、API 密钥或其他敏感的驻留内存数据，具体内容取决于先前堆内存的使用情况。

MongoDB 的错误处理逻辑进一步放大了信息泄露的风险。当发送的畸形 BSON 对象未包含空终止符时，服务器将持续解析内存直至遇到空终止符为止。当解析最终失败时，服务器会返回错误响应，其中包含原始消息及泄漏的堆内存内容。

截至撰写本文时，Shodan 报告显示有超过 21.3 万个暴露于互联网的 MongoDB 实例，而 Censys 的数据则超过 8.7 万个，这表明该漏洞的影响范围极为广泛。

公开漏洞利用代码已出现

在漏洞披露后数日内，GitHub 上已出现可运行的漏洞利用程序。该利用程序通过重复发送畸形的压缩请求，使攻击者能够逐步泄漏大量堆内存数据。

受影响的版本

MongoBleed 影响以下 MongoDB 版本：

8.2.0–8.2.2
8.0.0–8.0.16
7.0.0–7.0.27
6.0.0–6.0.26
5.0.0–5.0.31
4.4.0–4.4.29
所有 v3.6、v4.0 和 v4.2 版本

修补分析

单行补丁改为根据输出结果计算消息大小，而非直接信任 OP_COMPRESSED BSON 中提供的值。这确保了分配的内存不会超过消息的实际大小。

-    return {output.length()};
+    return length;

抵御方案

升级到已修复的版本

修复补丁已在以下版本中发布：8.2.3、8.0.17、7.0.28、6.0.27、5.0.32 及 4.4.30。
升级至上述任一版本即可完全修复该漏洞。

通过网络分段减少暴露面

在应用补丁前，可通过以下分段措施显著降低暴露风险：

阻止对 TCP/27017 端口上 MongoDB 实例的入站互联网访问
仅允许来自明确可信来源的连接

使用 Akamai Guardicore Segmentation 识别有漏洞的主机

以下 Akamai Guardicore Segmentation Insight 查询可用于识别运行存在漏洞的 MongoDB 实例的主机。

Linux 资产

WITH LINUX AS (
  SELECT DISTINCT name, version, source
  FROM deb_packages 
  WHERE name = 'mongodb-org-server'
  UNION ALL
  SELECT DISTINCT name, version, source
  FROM rpm_packages
  WHERE name = 'mongodb-org-server'
),
PARSED AS (
  SELECT name, source, version,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 1) AS INTEGER) AS major,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 2) AS INTEGER) AS minor,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 3) AS INTEGER) AS patch
  FROM LINUX
)
SELECT name, source, version
FROM PARSED
WHERE
    (major = 8 AND minor = 2 AND patch BETWEEN 0 AND 2)
    OR
    (major = 8 AND minor = 0 AND patch BETWEEN 0 AND 16)
    OR
    (major = 7 AND minor = 0 AND patch BETWEEN 0 AND 27)
    OR
    (major = 6 AND minor = 0 AND patch BETWEEN 0 AND 26)
    OR
    (major = 5 AND minor = 0 AND patch BETWEEN 0 AND 31)
    OR
    (major = 4 AND minor = 4 AND patch BETWEEN 0 AND 29)
    OR
    (major = 3 AND minor = 6)
    OR
    (major = 4 AND minor IN (0, 2))

Windows 资产

WITH WINDOWS AS (
  WITH MONGO_PROGRAMS AS (
  SELECT DISTINCT name, version, install_source AS source, REGEX_MATCH(name, 'MongoDB [0-9].*', 0) AS mongo_match
  FROM programs
  WHERE name LIKE "MongoDB%"
  )
  SELECT DISTINCT name, version, source
  FROM MONGO_PROGRAMS
  WHERE LENGTH(mongo_match) > 0
),
PARSED AS (
  SELECT name, source, version,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 1) AS INTEGER) AS major,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 2) AS INTEGER) AS minor,
    CAST(REGEX_MATCH(version, '([0-9]+)\.([0-9]+)\.([0-9]+)', 3) AS INTEGER) AS patch
  FROM WINDOWS
)
SELECT name, source, version
FROM PARSED
WHERE
    (major = 8 AND minor = 2 AND patch BETWEEN 0 AND 2)
    OR
    (major = 8 AND minor = 0 AND patch BETWEEN 0 AND 16)
    OR
    (major = 7 AND minor = 0 AND patch BETWEEN 0 AND 27)
    OR
    (major = 6 AND minor = 0 AND patch BETWEEN 0 AND 26)
    OR
    (major = 5 AND minor = 0 AND patch BETWEEN 0 AND 31)
    OR
    (major = 4 AND minor = 4 AND patch BETWEEN 0 AND 29)
    OR
    (major = 3 AND minor = 6)
    OR
    (major = 4 AND minor IN (0, 2))