--- title: "MongoBleed: Critical Unauthenticated Memory Disclosure Hits MongoDB Server" url: https://radicalnotion.ai/blog/mongobleed-critical-unauthenticated-memory-disclosure-hits-mongodb-server-20251230154920 type: article description: "A critical vulnerability dubbed 'MongoBleed' allows unauthenticated attackers to extract sensitive data from MongoDB server memory through malformed Zlib headers. CISA confirms active exploitation in the wild." updated: 2026-03-21 source: RadicalNotion.AI license: CC BY-NC 4.0 (https://creativecommons.org/licenses/by-nc/4.0/) --- # MongoBleed: Critical Unauthenticated Memory Disclosure Hits MongoDB Server By Radical Notion Team, 2025-12-30 *A critical vulnerability dubbed 'MongoBleed' allows unauthenticated attackers to extract sensitive data from MongoDB server memory through malformed Zlib headers. CISA confirms active exploitation in the wild.* A critical vulnerability in MongoDB Server—dubbed "MongoBleed" by security researchers—is under active exploitation, allowing unauthenticated attackers to read sensitive data directly from server memory. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-14847 to its Known Exploited Vulnerabilities catalog on December 29, 2025, confirming that threat actors are already weaponizing this flaw. With affected versions spanning from MongoDB 3.6 through 8.2.2, this represents one of the most widespread database security incidents in recent memory. --- ## What Happened On December 15, 2025, MongoDB's internal security team discovered a critical flaw in how the database server handles Zlib-compressed protocol headers. The vulnerability stems from improper validation of length parameters in compressed network messages, allowing malicious clients to trigger the server to return uninitialized heap memory—potentially containing database credentials, session tokens, personally identifiable information (PII), or other sensitive data residing in RAM. MongoDB moved swiftly, releasing patches across six major version branches on December 19, 2025, just four days after discovery. However, by December 29, security researcher Joe Desimone published a proof-of-concept exploit titled "mongobleed" on GitHub, and CISA confirmed active exploitation in the wild. The compressed timeline between patch release and confirmed exploitation underscores the critical nature of this vulnerability. The name "MongoBleed" intentionally evokes the infamous 2014 Heartbleed vulnerability in OpenSSL, which similarly allowed attackers to extract memory contents from vulnerable servers. Like Heartbleed, MongoBleed requires no authentication and can be exploited remotely over the network, making it a prime target for automated scanning and exploitation. --- ## Understanding the Vulnerability ### The Root Cause MongoDB Server supports multiple compression algorithms for network traffic, including Zlib, Snappy, and Zstd. When a client negotiates Zlib compression, the server and client exchange messages with compressed payloads. Each compressed message includes header fields specifying the compressed and uncompressed data lengths. The vulnerability (CWE-130: Improper Handling of Length Parameter Inconsistency) occurs when the MongoDB server processes a maliciously crafted Zlib header containing mismatched length parameters. According to MongoDB's internal Jira ticket SERVER-115508, the issue involves "minimally sized buffers for uncompressed Messages." When the server allocates a buffer based on untrusted length values from the client, it can create a buffer that is too small or fails to properly initialize the memory space. ### The Attack Chain Here's how an attacker exploits MongoBleed step-by-step: 1. **Initial Connection**: The attacker establishes a network connection to the MongoDB server's port (default 27017) 2. **Compression Negotiation**: The attacker initiates or negotiates a Zlib compressed message exchange with the server 3. **Header Manipulation**: The attacker sends a specially crafted message with inconsistent length parameters in the Zlib protocol header: 4. **Buffer Misallocation**: The server processes the malformed header and allocates a buffer using the manipulated length parameters. Due to the inconsistency, the server either: 5. **Memory Leakage**: The server constructs a response to the client using this improperly sized or uninitialized buffer, inadvertently including whatever data was previously stored in that memory location 6. **Data Exfiltration**: The attacker receives the response containing raw heap memory contents, which may include: ### Technical Depth: The Zlib Implementation Flaw The MongoDB Jira issue title—"Make minimally sized buffers for uncompressed Messages"—provides insight into the fix. Prior to patching, the server likely allocated buffers based directly on client-provided length values without adequate validation or bounds checking. The fix enforces strict buffer sizing logic and ensures proper initialization of memory regions before use. Looking at the patch commits across MongoDB's GitHub repository, the fixes were applied to multiple branches between December 22-23, 2025: - **8.2.3**: Commit `029d8f99bf1e828b5327946b9c820bf493f466f1` - **8.0.17**: Commit `fe4a0b8cf49fd664128bcf668c046292c8e8eb80` - **7.0.28**: Commit `5393ef6c933e57093d11f704e611195301a967dd` - **6.0.27**: Commit `9e00200dcbf8b9c9f945a8b36bf7951db4f61e1c` - **5.0.32**: Commit `1264f9be5165abb0981f8023d2495652ab916699` - **4.4.30**: Commit `505b660a14698bd2b5233bd94da3917b585c5728` These commits implement proper validation of length field consistency and enforce minimum buffer sizes with guaranteed initialization, preventing the server from returning uninitialized memory to clients. ### Why No Authentication Required? This vulnerability is exploitable during the initial connection and compression negotiation phase, which occurs before MongoDB's authentication mechanisms engage. The Zlib compression layer operates at the network protocol level, processing message headers before the server validates client credentials. This makes MongoBleed particularly dangerous—attackers don't need valid credentials, making every internet-exposed MongoDB instance a potential target. --- ## Who Is Affected The scope of MongoBleed is staggering, affecting virtually every MongoDB Server version released in the past seven years: | | | | | | | --- | --- | --- | --- | --- | | | | | | | | | | | | | | | | | | | | | | | | | | MongoDB | MongoDB Server | 8.2.0 - 8.2.2 | 8.2.3 | Patch Available | | MongoDB | MongoDB Server | 8.0.0 - 8.0.16 | 8.0.17 | Patch Available | | MongoDB | MongoDB Server | 7.0.0 - 7.0.26 | 7.0.28 | Patch Available | | MongoDB | MongoDB Server | 6.0.0 - 6.0.26 | 6.0.27 | Patch Available | | MongoDB | MongoDB Server | 5.0.0 - 5.0.31 | 5.0.32 | Patch Available | | MongoDB | MongoDB Server | 4.4.0 - 4.4.29 | 4.4.30 | Patch Available | | MongoDB | MongoDB Server | All 4.2.x versions | None | End of Life - Workaround Required | | MongoDB | MongoDB Server | All 4.0.x versions | None | End of Life - Workaround Required | | MongoDB | MongoDB Server | All 3.6.x versions | None | End of Life - Workaround Required | ### Deployment Context MongoDB is one of the world's most popular NoSQL databases, used by enterprises across industries including: - **Financial Services**: Processing transaction data and customer information - **Healthcare**: Storing patient records and medical data - **E-commerce**: Managing product catalogs and customer orders - **Social Media**: Handling user profiles and content - **IoT and Analytics**: Aggregating sensor data and telemetry According to MongoDB Inc., millions of deployments run globally, from small startups to Fortune 500 enterprises. Any MongoDB instance with Zlib compression enabled (the default in many configurations) and exposed to untrusted networks is vulnerable. ### End-of-Life Version Crisis A particularly concerning aspect of this vulnerability is its impact on end-of-life (EOL) MongoDB versions. Versions 3.6, 4.0, and 4.2 are explicitly listed as affected but receive no official patches due to their EOL status. Organizations running these legacy versions must either: 1. Implement the configuration workaround (disabling Zlib) 2. Upgrade to a supported version (a major undertaking requiring testing and potential application changes) 3. Accept the risk of leaving systems vulnerable The presence of EOL versions in production environments is common in enterprises with complex technical debt, making this a particular challenge for security teams. --- ## Real-World Risk ### Confirmed Active Exploitation CISA's addition of CVE-2025-14847 to the Known Exploited Vulnerabilities (KEV) catalog on December 29, 2025, provides definitive evidence that attackers are actively exploiting this vulnerability in the wild. While CISA does not publicly disclose the specific incidents or threat actors involved, KEV listings are reserved for vulnerabilities with confirmed real-world exploitation. Under Binding Operational Directive 22-01, U.S. federal agencies must apply mitigations by **January 19, 2026**—a timeline that reflects the critical urgency of this threat. ### The Proof-of-Concept Security researcher Joe Desimone released a proof-of-concept exploit on GitHub at `https://github.com/joe-desimone/mongobleed`. This PoC demonstrates the practical exploitation of the vulnerability, showing how an attacker can: - Connect to a vulnerable MongoDB server - Send malformed Zlib headers with manipulated length parameters - Receive responses containing raw memory dumps - Parse the memory contents to extract sensitive information The availability of working exploit code dramatically lowers the barrier to entry for attackers. Script kiddies and automated scanning tools can now exploit MongoBleed without deep technical expertise. ### Attack Scenarios **Scenario 1: Credential Harvesting** An attacker scans the internet for MongoDB instances on port 27017, identifies vulnerable versions, and repeatedly exploits MongoBleed to extract memory contents. Over multiple requests, they collect fragments of uninitialized heap memory that may contain: - Database authentication credentials (usernames and passwords) - Application-level API keys stored in memory - Session tokens from other connected clients With these credentials, the attacker escalates from anonymous memory reading to full database access, potentially exfiltrating entire datasets or deploying ransomware. **Scenario 2: PII Data Breach** A healthcare organization runs MongoDB 7.0.15 to store patient records. An attacker exploits MongoBleed and extracts memory containing: - Patient names and social security numbers - Medical record numbers - Recent query results cached in RAM Even without authenticating to the database, the attacker obtains protected health information (PHI), triggering HIPAA breach notification requirements and potential regulatory penalties. **Scenario 3: Supply Chain Attack** A software-as-a-service (SaaS) provider uses MongoDB for multi-tenant data storage. An attacker exploits MongoBleed on the shared database server and extracts memory containing data from multiple customers. This cross-tenant information leakage compromises the security isolation of the entire platform. **Scenario 4: Reconnaissance for Ransomware** Ransomware operators use MongoBleed as a reconnaissance tool, extracting memory to map the internal network architecture, identify high-value data stores, and steal credentials for lateral movement—all before deploying encryption payloads. ### Data at Risk The heap memory of a MongoDB server can contain virtually any data the database processes: - **Credentials**: Database usernames, passwords, and authentication tokens - **Session Tokens**: Active user sessions and authorization tokens - **Query Results**: Recent database queries and their results, cached in memory - **Configuration Data**: Internal server settings, connection strings, encryption keys - **Personally Identifiable Information (PII)**: Customer names, addresses, social security numbers, email addresses - **Financial Data**: Credit card numbers, bank account details, transaction records - **Business Logic**: Application code, proprietary algorithms, trade secrets ### Impact Assessment: CVSS Scores MongoDB assigned CVE-2025-14847 the following CVSS scores: **CVSS v3.1**: **7.5 (HIGH)** - Vector: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` - Attack Vector: Network (exploitable remotely) - Attack Complexity: Low (no special conditions required) - Privileges Required: None (unauthenticated) - User Interaction: None (fully automated) - Confidentiality Impact: High (significant information disclosure) - Integrity Impact: None (no data modification) - Availability Impact: None (no denial of service) **CVSS v4.0**: **8.7 (HIGH)** - Vector: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` Both scoring systems classify this as a **HIGH severity** vulnerability with maximum confidentiality impact. The ease of exploitation (low complexity, no authentication) combined with confirmed active exploitation elevates this to critical priority for remediation. --- ## What You Should Do ### Immediate Actions (Within 24 Hours) **1. Inventory Your MongoDB Deployments** Identify all MongoDB instances in your environment: ```bash # Example: Scan your network for MongoDB instances nmap -p 27017 --open -sV # Check MongoDB version on a running instance mongosh --eval "db.version()" ``` Prioritize instances that are: - Exposed to the internet - Accessible from untrusted networks - Processing sensitive data - Running affected versions (3.6 through 8.2.2) **2. Apply Network-Level Protections** If you cannot immediately patch: - **Firewall Rules**: Restrict MongoDB port access (27017) to trusted IP addresses only - **VPN/Private Networks**: Move MongoDB instances behind VPNs or private network segments - **Cloud Security Groups**: Update security group rules to block public internet access ```bash # Example: UFW firewall rule to restrict MongoDB access sudo ufw deny 27017 sudo ufw allow from to any port 27017 ``` ### Short-Term Mitigation: Disable Zlib Compression If you cannot upgrade immediately, MongoDB provides a **fully effective workaround**: disable Zlib compression on your servers. **For mongod (Database Server):** Edit your MongoDB configuration file (`/etc/mongod.conf` or similar): ```yaml net: compression: compressors: snappy,zstd # Explicitly omit 'zlib' ``` Alternatively, start mongod with command-line options: ```bash mongod --networkMessageCompressors snappy,zstd # Or to disable all compression: mongod --networkMessageCompressors disabled ``` **For mongos (Sharding Router):** ```bash mongos --networkMessageCompressors snappy,zstd ``` **Side Effects of This Workaround:** - **Increased Network Bandwidth**: Without Zlib compression, network traffic between clients and servers will be larger - **Potential Performance Impact**: Compression reduces data transfer time; disabling it may slow query response times on high-latency networks - **Application Compatibility**: Ensure your client applications support Snappy or Zstd compression, or can operate without compression **Effectiveness**: This workaround is **fully effective**. Without Zlib enabled, the vulnerable code path is never executed, completely mitigating MongoBleed. ### Permanent Fix: Upgrade to Patched Versions MongoDB released patches for all supported versions on December 19-22, 2025. Upgrade to: | | | | | --- | --- | --- | | | | | | | | | | 8.2.0 - 8.2.2 | **8.2.3** | https://www.mongodb.com/try/download/community | | 8.0.0 - 8.0.16 | **8.0.17** | https://www.mongodb.com/try/download/community | | 7.0.0 - 7.0.26 | **7.0.28** | https://www.mongodb.com/try/download/community | | 6.0.0 - 6.0.26 | **6.0.27** | https://www.mongodb.com/try/download/community | | 5.0.0 - 5.0.31 | **5.0.32** | https://www.mongodb.com/try/download/community | | 4.4.0 - 4.4.29 | **4.4.30** | https://www.mongodb.com/try/download/community | | 4.2.x, 4.0.x, 3.6.x | **Workaround Required** | (EOL - No patch available) | **Upgrade Best Practices:** 1. **Test in Non-Production**: Deploy patches to development/staging environments first 2. **Backup First**: Always backup your databases before upgrading 3. **Review Release Notes**: Check for any breaking changes or compatibility issues 4. **Rolling Upgrades**: For replica sets and sharded clusters, upgrade secondaries first, then primaries 5. **Monitor Post-Upgrade**: Watch logs and performance metrics for unexpected behavior **Example Upgrade Process (Ubuntu/Debian):** ```bash # Backup your data mongodump --out /backup/mongodump-$(date +%Y%m%d) # Stop MongoDB sudo systemctl stop mongod # Update package list and upgrade sudo apt-get update sudo apt-get install -y mongodb-org=7.0.28 mongodb-org-database=7.0.28 \ mongodb-org-server=7.0.28 mongodb-org-mongos=7.0.28 \ mongodb-org-tools=7.0.28 # Start MongoDB sudo systemctl start mongod # Verify version mongosh --eval "db.version()" ``` ### Detection and Monitoring **Network-Level Detection:** Monitor for anomalous MongoDB traffic patterns: ```bash # Capture MongoDB traffic for analysis sudo tcpdump -i any -w mongodb_traffic.pcap port 27017 # Look for: # - High volume of connections from unknown IPs # - Connections that immediately terminate after receiving data # - Unusual Zlib compressed packet patterns ``` **Indicators of Compromise (IOCs):** - Unusually high volume of Zlib compressed traffic from external IPs - Connections that negotiate compression but send minimal queries - Response packet sizes that are disproportionately large relative to the request - Multiple rapid connection/disconnection cycles from the same source **Log Monitoring:** Enable MongoDB audit logging and watch for: ```javascript // Example: Enable auditing in MongoDB db.adminCommand({ auditConfig: 1, filter: { atype: "authenticate" } }) ``` Note: MongoBleed exploitation may be **silent** in MongoDB logs since the attack occurs at the network protocol layer before authentication. Network-level detection is more reliable. **SIEM Integration:** Create alerts for: - Failed authentication attempts followed by successful memory disclosure patterns - Unusual outbound data transfers from MongoDB servers - Connection attempts from known malicious IPs (check threat intelligence feeds) ### Post-Incident Response If you suspect your MongoDB instance was exploited: 1. **Isolate the System**: Disconnect the server from the network to prevent further data exfiltration 2. **Preserve Evidence**: Capture memory dumps and network traffic logs for forensic analysis ```bash # Capture memory dump (requires gcore or similar) sudo gcore $(pgrep mongod) ``` 1. **Rotate All Credentials**: Assume all credentials in memory were compromised: 2. **Review Access Logs**: Identify what data may have been accessed 3. **Notify Stakeholders**: If PII or regulated data was potentially exposed, follow your incident response and breach notification procedures 4. **Apply Patches**: Upgrade to fixed versions before restoring service ### Special Considerations for End-of-Life Versions If you're running MongoDB 3.6, 4.0, or 4.2: **Option 1: Apply Workaround (Short-Term)** - Disable Zlib compression immediately - This buys time but is not a long-term solution **Option 2: Upgrade (Recommended)** - Plan migration to MongoDB 4.4.30 or later - Test application compatibility thoroughly - Leverage MongoDB's upgrade guides for multi-version jumps **Option 3: Commercial Support** - Contact MongoDB Inc. about extended support options for EOL versions - Enterprise customers may have access to backported security fixes --- ## The Bigger Picture ### A Pattern of Memory Disclosure Vulnerabilities MongoBleed joins a troubling lineage of critical memory disclosure vulnerabilities in widely-deployed infrastructure software: - **Heartbleed (CVE-2014-0160, 2014)**: OpenSSL TLS heartbeat memory disclosure - **CloudBleed (2017)**: Cloudflare edge server memory leaks - **Spectre/Meltdown (2018)**: CPU-level speculative execution memory disclosure - **BleedingTooth (CVE-2020-12351, 2020)**: Linux Bluetooth memory disclosure - **MongoBleed (CVE-2025-14847, 2025)**: MongoDB Zlib compression memory disclosure These vulnerabilities share common characteristics: 1. **No Authentication Required**: Exploitable before security controls engage 2. **Memory Scraping**: Extract arbitrary memory contents through repeated exploitation 3. **Widespread Impact**: Affect millions of systems globally 4. **Easy Exploitation**: Low complexity, often with public PoC code 5. **Immediate Threat**: Quickly weaponized after disclosure ### Lessons for Database Security **Input Validation Remains Critical** MongoBleed underscores that input validation failures—even at the network protocol level—can have catastrophic consequences. Length fields, size parameters, and buffer allocations based on untrusted input must be rigorously validated. **Defense in Depth Still Matters** Organizations that followed security best practices (firewalling databases, network segmentation, principle of least privilege) significantly reduced their exposure to MongoBleed. No database server should ever be directly exposed to the public internet. **Patching Velocity is a Competitive Advantage** The four-day window between MongoDB's discovery and patch release demonstrates exceptional vendor response time. However, the immediate exploitation following public disclosure shows that attackers are faster. Organizations need automated patch management processes to deploy critical fixes within hours, not days or weeks. **End-of-Life is a Ticking Time Bomb** The presence of EOL MongoDB versions in production environments creates unfixable security risks. Technical debt in the form of outdated software versions is a strategic vulnerability that requires executive-level attention and resources to address. ### Broader Implications for NoSQL Databases While this vulnerability is specific to MongoDB's Zlib implementation, it raises questions about the security posture of other NoSQL databases. Security researchers will likely examine similar compression and network protocol handling in: - **Apache Cassandra**: Compression protocols and memory handling - **Redis**: RESP protocol and memory management - **Couchbase**: Network compression implementations - **Amazon DynamoDB**: While managed and presumably patched, third-party compatible implementations may be vulnerable Organizations using multiple database technologies should proactively audit their compression and network protocol implementations. ### The Automation of Exploitation The rapid weaponization of MongoBleed (public PoC released the same day as CISA KEV listing) reflects a broader trend: the industrialization of vulnerability exploitation. Threat actors increasingly use automated scanning tools to identify and exploit vulnerabilities within hours of public disclosure. This arms race between disclosure and exploitation places enormous pressure on defenders to: 1. Maintain comprehensive asset inventories 2. Automate vulnerability scanning 3. Implement emergency patching procedures 4. Deploy compensating controls (like the Zlib workaround) instantly ### Looking Forward: What to Watch **Ransomware Integration** MongoBleed is a textbook pre-ransomware reconnaissance tool. Watch for: - Ransomware groups incorporating MongoBleed into their toolchains - Double-extortion attacks where attackers exfiltrate data via MongoBleed before deploying encryption - Specific targeting of MongoDB instances as initial access vectors **Supply Chain Attacks** Managed service providers, cloud platforms, and SaaS vendors using MongoDB may be targeted: - Multi-tenant MongoDB deployments could see cross-customer data leakage - Supply chain compromises where attackers pivot from a vulnerable MongoDB instance to customer environments **Regulatory and Compliance Fallout** Organizations that fail to patch or mitigate may face: - GDPR violations for inadequate data protection (up to 4% of global revenue in fines) - HIPAA penalties for PHI breaches - PCI DSS compliance failures for cardholder data exposure - SOC 2 audit failures - Shareholder lawsuits for negligent security practices **Bug Bounty and Security Research** Expect increased scrutiny of database compression implementations: - Bug bounty hunters will examine similar code paths in other databases - Academic researchers may publish detailed analysis of MongoBleed's exploitation mechanics - Defensive security tools will add MongoBleed detection signatures ### The Bottom Line MongoBleed represents a critical threat to any organization using MongoDB Server. The combination of ease of exploitation, no authentication requirement, confirmed active exploitation, and widespread affected versions creates a perfect storm of risk. The path forward is clear: 1. **If you run MongoDB, act immediately**: patch or apply the Zlib workaround today 2. **If you can't patch immediately**: disable Zlib and isolate your MongoDB instances from untrusted networks 3. **If you're on EOL versions**: plan your upgrade now—technical debt has become a security crisis 4. **If you're a federal agency**: you have until January 19, 2026, to comply with CISA's directive This isn't a theoretical vulnerability or a low-probability threat. Attackers are exploiting MongoBleed right now. Every hour of delay increases the risk of data breach, regulatory penalties, and reputational damage. The Heartbleed era taught us that memory disclosure vulnerabilities are not just technical curiosities—they're existential threats to data security. MongoBleed is this decade's reminder that the lessons of Heartbleed remain painfully relevant. --- *This analysis is based on official MongoDB security advisories, CISA Known Exploited Vulnerabilities catalog entries, public security research, and CVE database records as of December 30, 2025.* ## Sources - [NVD - CVE-2025-14847](https://nvd.nist.gov/vuln/detail/CVE-2025-14847) - [MongoDB Security Advisory - SERVER-115508](https://jira.mongodb.org/browse/SERVER-115508) - [CISA Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-14847) - [Openwall OSS Security Mailing List - MongoBleed Disclosure](http://www.openwall.com/lists/oss-security/2025/12/29/21) - [MongoBleed Proof-of-Concept (GitHub)](https://github.com/joe-desimone/mongobleed) - [MongoDB 8.2.3 Patch Commit](https://github.com/mongodb/mongo/commit/029d8f99bf1e828b5327946b9c820bf493f466f1) - [MongoDB 8.0.17 Patch Commit](https://github.com/mongodb/mongo/commit/fe4a0b8cf49fd664128bcf668c046292c8e8eb80) - [MongoDB 7.0.28 Patch Commit](https://github.com/mongodb/mongo/commit/5393ef6c933e57093d11f704e611195301a967dd) - [MongoDB 6.0.27 Patch Commit](https://github.com/mongodb/mongo/commit/9e00200dcbf8b9c9f945a8b36bf7951db4f61e1c) - [MongoDB 5.0.32 Patch Commit](https://github.com/mongodb/mongo/commit/1264f9be5165abb0981f8023d2495652ab916699) - [MongoDB 4.4.30 Patch Commit](https://github.com/mongodb/mongo/commit/505b660a14698bd2b5233bd94da3917b585c5728) - [MongoDB Download Center](https://www.mongodb.com/try/download/community) Tags: CVE-2025-14847, MongoDB, MongoBleed, Information-Disclosure, Memory-Disclosure, Zlib, Database-Security, CISA-KEV, Critical-Vulnerability, Unauthenticated-Attack --- Source: [RadicalNotion.AI](https://radicalnotion.ai/blog/mongobleed-critical-unauthenticated-memory-disclosure-hits-mongodb-server-20251230154920). Licensed CC BY-NC 4.0; attribute RadicalNotion.AI and link the source page when you reuse this data.