No, but it's pretty common IME to create an Atlas cluster that has internet-wide access (0.0.0.0/0) when testing and forgetting to turn this off. According to https://jira.mongodb.org/browse/SERVER-115508, this affects unauthenticated ops. Based on the repro code itself, it looks like this happens way before authentication is checked for the corresponding OP at the OP_MSG decoding level.
So if you're using Atlas, check that your Cluster has auto upgraded already. If you're using 0.0.0.0/0, stop doing that and prefer a limited IP address range and even better, use VPC Peering or other security/network boundary features.
This is a good example of a benefit of certificate-based authentication option for MongoDB, because you need to at least present a valid client certificate to transmit any data.
Its default is to only take connections that are local, usually I have my mongo clients SSH into a mongo server as opposed to opening up the port to the internet. Some Mongo users / collections are very open by default.
It has been a minute since I used Mongo for production grade projects, so some things could have changed since then.
I don't think I would be comfortable serving any DB over the internet these days, exploit scanners are so agressand ubiquitous that a breach would feel inevitable.
Not that it is fool proof, but if I am setting up the infrastructure I can probably control where the DB is deployed, so I would colocate it with the application servers on a local network or virtual local network, that is all I would be comfortable with.
When vulnerability description says “unauthenticated exploit” that means that you can exploit without being required to authenticate first. It means it just works even with authentication being required on the server.
When it says “authenticated exploit” it means you need to pass authentication first in order to trigger exploit whatever it may be.
Current link points straight to the Python code without a lot of context, so here’s the top of the readme:
> CVE-2025-14847 - MongoDB Unauthenticated Memory Leak Exploit
> A proof-of-concept exploit for the MongoDB zlib decompression vulnerability that allows unauthenticated attackers to leak sensitive server memory.
Do people usually run Mongo in a mode that allows unauthenticated calls? I don’t know anything about Mongo. This just seems surprising.
No, but it's pretty common IME to create an Atlas cluster that has internet-wide access (0.0.0.0/0) when testing and forgetting to turn this off. According to https://jira.mongodb.org/browse/SERVER-115508, this affects unauthenticated ops. Based on the repro code itself, it looks like this happens way before authentication is checked for the corresponding OP at the OP_MSG decoding level.
So if you're using Atlas, check that your Cluster has auto upgraded already. If you're using 0.0.0.0/0, stop doing that and prefer a limited IP address range and even better, use VPC Peering or other security/network boundary features.
We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.
This is a good example of a benefit of certificate-based authentication option for MongoDB, because you need to at least present a valid client certificate to transmit any data.
> No, but it's pretty common IME to create an Atlas cluster that has internet-wide access (0.0.0.0/0) when testing and forgetting to turn this off.
That is a ridiculous default.
Its default is to only take connections that are local, usually I have my mongo clients SSH into a mongo server as opposed to opening up the port to the internet. Some Mongo users / collections are very open by default.
It has been a minute since I used Mongo for production grade projects, so some things could have changed since then.
I don't think I would be comfortable serving any DB over the internet these days, exploit scanners are so agressand ubiquitous that a breach would feel inevitable.
Not that it is fool proof, but if I am setting up the infrastructure I can probably control where the DB is deployed, so I would colocate it with the application servers on a local network or virtual local network, that is all I would be comfortable with.
When vulnerability description says “unauthenticated exploit” that means that you can exploit without being required to authenticate first. It means it just works even with authentication being required on the server.
When it says “authenticated exploit” it means you need to pass authentication first in order to trigger exploit whatever it may be.
What an awful vulnerability. The most interesting fact is that this has been there since the PR that introduced it in 2017[1].
I'm not sure how Mongo's review process works, but it seems like this one had zero review.
[1] - https://github.com/mongodb/mongo/pull/1152
This is astronomical. If I correctly understood, the full on compromise of Ubisoft happened because of this.
Good write ups:
https://doublepulsar.com/merry-christmas-day-have-a-mongodb-...
https://blog.ecapuano.com/p/hunting-mongobleed-cve-2025-1484...
The problem is that about 20% of mongodb users are still on v4 for which not patch has been provided since it reach end of support on Feb 2024...
Incorrect, the company patched 4.4 on 12/19/25 with a special 4.4.30 release:
https://www.mongodb.com/docs/v4.4/release-notes/4.4/#4.4.30-...
Luckily most people wouldn't use zlib anyway, they'd use snappy or zstd, and this also requires authenticated access to the cluster ....
> authenticated access to the cluster
No it doesn’t.
> they'd use snappy or zstd
What is being used more doesn’t matter, what’s compiled in and enabled matters.