Friday, January 16, 2026

CVE-2025-14847 (MongoBleed) — A Excessive-Severity Reminiscence Leak in MongoDB


A excessive severity vulnerability, known as “mongobleed” (CVE-2025-14847) has been recognized in most variations of MongoDB Neighborhood and Enterprise editions and MongoDB Atlas. Percona Server for MongoDB (PSMDB) can be affected, since it’s based mostly on the upstream MongoDB Neighborhood code base. This situation impacts all MongoDB server binaries the place zlib community compression is allowed.
Beneath, we define the small print of the vulnerability, the steps Percona is taking, and the actions we suggest you are taking to mitigate threat.

Vulnerability particulars:

The mongobleed vulnerability permits an unauthenticated distant attacker with community entry to a mongod or mongos occasion to extract fragments of uninitialized server reminiscence, which can comprise delicate knowledge.
This vulnerability can solely be exploited if each of the next situations are true:

  • The MongoDB server is reachable over the community, and
  • zlib community compression is allowed (default worth)

Servers that aren’t network-reachable (e.g. embedded techniques) or don’t permit zlib compression aren’t uncovered to this situation.

Affected MongoDB variations embrace:

  • MongoDB 8.2.0 via 8.2.2
  • MongoDB 8.0.0 via 8.0.16
  • MongoDB 7.0.0 via 7.0.26
  • MongoDB 6.0.0 via 6.0.26
  • MongoDB 5.0.0 via 5.0.31
  • MongoDB 4.4.0 via 4.4.29
  • All MongoDB Server 4.2, 4.0, and three.6 variations

Percona is actively making ready and validating patches for at present supported PSMDB releases. Releases are anticipated for the primary week of January.

Mitigation steps:

Till patched variations can be found, we strongly suggest disabling zlib community compression on all affected MongoDB servers.
MongoDB cases negotiate compression within the following order by default: snappy, zstd, then zlib. As a result of zlib is the ultimate fallback, it’s typically not utilized in observe, so disabling it shouldn’t have any useful affect for many deployments.

Many drivers negotiate compression mechanically. If purchasers explicitly request zlib, they might decline to barter compression together with your server or fall again to a different compressor. Guarantee purchasers favor snappy or zstd and don’t embrace zlib in their very own configuration.

Should you begin MongoDB manually, add the next parameter:

For a mongos router:

Should you use a configuration file (mongod.conf or mongos.conf), add or modify the compression part and restart the method (Reproduction units or sharded clusters might be restarted in a rolling style):

This explicitly lists solely supported, non-vulnerable compressors and omits zlib completely.

Verification

To verify zlib is disabled, connect with the server and examine the output of the next command:

Anticipated end result:

You might also check a shopper connection that explicitly requests zlib:

Then examine mongod.log to confirm that no compressor was negotiated:

When you have put in Percona Monitoring & Administration (PMM), you can too examine metrics particularly for zlib to make sure after the adjustments in web.compression, no knowledge will get transmitted utilizing zlib.

For server-side you possibly can examine mongodb_ss_network_compression_zlib_compressor_bytesIn, and for shopper aspect mongodb_ss_network_compression_zlib_decompressor_bytesIn ought to cease growing.

When you have questions or would really like help validating your configuration, please contact Percona Help.

Related Articles

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Latest Articles