Issue Description
Mismatched length fields in Zlib compressed protocol headers may allow a read of uninitialized heap memory to an unauthenticated client.
We have released patch versions for MongoDB versions (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, 4.4.30) to address this issue. We highly recommend you upgrade your MongoDB clusters to the latest version to apply this patch.
See CVE-2025-14847 for more information.
This issue does not impact WiredTiger on-disk compression, only MongoDB network compression.
Affected Versions
The following MongoDB Server versions are affected:
All 8.2 versions prior to 8.2.3
All 8.0 versions prior to 8.0.17
All 7.0 versions prior to 7.0.28
All 6.0 versions prior to 6.0.27
All 5.0 versions prior to 5.0.32
All 4.4 versions prior to 4.4.30
All 4.2 versions
All 4.0 versions
All 3.6 versions
Mitigation Steps
Enterprise Advanced
Upgrade your MongoDB Server version to one of the following patch versions:
8.2.3
8.0.17
7.0.28
6.0.27
5.0.32
4.4.30
Visit the downloads page to download the latest binaries.
Ops Manager
Upgrade your MongoDB Server version to one of the following patch versions:
8.2.3
8.0.17
7.0.28
6.0.27
5.0.32
4.4.30
Visit the downloads page to download the latest binaries.
If using Automation, see Change the Version of MongoDB.
If using Local Mode you must first populate your Versions Directory on each Ops Manager with the correct OS specific binaries from the MongoDB Ops Manager Download site. See Configure Deployment to Have Limited Internet Access.
Cloud Manager Automation
Upgrade your MongoDB Server version to one of the following patch versions:
8.2.3
8.0.17
7.0.28
6.0.27
5.0.32
4.4.30
If using Automation, see Change the Version of MongoDB.
MongoDB Enterprise Kubernetes Operator and MongoDB Community Kubernetes Operator
Adjust the spec.version of your MongoDB Deployments to the latest patch of your current major release:
8.2.3-ent
8.0.17-ent
7.0.28-ent
6.0.27-ent
5.0.32-ent
4.4.30-ent
If You Cannot Upgrade Immediately
If you cannot upgrade immediately, we recommend the following alternative controls.
Ensure you test the other compressors before applying these changes to avoid disabling compression entirely.
Note that after zlib is removed, clients that specify only zlib compression will no longer use compression. To continue using compression, specify snappy or zstd for your clients in one of two ways:
Set the compression algorithm in your connection string.
Set the compression algorithm as specified by your driver. See the appropriate driver information in the MongoDB documentation.
Enterprise Advanced
By default, the allowed compressors are
snappy,zstd,zlib. Remove zlib from your allowed list of compressors by setting it tosnappy,zstduntil the clusters are upgraded. Note that zlib is allowed by default, so you must explicitly set the value tosnappy,zstdto remove it.Review network settings and ensure your clusters are only accessible from required IP addresses.
Cloud Manager and Ops Manager
Remove zlib by excluding it from the list of allowable compressors from each managed deployment using Advanced Options for MongoDB Deployments.
Open Advanced Options for the cluster, search for "compress".
Select networkMessageCompressors and enter
snappy,zstd.Save, Review & Deploy, Confirm & Deploy. The cluster will do a rolling restart to apply the changes.
Review network settings and ensure your clusters are only accessible from required IP addresses.
Self-Managed Enterprise Deployments
If you are only monitoring your deployments, or not using Ops Manager nor Cloud Manager, then you must manually adjust the net.compression.compressors settings and restart your MongoDB processes in a rolling fashion.
Configuration file changes:
Starting with the Secondary Replica Set Members:
Edit the
mongod.confand patch or merge in the following network settings. (Important, if you already have anet:ornet.compression:section, insert or merge the changes therein).net: compression: compressors: snappy,zstd
Restart the MongoDB process.
Proceed to the next secondary node and repeat the above steps.
Lastly, step down the primary node and complete the final configuration change.
CLI Parameter Changes:
If you are not using a MongoDB configuration file, add or adjust the mongod/mongos CLI parameter with --networkMessageCompressors=snappy,zstd (omitting zlib)
MongoDB Resources Managed by MongoDB Enterprise Kubernetes Operator (MEKO) or MongoDB Controller for Kubernetes (MCK)
Adjust the MongoDB Custom Resource for all affected deployments with the following yaml patch:
spec: additionalMongodConfig: net: compression: compressors: "snappy,zstd"
How to validate the compressor mitigation steps:
Connect and authenticate to the cluster using mongosh.
Run the following command:
db.serverStatus().network.compression
Confirm zlib is not present.
Example:
{ snappy: { compressor: { bytesIn: Long('1408774'), bytesOut: Long('945748') }, decompressor: { bytesIn: Long('950567'), bytesOut: Long('1586773') } }, zstd: { compressor: { bytesIn: Long('0'), bytesOut: Long('0') }, decompressor: { bytesIn: Long('0'), bytesOut: Long('0') } } }
Supplemental Information
For more information on network compression, see the following information:
For information on driver specific compression, see the appropriate driver information in the MongoDB documentation.
FAQ
How was this issue discovered?
This issue was discovered internally within MongoDB during our standard internal code audits.
How do we know the issue wasn't already found externally?
At this time we are not aware of any evidence of this specific issue being identified or discussed externally.
Was customer metadata impacted?
At this time we are not aware of any evidence that customer metadata was accessed improperly.
Was customer data stored in MongoDB impacted?
At this time we are not aware of any evidence that customer data stored in MongoDB was accessed improperly.
What steps has MongoDB taken to mitigate this issue?
A patch was successfully developed, tested, and released to mitigate the issue.
How can you be confident there are not any further issues?
We will continue to scrutinize MongoDB code and issue fixes when warranted, consistent with our ongoing security efforts.
My cluster is not connected to the internet, am I at risk?
While an 'air-gapped' or isolated network significantly reduces the opportunity for attack, it does not eliminate risk. Unpatched clusters could still be exploited by a compromised internal asset or a 'trusted' user within your perimeter. We recommend applying the mitigation regardless of internet connectivity.
Is there evidence of any active exploitation in the wild?
This issue was discovered internally within MongoDB during our internal code audits. We are currently unaware of any external parties having discovered this or exploited it.
We operate under regulatory guidelines; do we have reporting or disclosure requirements?
We understand the importance of assessing regulatory impact. However, how any laws or regulations might apply to your organization depends on those specific laws or regulations, as well as your specific facts and circumstances. We recommend consulting your legal and compliance teams.