惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园_首页
Engineering at Meta
Engineering at Meta
量子位
A
About on SuperTechFans
阮一峰的网络日志
阮一峰的网络日志
Recent Announcements
Recent Announcements
博客园 - 司徒正美
V
Visual Studio Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The GitHub Blog
The GitHub Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
腾讯CDC
Jina AI
Jina AI
C
Check Point Blog
H
Help Net Security
罗磊的独立博客
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
V
V2EX
爱范儿
爱范儿
I
InfoQ

Wiz Blog | RSS feed

Meet Wiz for M365: Bringing SaaS into the Security Graph Bringing Security Visibility to Vercel with Wiz Axios NPM Distribution Compromised in Supply Chain Attack Tracking TeamPCP: Investigating Post-Compromise Attacks Seen in the Wild The Wiz Blue Agent, now Generally Available Beyond the Badge: What Achieving Microsoft’s Certified Software Designation Means for Your Cloud Security Introducing the Green Agent: AI-Powered Remediation for the Cloud Three’s a Crowd: TeamPCP trojanizes LiteLLM in Continuation of Campaign KICS GitHub Action Compromised: TeamPCP Strikes Again in Supply Chain Attack Introducing the Wiz Red Agent- AI-Powered Attacker Introducing Wiz AI Application Protection Platform (AI-APP) Introducing Wiz Agents & Workflows: Security at the Speed of AI AI Runtime Threat Detection: From Input to Real-World Impact Trivy Compromised: Everything You Need to Know about the Latest Supply Chain Attack It’s Official: Wiz Joins Google Understanding and Reducing AI Risk in Modern Applications Introducing Wiz Tenant Manager: Multi-Tenant Management for Federated Organizations The Agile FedRAMP Playbook, Part 4: Reactive Risk Management through Enriched Incident Response Wiz Achieves CPSTIC Certification in Spain Seeing AI Clearly: Building Visibility Across Modern AI Applications The Agile FedRAMP Playbook, Part 3: Preventative Risk Management by building Secure by Design Wiz Leads the 2026 Latio Application Security Report with awards in 4 categories Building an Agentic Cloud Security Ecosystem: A Reference Architecture with Wiz MCP and Infosys Cyber Next The Agile FedRAMP Playbook, Part 2: Proactive Risk Management with Continuous Monitoring Cloud-native Security for your Windows environment: Announcing the Wiz Runtime Sensor for Windows Would You Click ‘Accept’? Automatically detecting malicious Azure OAuth applications using LLMs Wiz Named a Leader in The Forrester Wave™: Cloud Native Application Protection Solutions, Q1 2026 From Detection to Remediation: It’s Time to Rethink AppSec Around Exploitability and Root Cause Fixes The Agile FedRAMP Playbook, Part 1: Why Risk is Your Best Starting Point Introducing AI Cyber Model Arena: A Real-World Benchmark for AI Agents in Cybersecurity
MongoBleed (CVE-2025-14847) exploited in the wild: everyt...
Merav Bar, Amitai Cohen, Yaara Shriki, Gili Tikochinski · 2025-12-28 · via Wiz Blog | RSS feed

MongoDB has disclosed a high-severity unauthenticated information leak vulnerability, tracked as CVE-2025-14847 and dubbed MongoBleed (after HeartBleed), affecting multiple supported and legacy MongoDB Server versions. The flaw can be exploited remotely by unauthenticated attackers with low complexity, potentially leading to exfiltration of sensitive data and credentials.

Self-hosted MongoDB instances remain at risk until patched, whereas MongoDB Atlas instances have been upgraded automatically and no customer action is required.

How do I know if I'm affected?

To determine if your specific MongoDB environment is vulnerable to CVE-2025-14847, follow the triage logic below. This flowchart guides you through the necessary checks regarding deployment type, server version, and the critical zlib compression configuration:

Flowchart to determine server vulnerability to MongoBleed

What is CVE-2025-14847?

CVE-2025-14847 stems from a flaw in MongoDB Server’s zlib-based network message decompression logic, which is processed prior to authentication. By sending malformed, compressed network packets, an unauthenticated attacker can trigger the server to mishandle decompressed message lengths, resulting in uninitialized heap memory being returned to the client. This allows attackers to remotely leak fragments of sensitive in-memory data without valid credentials or user interaction.

At a code level, the vulnerability was caused by incorrect length handling in message_compressor_zlib.cpp. The affected logic returned the allocated buffer size (output.length()) instead of the actual decompressed data length, allowing undersized or malformed payloads to expose adjacent heap memory.

