MongoBleed
61 points
by gpi
10 hours ago
| 3 comments
| github.com
| HN
▲
FridgeSeal
6 hours ago
[-]
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.

reply
▲
dpark
7 hours ago
[-]
Do people usually run Mongo in a mode that allows unauthenticated calls? I don’t know anything about Mongo. This just seems surprising.
reply
▲
erdaniels
6 hours ago
[-]
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.

reply
▲
computerfan494
6 hours ago
[-]
We received communication that all Atlas clusters were upgraded with the fix before the vulnerability was announced.
reply
▲
yearolinuxdsktp
4 hours ago
[-]
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.
reply
▲
giancarlostoro
6 hours ago
[-]
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.

reply
▲
ehnto
1 hour ago
[-]
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.

reply
▲
winrid
4 hours ago
[-]
Luckily most people wouldn't use zlib anyway, they'd use snappy or zstd, and this also requires authenticated access to the cluster ....
reply
▲
mirashii
2 hours ago
[-]
> 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.

reply