Exposed MongoDB instances continue to be actively targeted in automated data extortion campaigns, with attackers demanding relatively small Bitcoin ransoms in exchange for alleged data restoration. Despite years of warnings and prior large-scale incidents, misconfigured databases remain a persistent and lucrative target.
Ongoing data extortion against misconfigured MongoDB servers
Threat actors are systematically scanning the internet for MongoDB deployments that are accessible without authentication. These “low-hanging fruit” systems are typically exposed due to insecure default configurations or improperly applied access controls. Once identified, attackers wipe the databases and leave ransom notes demanding approximately $500 worth of Bitcoin to restore the data.
Recent activity indicates that around 1,400 exposed MongoDB servers have already been compromised in this wave, with ransom demands commonly set at roughly 0.005 BTC. This tactic mirrors earlier campaigns observed before 2021, when attackers deleted thousands of databases and demanded payment—sometimes even without offering data recovery.
Findings from large-scale exposure analysis
A penetration testing exercise conducted by researchers at Flare shows that while the scale of attacks has decreased compared to previous years, the threat has not disappeared. Flare identified more than 208,500 publicly exposed MongoDB servers during their assessment.
Of these, approximately 100,000 instances leaked operational metadata, and around 3,100 were directly accessible without any authentication. Alarmingly, nearly half—45.6%—of the unrestricted instances had already been compromised at the time of analysis. These databases had been wiped clean and replaced with ransom notes.
Ransom demands and attacker attribution
Analysis of the ransom notes revealed a consistent pattern. Most victims were instructed to pay 0.005 BTC within 48 hours to a specified wallet address. At current exchange rates, this equates to roughly $500–600 USD.
Flare noted that there is no assurance attackers actually retain a copy of the data or will provide functional recovery tools after payment. This uncertainty significantly undermines the value of paying the ransom and increases the likelihood of permanent data loss.
Interestingly, only five unique Bitcoin wallet addresses were identified across all observed ransom notes. One wallet appeared in approximately 98% of cases, strongly suggesting that a single threat actor or tightly coordinated group is responsible for the majority of these attacks.
Exposed but untouched systems raise further concerns
Flare researchers also observed a number of poorly secured MongoDB instances that had not yet been wiped, despite being publicly accessible. One hypothesis is that some of these organizations may have already paid ransoms in earlier incidents, temporarily deterring further attacks.
Beyond authentication failures, the study found that nearly 95,000 exposed MongoDB servers were running outdated versions susceptible to known n-day vulnerabilities. While most of these flaws are limited to denial-of-service conditions rather than remote code execution, they still contribute to overall risk and instability.
Security best practices for MongoDB administrators
From a defensive standpoint, these findings reinforce long-standing best practices for database security. MongoDB instances should never be exposed directly to the public internet unless absolutely required. Strong authentication mechanisms must be enforced, and access should be restricted using firewalls, security groups, and Kubernetes network policies that allow only trusted sources.
Administrators are also advised to avoid blindly copying configurations from deployment guides without understanding their security implications. Keeping MongoDB deployments fully up to date, continuously monitoring for unintended exposure, and regularly auditing access logs are essential measures.
In cases where exposure is detected, credentials should be rotated immediately, and logs should be reviewed for signs of unauthorized access or data manipulation. These steps remain critical to reducing the risk of data extortion and protecting sensitive information in modern database environments.