Podcast Detail

SANS Stormcast Sunday, December 28th, 2025: MongoDB Unauthenticated Memory Leak CVE-2025-14847

If you are not able to play the podcast using the player below: Use this direct link to the audio file: https://traffic.libsyn.com/securitypodcast/9750.mp3

previous
Podcast Logo
MongoDB Unauthenticated Memory Leak CVE-2025-14847
00:00

Podcast Transcript

 Hello and welcome to the Sunday, December 28, 2025
 edition of the SANS Internet Storm Centers Stormcast. My
 name is Johannes Ullrich and today I'm recording from
 Jacksonville, Florida. And this episode is brought to you
 by the SANS.edu Undergraduate Certificate Program in
 Cybersecurity Fundamentals. Sadly, we do have, well, a
 little bit one of those special Christmas presents
 that we got here that required me to do, after some
 reconsideration, a special podcast. I at least want to
 get it out there and make you decide whether or not this is
 something that's important or critical for you. The problem
 here is MongoDB. On the 24th, a patch was released for
 MongoDB. So, well, a Christmas gift patch. Problem was that
 this patch also fixed a critical vulnerability in
 MongoDB, a memory leak issue or really a memory disclosure
 issue. The vulnerability is a little bit like heart bleed.
 So, what's happening here is that MongoDB does accept BSON
 formatted data. BSON binary JSON. So, it's not JSON. It's
 sort of a more binary encoded form of JSON that also allows
 for compression. Well, with compression, we always have
 the issue that length of things change as it's being
 decompressed and we have to track this. Usually, you know,
 this has in the past that caused many, many buffer
 overflows. This one is different where the buffer
 size being reported back is actually the size of the
 entire allocated memory, not just the size of the memory
 that was actually used. And it's particular if a BSON file
 was parsed by MongoDB that, well, did lie a little bit
 about its content length. So, what's happening with that
 extra memory? Well, it's going to be filled with essentially
 random allocated memory for the MongoDB process. That may
 contain any MongoDB data that's available there,
 including, of course, secrets like keys and the like and
 definitely, you know, data that you don't want to leak.
 So, a patch has been made available, sadly, with the
 patch. A test case was published also that was
 essentially a proof of concept exploit. So, an exploit is
 available. The exploit is also not terribly complicated.
 Really just adjusting a length field in BSON data that you're
 sending to MongoDB will do the trick. Apparently,
 exploitation is also already underway. If you do have
 MongoDB exposed to the internet, assume someone
 already is working on trying to apply this exploit to your
 variable instance. My number one recommendation here would
 be don't expose MongoDB. Never really got the fascination
 that people have with exposing all these no SQL databases to
 the internet. I would have never done that with a SQL
 database, but I guess no SQL, there's other things that you
 don't need if you don't need SQL. So, that's why people
 exposed to the internet. In particular, with MongoDB,
 there are some ways how you can use JavaScript, for
 example, to access directly, which is, I think, one of the
 reasons why people are tempted to expose it like this. So,
 make sure that you aren't exposing MongoDB. It is
 included in a lot of other projects and other products.
 For example, Unify and their controllers does include
 MongoDB, and a bunch of other systems like that include
 MongoDB sort of as a database. So, even if you aren't
 familiar with MongoDB, certainly it may be running in
 your network, even though if it's not exposed. If it's not
 exposed, then, of course, the vulnerability is less severe.
 It's more difficult to exploit. Then, of course, it
 depends on how it is exposed. Is it just to the local
 network or just on loopback? These are sort of some of the
 considerations that matter to figure out how critical this
 issue is for you. Assume all versions of MongoDB. I think
 back to 3.6 I've seen. So, really, all versions that are
 currently realistically in use are vulnerable if they haven't
 been patched within the last week. Anyway, just want to get
 this out here. I'm not sure if I'll do another podcast before
 the new year. If not, then hope all goes well and you
 don't have to start the new year with an incident based on
 this MongoDB wannabe. Oh, and one thing I do want to mention
 is if you do feel like you have been attacked and you
 have some incident here, this is not about running arbitrary
 code on your system. This is about stealing credentials.
 So, you definitely, if you find an exposed unpatched
 MongoDB instance, changing rotating credentials is really
 critical here and you're looking at what data MongoDB
 touched here and what potentially could be an issue
 here if it's being leaked. That's really how you have to
 approach this. So, command execution may come later using
 some of those credentials, but at first these credentials
 will be what the attacker is after. Well, and that's it for
 today. So, thanks for listening and talk to you
 again. Well, hopefully not this year, but maybe one more
 this year and then another one after the new year. Bye.