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.
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.
Good write ups:
https://doublepulsar.com/merry-christmas-day-have-a-mongodb-...
https://blog.ecapuano.com/p/hunting-mongobleed-cve-2025-1484...
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.
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.
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.