.svg)
.png)
Since the publication of the MongoBleed (CVE-2025–14847) PoC on the 25th of December, 2025, organizations have been rushing to patch it. However, many publicly accessible instances remain unpatched; of those scanned on the 30th, nearly 70% were found to still be vulnerable. Many affected organizations will now have to investigate their mongo instance and search for intrusions on top of the patch installation, as widespread exploitation has been going on since the 28th.
The detections suggested by many are based on the fact that the published PoC connects to the MongoDB instance but does not send metadata about the connection. As noted by the authors of these detection methods, this behavior is not inherent to the exploitation of the vulnerability itself, but rather specific to how this particular PoC was written. It is a small leap to assume that more resourceful and stealthy threat actors would exploit this vulnerability while attempting to leave the exact same trace in the logs as a normal connection.
Vulnerable instances on December 28th
The vulnerability lies in the decompression of a user-supplied zlib buffer into a larger unclean buffer. Following decompression, MongoDB attempts to parse the data as BSON (a MongoDB-specific, JSON-like format).
For the vulnerability to work, the BSON parsing attempt must fail and prompt MongoDB to send an error message back to the initiator. This message provides the leaked data used by the exploit:
Press enter or click to view image in full size
But as with most errors, this error is not only sent to the user but can also be logged. While examining the BSON parsing logic in MongoDB, we discovered this function, which is called for every BSON document.
Let’s look into the validate function in “src/mongo/bson/bson_validate.cpp”:
Press enter or click to view image in full size
We can see a few interesting assert based logs that could be relevant to our case.
Our research team at Unfold wanted to identify a simple but efficient way to determine if a given instance has been compromised and, if possible, when. By diving into the logging functions, we identified the AssertionCount class:
Press enter or click to view image in full size
The class is quite self-explanatory; it counts how many times each type of assertion has failed. The rollovers field is used to track how many times any assertion counter has reached MAX_UINT and been reset.
Logging into our MongoDB shell, we can extract that exact assertion count data:
my_mongo> db.serverStatus().asserts
{
regular: 3,
warning: 6,
msg: 3,
user: 3,
tripwire: 12,
rollovers: 2
}After running the PoC, the assert statistics look quite different:
my_mongo> db.serverStatus().asserts
{
regular: 3,
warning: 6,
msg: 3,
user: 3187,
tripwire: 12,
rollovers: 2
}
Notice the significant uptick in user assertions. This allows us to ascertain whether it’s likely an instance has been exploited, but it could easily produce false positives. This stems from the fact that assertion metrics are cumulative since the last server restart and can be influenced by other user actions. In addition, we cannot determine exactly when the exploitation happened or identify the source IPs.
The Full-Time Diagnostic Data Capture (FTDC) subsystem of MongoDB offers an often overlooked source of telemetry. FTDC operates independently of standard log verbosity levels and captures internal server statistics that are rotated infrequently. The FTDC structure is undocumented and considered an internal component of MongoDB. One of the main data sources for FTDC is the serverStatus category, which can be viewed by calling db.serverStatus(). By default, FTDC records changes to this data approximately every five minutes. As a result, asserts is one of the keys saved, allowing its changes to be closely tracked.
We can detect an exploitation attempt with certainty by identifying a clear uptick in user assertions, which allows us to pinpoint the duration, approximate volume of requests, and timing of the attack. Since we can determine exactly when and how many requests were sent, we can easily correlate this data with connection logs to identify the attackers’ source IP addresses:
Found 4 FTDC file(s)
------------------------------------------------------------
metrics.2025-12-31T07-15-54Z-00000: 15 samples
metrics.2025-12-31T08-27-06Z-00000: 1 samples
metrics.2025-12-31T08-31-22Z-00000: 16 samples
metrics.interim: 1 samples
------------------------------------------------------------
Total samples: 33
Earliest diagnostic: 2025-12-31T07:15:55+00:00
Latest diagnostic: 2025-12-31T09:45:52+00:00
============================================================
USER ASSERT PEAKS DETECTED (>100 in 5 minutes)
============================================================
Peak #1:
Time: 2025-12-31T07:30:55+00:00 -> 2025-12-31T07:35:55+00:00
Duration: 5.0 minutes
Asserts: 17 -> 663 (delta: +646)
Peak #2:
Time: 2025-12-31T07:35:55+00:00 -> 2025-12-31T07:40:55+00:00
Duration: 5.0 minutes
Asserts: 663 -> 1995 (delta: +1332)
Peak #3:
Time: 2025-12-31T07:45:55+00:00 -> 2025-12-31T07:50:55+00:00
Duration: 5.0 minutes
Asserts: 1995 -> 2430 (delta: +435)
Peak #4:
Time: 2025-12-31T07:50:55+00:00 -> 2025-12-31T07:55:55+00:00
Duration: 5.0 minutes
Asserts: 2430 -> 3266 (delta: +836)
Peak #5:
Time: 2025-12-31T08:31:23+00:00 -> 2025-12-31T08:36:23+00:00
Duration: 5.0 minutes
Asserts: 16 -> 403 (delta: +387)We’re happy to share our detection approach and code to help you determine whether your server was attacked, feel free to reach out on sos@unfold.ai or DM on Linkedin.
If you are still concerned or if patching isn’t immediately possible, we can help. We are unfolding what’s really happening inside your different assets.
Eric Capuano - Hunting MongoBleed
Florian Roth - mongobleed-detector