208,000 MongoDB Servers Exposed, 1,400 Already Hit by Extortion

A single threat actor has compromised approximately 1,400 MongoDB instances in automated data extortion attacks, wiping databases and demanding Bitcoin ransoms from server owners. Research from cybersecurity firm Flare reveals that over 208,500 MongoDB servers remain publicly exposed, with 3,100 accessible without any authentication—making them trivial targets for opportunistic attackers.

The Attack Pattern

The attacker isn't exploiting software vulnerabilities. They're targeting misconfigured databases left open to the internet without authentication—low-hanging fruit that requires no technical sophistication to compromise.

The approach is straightforward: automated scripts scan for internet-facing MongoDB instances, connect to those lacking authentication, copy the data, wipe the database, and leave behind a ransom note demanding approximately 0.005 BTC (around $500-600 USD). Victims receive a 48-hour deadline.

Flare's analysis found only five distinct Bitcoin wallet addresses across all the ransom notes. One wallet appeared in 98% of cases, indicating a single actor behind almost all the attacks. The concentrated targeting suggests an organized campaign rather than multiple opportunistic attackers.

No Guarantee of Recovery

The ransom notes promise data restoration upon payment. There's no evidence the attackers actually retain the stolen data or have any intention of returning it. Paying the ransom likely buys nothing except funding further attacks.

This pattern mirrors database ransom campaigns that peaked in 2021, when thousands of MongoDB, Elasticsearch, and MySQL databases were wiped in similar attacks. Some attackers during that wave deleted data without even bothering to demand payment—pure destruction.

Scale of Exposure

Flare's researchers discovered the scope of the problem during a penetration testing exercise:

• 208,500+ publicly exposed MongoDB servers identified
• 100,000 expose operational information to anyone who connects
• 3,100 allow full access without any authentication
• ~1,400 already compromised with ransom notes

Nearly half (45.6%) of the unauthenticated instances showed signs of prior compromise. The attackers aren't the first to find these databases—they're just the latest.

Separately, around 95,000 exposed MongoDB servers run outdated versions vulnerable to known security flaws. However, most CVEs affecting MongoDB enable denial-of-service attacks rather than remote code execution, limiting their usefulness for data theft.

Connection to MongoBleed

These extortion attacks are distinct from the recent MongoBleed vulnerability (CVE-2025-14847) that CISA added to its Known Exploited Vulnerabilities catalog in December. MongoBleed allows attackers to read sensitive data from MongoDB server memory through a pre-authentication flaw—a more sophisticated attack vector.

The current extortion campaign targets a simpler problem: databases with no authentication at all. The fix isn't a patch; it's configuration.

Why Databases Stay Exposed

MongoDB's default configuration has required authentication since version 3.6 (released in 2017). The continued existence of unauthenticated instances reflects a few recurring problems:

Copy-pasted configurations: Developers copy deployment guides and tutorials without understanding the security implications. Guides optimized for quick local development may disable authentication for convenience.

Development instances gone wild: Databases spun up for testing or development get exposed accidentally and forgotten. Without asset inventories, organizations don't know these instances exist.

Cloud misconfigurations: Security group rules and network policies may expose database ports to broader ranges than intended. A permissive firewall rule during troubleshooting becomes permanent.

Shadow IT: Departments deploy databases without involving security or operations teams. These instances never receive hardening or monitoring.

Protection Measures

Flare recommends immediate steps for MongoDB administrators:

1. Audit exposure: Scan for all MongoDB instances in your environment, including development and staging servers. Check whether they're accessible from the internet.

2. Enable authentication: Any instance that somehow lacks authentication needs it enabled immediately. There's no legitimate reason for production databases to accept unauthenticated connections.

3. Restrict network access: MongoDB ports (default 27017) should only accept connections from application servers, not the entire internet. Implement firewall rules, security groups, or Kubernetes network policies accordingly.

4. Update to current versions: While this campaign targets misconfiguration rather than vulnerabilities, running supported versions ensures you receive security patches when needed.

5. Rotate credentials on compromised instances: If an attacker accessed your database, assume they copied everything. Rotate any credentials stored in that database and check logs for unauthorized activity.

The Pattern Continues

Database ransom attacks have persisted for years because exposed databases persist for years. The attacks require minimal effort—automated scanning finds targets, automated scripts do the work. Low ransoms mean even a small percentage of payments generates income.

Organizations that configured databases securely never become targets. The 1,400 compromised instances represent the predictable result of skipping authentication on internet-facing databases.

The attackers will keep scanning. The only question is whether more databases will be waiting when they do.