Conversation
Edited 26 days ago

Merry Christmas to everybody, except that dude who works for Elastic, who decided to drop an unauthenticated exploit for MongoDB on Christmas Day, that leaks memory and automates harvesting secrets (e.g. database passwords)

CVE-2025-14847 aka MongoBleed

Exp: https://github.com/joe-desimone/mongobleed/blob/main/mongobleed.py

This one is incredibly widely internet facing and will very likely see mass exploitation and impactful incidents

Impacts every MongoDB version going back a decade.

Shodan dork: product:"MongoDB"

11
29
0

@GossiTheDog oh for fuck's sake, what an asshole time to drop that one

1
0
0

The exploit is real and works, you can just run it and target specific offsets and/or keep running it until you get AWS secrets and such.

2
4
0
@GossiTheDog Maybe you are confusing MariaDB with MongoDB in their relation to MySQL?
0
0
5

@GossiTheDog .oO( Surely nobody exposes mongodb towards the inter-| OMGWTFBBQsrsly?

1
0
0

@GossiTheDog who the fuck exposes a DB directly to the internet?

0
0
0

@nblr @GossiTheDog ofc not, I bet on aistartups and governments :3
All information should be FREE!
Except the personal one ;-)

0
0
0

@GossiTheDog I am having a bit of trouble getting worked up about this.
The bug went public six days before Christmas. This means, frankly, that the folks who get paid to be bad actors, of which there are rather many nowadays, have had six days to figure out how to exploit it. I'm sure several of them had already figured it out before the Eclipse dude dropped the exploit.
By making the urgency of patching this issue clear, he has arguably done a public service.

0
1
0

@GossiTheDog Publishing an exploit on Christmas Day and not providing any info on how to detect exploitation is just the most stupid thing for a security vendor to do...

0
0
0

@GossiTheDog it would be great to add note that you don’t have to upgrade right now.

Disabling zlib for network compression in enough to mitigate

Either:

a) Restart mongod/mongos with option --networkMessageCompressors=snappy,zstd
(omit zstd on 3.6 and 4.0)

b) Disable in mongod.conf and restart

net:
compression:
# (omit `zstd` on 3.6 and 4.0)
compressors: snappy,zstd

And then plan upgrade after holidays

1
2
0

@GossiTheDog doesn't seem far to blame the PoC author? the exploit trigger was in the original diff as a unit test

0
1
0

@gsuberland @GossiTheDog the exploit was included as a unit test in the original patch, wiring that into a python script isn't slowing down attackers (but surely made the defenders take notice)

0
1
0

@GossiTheDog https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-14847 is a 404. I guess they assign a different CVE if one of their products based on MongoDB is affected?

0
0
0

I set up a honeypot for MongoBleed on a legit MongoDB instance, yolo and all that.

1
0
0

@alex @GossiTheDog Thank you. This is how all vuln announcements should look. Simple instructions for disabling the vector.

0
0
0

Just checked in on my MongoDB honeypot, it's had a few hundred MongoBleed attempts from 7 IPs so far.

3
2
0

One of the IPs in the honeypot is a ransomware/extortion group, they are blasting the internet. I have a capture of the traffic, it's an exact match to the mongobleed.py exploit by joe (it doesn't match a normal connect as it's invalidly formatted session).

3
2
0

@GossiTheDog I am sincerely surprised you can trace back an IP to a ransomware group, I'd expect them to be more careful to protect their Identity when trying out a new exploit. I mean, essentially they're giving away their game, especially when they are iterating, since their IPs are (as can be seen) scrutinized more than other's

0
0
0

@GossiTheDog None here. (If I understand correctly, using the exploit would generate many connections and nothing else.) Not even authentication attempts. Just a few IPs running commands (buildinfo, listDatabases, ismaster, etc.) without prior authentication.

They seem to be looking for databases exposed to the Internet and not protected in any way? Unless something's wrong with the honeypot...

0
1
0

@GossiTheDog It simulates the login process of MongoDB 8.0.9, rejecting any credentials the attacker tries.

A normal attacker would connect, get information about the login method, then try to authenticate (first image).

Somebody exploiting this vulnerability would try to connect many times and nothing else (second image).

Instead, I am observing the attacker connecting once, then using some commands without attempting to authenticate (third image).

1
0
0

@GossiTheDog any advice if I find any publicly exposed Azure managed MongoDB databases like cosmos db? I asked support (went to a 3rd party v- address), and they’re doing the usual delay stuff, asking for information they don’t need.