Because the vulnerability is reachable prior to authentication and does not require user interaction, Internet-exposed MongoDB servers are particularly at risk.

Wiz Research data: what’s the risk to cloud environments?

Based on Wiz data, 42% of cloud environments have at least one instance of MongoDB in a version vulnerable to CVE-2025-14847, including both publicly exposed and internal resources. Wiz has been able to validate many internet-facing instances as exploitable.

Censys has reported observing 87K potentially vulnerable instances worldwide.

What sort of exploitation has been identified in the wild?

A working exploit has been publicly available since December 26, 2025, with initial reporting of exploitation in the wild reported shortly after, and the vulnerability has since been added to CISA KEV.

Which products are affected?

The vulnerability impacts MongoDB in versions 8.2.0 through 8.2.2, 8.0.0 through 8.0.16, 7.0.0 through 7.0.27, 6.0.0 through 6.0.26, 5.0.0 through 5.0.31, 4.4.0 through 4.4.29, and all MongoDB Server v4.2, v4.0, and v3.6 versions.

Note that Ubuntu originally stated that the same vulnerability affected multiple unrelated Ubuntu packages such as rsync due to their use of zlib, but this was later retracted.

Which actions should security teams take?

  1. Upgrade immediately to one of the patched versions: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32, or 4.4.30.

  2. If immediate patching is not possible, disable zlib compression by explicitly omitting it from networkMessageCompressors or net.compression.compressors. Safe alternatives include snappy, zstd, or fully disabling compression.

  3. Restrict network exposure of MongoDB servers (e.g., firewall rules, private networking).

  4. Monitor MongoDB logs for anomalous pre-authentication connections or unexpected crashes (see this blogpost from Eric Capuano for additional detection guidance, and this detection tool from Florian Roth).

  5. Plan upgrades for any remaining end-of-life MongoDB versions, as they remain permanently vulnerable.

How can wiz help?

Wiz customers can use the pre-built query and advisory in the Wiz Threat Center to search for vulnerable instances in their environment.

Update (December 31, 2025)

To assist security teams in validating exploitability, Wiz Research has published a custom Nuclei template (see below) designed to deterministically and safely detect if a MongoDB server is vulnerable to CVE-2025-14847, without exfiltrating data. This template validates the vulnerability by sending a single crafted packet that triggers the specific memory leak condition. It then analyzes the server's response for leaked BSON signatures, confirming the flaw exists without requiring authentication.

Nuclei Template

How this detection method helps defenders

While the original proof-of-concept exploit published by Joe Desimone is effective at demonstrating critical impact by aggressively harvesting data from the server's memory, this Nuclei template is engineered specifically for safe and simple exploitability validation. Real-world attacks observed in the wild often flood the server with thousands of connections to scrape large amounts of RAM. In contrast, this template sends a single, specially crafted packet. It is a low-intensity check that confirms the vulnerability by detecting the presence of a BSON signature in the unauthorized memory space, rather than actually parsing sensitive customer data.

How it works - the "magic" packet

The vulnerability acts as a buffer over-read caused by a trust issue in the MongoDB Zlib decompression logic. The flaw allows an attacker to arbitrarily dictate the size of the memory buffer the server allocates, regardless of how much data is actually provided in the compressed payload. The Hex payload used in this template exploits this by wrapping a valid, minimal BSON document, specifically {"a": 1}, inside a malformed OP_COMPRESSED message. The header of this message (specifically the uncompressedSize field) is set by the attacker to lie to the server, claiming the data will expand to a size significantly larger than what the tiny {"a": 1} payload actually requires.

When the server processes this packet, it trusts the header and allocates a large heap buffer based on the attacker's fake size. This buffer initially contains uninitialized "dirty" memory from previous operations. The decompression process writes the small {"a": 1} payload into the start of the buffer but leaves the rest of the space untouched. Because of the vulnerability, the server attempts to parse this entire buffer as BSON. It successfully reads the first valid document, but then continues reading the "dirty" memory as if it were part of the data stream.

Since this uninitialized memory is almost never valid BSON, the parser inevitably fails. Crucially, the resulting error message often quotes the "invalid" bytes it encountered, potentially leaking sensitive data back to the client. This mechanism explains why actual exploitation is a "game of chance" requiring multiple requests: the attacker is betting that the unallocated memory contains valuable data and that the specific way the parser fails will reveal it as a printable string. Our Nuclei template, however, bypasses this need for luck by inspecting the raw stream for BSON markers in the response, deterministically confirming the leak exists without needing to successfully extract readable secrets.

References