MongoBleed Explained Simply

Summary

MongoBleed, officially CVE-2025-14847, is a recently-uncovered extremely sensitive vulnerability affecting basically all versions of MongoDB since ~2017.It is a bug in the zlib message compression path in MongoDB.It allows an attacker to read off any uninitialized heap memory, meaning anything that was allocated to memory from a previous database operation could be read.The bug was introduced in 2017. It is dead-easy to exploit - it only requires connectivity to the database (no auth needed). It is fixed as of writing, but some EOL versions (3.6, 4.0, 4.2) will not get it.Let’s get a few basics out of the way before we explain the bug:MongoDB uses its own TCP wire protocol instead of e.g HTTP. This is standard for databases, especially ones chasing high performance.Mongo uses the BSON format for messages. It’s basically binary json but with some key optimizations. We will talk about one later because it is essential to the exploit.Mongo doesn’t have endpoints or RPCs. It only uses a single op code called OP_MSG.The OP_MSG command contains a BSON message. The contents of the message denote what type of request it is. Concretely, it’s the first field of the message that marks the request type. The request can be compressed. In that case, an OP_COMPRESSED message is sent which wraps the now-compressed OP_MSG BSON.The request then looks like this: OP_COMPRESSED message ┌────────────────────────────┐ │ standard header (16 bytes) │ ├────────────────────────────┤ │ originalOpcode (int32) │ │ uncompressedSize (int32) │ │ compressorId (int8) │ │ compressed OP payload │ └────────────────────────────┘The first part of the exploit is to get the server to wrongfully think that an overly-large OP_MSG is coming.An attacker can send a falsefully large `uncompressedSize` field, say 1MB, when in reality the underlying message is 1KB uncompressed. This will make the server allocate a 1MB buffer in memory to decompress the message into. This is fine.The critical bug here is that, once ...