0
0
0

So @cyb3rops has made a MongoBleed log detection tool https://github.com/Neo23x0/mongobleed-detector

I’ve tried it and it works on a pwned server.

1
2
0

@GossiTheDog Aha! I'm finally getting exploitation attempts at the MongoDB honeypot. Not many, though (only these 2) - yet it's been up for 2 days already.

0
0
0

A Christmas lesson:

Cyber people probably shouldn't post full chain exploits which automate stealing secrets on Christmas Day for new vulns in direct competitor products.

I mean, people can post whatever they want.. it would just be nice to have a holiday with family and all, rather than arming teenagers.

2
3
0

If anybody is wondering on honeypot activity, lots.

More worrying is the real world incidents, two at large orgs I know of so far where attackers have gained access to internal DevOps systems using stolen creds used on MongoDB systems. In both cases it’s Advanced Persistent Teenagers.

2
1
0

@GossiTheDog Only 9 attempts observed by my honeypot so far, with one of them giving up after only 5 consecutive connections (another tried 41 times - the maximum so far):

0
1
0

MongoDB have a blog out about

Notably:

- Internal find at MongoDB

- they notified customers of the issue and patch availability on December 23rd

- A security vendor published technical details on December 24th, Christmas Eve

- Somebody at Elastic, a direct competitor, published an exploit with full secret extraction feature on December 25th, Christmas Day

That was an impossible situation for orgs - the security industry poured fire on them and set their own customers on fire.

8
10
0

@GossiTheDog With security vendors like that, who needs enemies? 🙄 facepalm

0
1
0

@GossiTheDog If this is internal, why were they unable to wait until mid January?

0
1
0

@GossiTheDog I feel like there's enough data on what happens as soon as a patch drops, from what has happened every previous time, that the consequences of Mongo dropping a patch on the 23rd were pretty easy to predict.

0
1
0

@GossiTheDog @windsheep so it's their first day on the internet then? This was extremely predictable, and both Mongodb and elastic look very poorly.

0
0
0

@GossiTheDog that seems like a very difficult claim to prove - CVEs don't usually come with sufficient information to be able to detect exploitation at a distance.

In any event, the vast majority of CVEs don't have this degree of impact and ease of exploitation. The moment that this kind of vuln - pre-auth information disclosure - is known to exist, it's basically inevitable that many actors, for a variety of reasons, will seek to develop an exploit for it.

0
0
0

@GossiTheDog and this right here is why I left IT security - security vendors dropping trou and taking a massive steaming shit on their competitors products while screaming LOOK AT ME IM DOING A SECURITY!!!

0
1
0

@GossiTheDog

> Somebody at Elastic, a direct competitor, published an exploit with full secret extraction feature on December 25th, Christmas Day

Which means if you're doing business with Elastic, you're doing business with someone who will intentionally and deliberately risk or outright destroy their own customers for completely imagined gains.

But as we have seen, having anything resembling ethics, morals, or a conscience is treated as a 'weakness.'

1
2
0

@rootwyrm @GossiTheDog

Coordinated ~Disclosure~ Dickmove by

1
1
0

@GossiTheDog @womble

From firsthand knowledge as an internal pentester whose team published > 2000 CVEs over about a decade or so, every single vulnerability we reported had an exploit but were never published.

Published is really what matters here. From details like "XSS in >software<" it's not really obvious or likely to become a working exploit 90% of the time unless someone is highly motivated. Especially factoring in the break they probably figured nobody would be that much of an asshole even if they did figure it out.

0
1
0

@badsamurai @GossiTheDog and hey! Why are we not surprised that he's only active on the site that protects Nazis (but pretends not to promote them!)

If I was an Elastic customer, my sales rep would've gotten a 1AM call from the lawyers demanding a very large settlement to cover costs of responding to a security incident they INTENTIONALLY caused, along with notice that the breach of contract suit will be right behind it.

1
0
0

@rootwyrm

Hah! And their sales will ignore you in the same key stroke they post what Mongo Bleed2Bleed sales taught them with creepy holiday pictures of their Ar*an family on LinkedIn.

@GossiTheDog

0
1
0

@GossiTheDog elastic need a kicking tbh

Also which security vendor?

1
1
0

@nieldk @GossiTheDog no reason to have posted that in such detail on Xmas eve. Other than wanting to be first.

MongoDB had no choice but to release patch ASAP but Ox and _Dez should have waited given the time of year

0
1
0