MongoDB instances exposed directly to the internet are once again being hit by automated ransomware campaigns. Attackers are systematically scanning the internet for misconfigured servers, erasing the data they contain and leaving ransom notes that promise “recovery” of the deleted databases in exchange for cryptocurrency.
Mass ransomware attacks on exposed MongoDB databases
According to recent research by Flare, more than 208,500 publicly accessible MongoDB servers were identified during a scan of internet-facing infrastructure. A significant portion of these instances are configured insecurely: over 100,000 MongoDB servers leak operational data such as cluster status and configuration, and roughly 3,100 instances allow access with no authentication at all.
The impact is substantial. Flare reports that 45.6% of MongoDB instances with unrestricted access had already been compromised at the time of analysis. Legitimate databases on these servers had been removed and replaced with collections containing ransom notes. In total, researchers observed about 1,400 active victims of these MongoDB ransomware attacks.
How automated MongoDB ransomware attacks work
The attack chain is highly automated and technically simple. Scripts continuously scan the internet for open MongoDB ports (by default, 27017 and 27018). When an accessible server is found that does not enforce authentication, the attacker connects with default privileges, drops existing databases and then creates a new database or collection containing a ransom message.
Flare’s analysis shows that most notes demand payment of 0.005 BTC (approximately USD 500–600 at the time of the study) within 48 hours. Payments are requested to one of five Bitcoin wallet addresses, with a single address appearing in about 98% of all ransom notes. This pattern strongly suggests that these campaigns are operated by one actor or a tightly coordinated group.
In many cases, there is no actual encryption and no evidence that attackers exfiltrate the data. The attack is essentially a destructive wipe followed by an extortion attempt that relies on victims’ lack of backups and desperation to recover lost information.
MongoDB ransomware: a new wave of an old security problem
Ransomware and destructive attacks on open MongoDB databases are not new. Before 2021, numerous large-scale incidents were documented in which thousands of unsecured MongoDB instances were wiped or hijacked. In some campaigns, attackers did not even bother demanding a ransom: data was simply destroyed, leading to permanent loss for organizations without reliable backups.
Flare notes that today’s MongoDB attacks appear to be somewhat smaller in scale than the earlier waves, but they continue to affect organizations worldwide. An interesting anomaly is that some insecure, internet-exposed instances have not been compromised, even though they are technically vulnerable. One hypothesis is that administrators of those systems may already have paid the ransom, after which attackers avoided re-targeting the same servers to reduce the risk of attracting attention.
Misconfigured and outdated MongoDB servers increase attack surface
The primary enabler of these incidents is incorrect MongoDB configuration. Instances are often deployed quickly for testing, proof-of-concept work or internal projects and later moved into production without tightening security. As a result, many servers continue to:
- listen on 0.0.0.0, making them reachable from the public internet,
- run without mandatory authentication,
- use weak, default or shared credentials for administrative access.
Flare’s research also highlights the problem of outdated software: nearly 95,000 internet-exposed MongoDB servers run legacy versions with publicly documented vulnerabilities. While many of these issues are classified as denial-of-service (DoS) flaws, they can often be chained with misconfigurations to aid in lateral movement, privilege escalation or broader system compromise.
Why paying the MongoDB ransom rarely restores data
Although ransom notes frequently promise to “restore” or “decrypt” data after payment, there is no technical guarantee that attackers possess any copy of the erased databases. Historically, many MongoDB extortion campaigns have simply deleted data without encryption and without preserving backups. Even if attackers wanted to honor their promises, in such cases they would be unable to do so.
Regulators and cybersecurity authorities such as FBI, CISA and ENISA consistently advise against paying ransoms. Payment does not ensure data recovery, may encourage further criminal activity and in some jurisdictions can raise legal and sanctions-related concerns. A strategy based on prevention and robust backup procedures is far more reliable than negotiation with extortionists.
MongoDB security best practices to prevent ransomware and data loss
Organizations using MongoDB should implement layered protections to minimize the risk of compromise and data destruction. Key measures include:
1. Restrict network exposure of MongoDB.
MongoDB should not be directly reachable from the public internet unless absolutely necessary. Administrators should:
- bind MongoDB to internal interfaces only via bind_ip,
- allow access exclusively from trusted IP ranges using firewalls or security groups,
- route administrative access through VPNs or hardened bastion hosts.
2. Enforce authentication and strong access control.
Always enable MongoDB authentication, use role-based access control and assign the minimum privileges needed for each account. Disable guest access, avoid shared admin accounts and use strong, unique passwords or centralized identity providers. Enable TLS to protect credentials and data in transit.
3. Secure Kubernetes and cloud deployments.
When running MongoDB in Kubernetes or public cloud environments, configure network policies, security groups and private subnets so that only required services and networks can reach the database. Avoid copying example configurations from public guides without adapting them to your own threat model and compliance requirements.
4. Keep MongoDB updated and manage vulnerabilities.
Regularly upgrade MongoDB and related components to supported versions and apply security patches in a timely manner. Use vulnerability scanners and attack-surface management tools to detect exposed services and outdated software, and integrate remediation into your normal operations workflow.
5. Implement reliable, isolated backups and test restores.
Well-designed backup and recovery processes are the only dependable way to restore data after ransomware, accidental deletion or infrastructure failure. Maintain offline or logically isolated backups that attackers cannot easily modify or delete, and routinely test restoration procedures to ensure they work under real conditions.
Automated attacks against unsecured MongoDB instances demonstrate how a single configuration mistake can result in the complete loss of critical data. Organizations should promptly inventory all MongoDB servers, identify which are accessible from the internet, verify that authentication is enforced and confirm that robust backup strategies are in place. Closing unnecessary ports, hardening configurations and keeping systems up to date significantly reduces the likelihood that the next ransom note will appear in your MongoDB collections.
