12月19日，MongoDB开发工程团队发布8.2.3、8.0.17、7.0.28、6.0.27、5.0.32以及4.4.30版本的重大更新，修补高风险漏洞CVE-2025-14847（MongoBleed）。该漏洞源于MongoDB服务器中zlib组件的实现问题，可能导致未初始化的内存堆栈泄露。4.0版本的CVSS评分为8.7分，3.1版本的CVSS风险评分为7.5分。目前已有安全公司与研究人员披露更多细节，并警告该漏洞已被用于实际攻击。

软件供应链安全公司OX Security最早披露了漏洞细节，指出未经身份验证的攻击者可从MongoDB服务器内存中泄露敏感数据，整个过程无需登录。攻击者可通过发送恶意网络数据包，触发zlib组件的缺陷，从而截取部分私有信息片段，包括用户信息、密码和API密钥。

根据MongoDB开发团队发布的补丁内容，OX Security指出问题出现在网络传输层：数据库在解压缩网络消息时，可能被迫处理极小的内存缓冲区。根本原因是用于返回解压缩数据大小的命令，实际返回的是已分配的内存数量，使攻击者能够利用zlib泄露数据。

Elastic安全团队研究员Joe Desimone公布了概念验证（PoC）代码，并指出CVE-2025-14847的发生原因是zlib在解压缩消息过程中出现缺陷，导致攻击者可从MongoDB中泄露数据。由于该漏洞与2014年爆发的OpenSSL严重漏洞Heartbleed（CVE-2014-0160）类似，他将CVE-2025-14847命名为MongoBleed。

安全专家Kevin Beaumont认为，MongoBleed极易被利用。攻击者只需获取MongoDB实例的IP地址，即可使用上述概念验证代码，从数据库中提取明文密码或AWS密钥等机密信息。全球共有21.4万台MongoDB主机，加上已有概念验证工具，预计很快将出现大规模漏洞利用。

威胁情报公司Censys警告，截至12月27日，已检测到超过8.7万台MongoDB实例存在该漏洞，其中美国近2万台最多，中国约1.7万台居次，德国、印度和法国分别超过7700台、5400台和5100台。中国大陆有多少MongoDB实例暴露在外，目前尚无明确数据。

值得注意的是，已有安全公司发现漏洞正在被利用。云安全公司Wiz表示，自12月26日Joe Desimone公布概念验证代码后不久，便发现有人实际利用该漏洞。由于该漏洞广泛存在于云环境中，42%的云环境存在MongoBleed，且攻击者无需身份验证，利用过程无需用户交互，因此暴露在互联网上的MongoDB服务器极易成为攻击目标，影响范围极为广泛。Wiz还提到，同样使用zlib的Ubuntu rsync组件也可能受MongoBleed影响，但具体细节尚不明确。