Comparitech reports exposed MongoDB test database wiped in under three hours

What happened

Comparitech reports that it ran a 48-hour experiment. It exposed an unprotected MongoDB database holding 1,007 synthetic customer records to the internet. According to Comparitech, the database was wiped 2 hours and 54 minutes after first exposure Comparitech. This is one outlet’s research on its own test database. It is not an incident affecting a named vendor or customer, and the findings have not been independently verified.

Comparitech gives this account of the experiment:

• Timeline. The database went live at 11:16 UTC. The first logged connection attempt came at 13:02, and the MongoDB server log recorded the attack at 14:10:30 UTC.
• The wipe. A remote client deleted the database and left a ransom note demanding 0.0059 bitcoin (USD $473).
• The client. Connection metadata showed PyMongo 4.17.0 on a Linux host. Comparitech notes that this metadata can be spoofed.
• Repeat incidents. Comparitech says it saw five further wipe-and-ransom incidents, each from a different IP address. It says this suggests automation rather than a person acting in real time.
• Connection volume. Comparitech’s firewall recorded 260 incoming TCP SYN events from 88 distinct IP addresses. Logging was rate-limited to 10 entries per minute, so Comparitech says these are recorded events, not a complete count.
• Scanners. Some connecting addresses belonged to security research scanners such as The Shadowserver Foundation and Censys. Comparitech notes that these addresses also had 100% abuse confidence scores on AbuseIPDB.

Comparitech also reports a separate survey. In September 2026 it analyzed a sample of 6,945 hosts that Shodan identified as running MongoDB:

• 717 of those hosts (10%) lacked authentication.
• Just over 64% of the unauthenticated hosts (460 instances) contained ransom notes.

Comparitech links this to a 2020 campaign. It says automated scripts in that campaign wiped 22,900 unauthenticated MongoDB instances Comparitech.

Not confirmed:

• Who operates the wiping infrastructure.
• Whether anyone paid a ransom.
• Whether data was copied before deletion.

Am I affected?

According to Comparitech, the risk applies to MongoDB instances that meet both of these conditions Comparitech:

• The instance is reachable from the internet. Comparitech says scanners were likely looking for port 27017, the default MongoDB TCP port.
• The instance lacks authentication.

The test setup was MongoDB 8.0 listening on all IPv4 interfaces (bindIp: 0.0.0.0), with the port open to 0.0.0.0/0.

The source does not report any specific MongoDB version as vulnerable, and it names no CVE. The issue it describes is a configuration problem, not a software flaw.

What to do now

These steps are from Comparitech’s guidance Comparitech:

1. Enable authentication. Create an admin user, using passwordPrompt() so the password is not typed into the command. Set security.authorization: enabled in mongod.conf, then restart.
2. Limit exposure. Keep bindIp: 127.0.0.1 or a private interface unless remote access is essential. Restrict port 27017 in cloud security groups and host firewalls to known IPs.
3. Check containers. Comparitech notes that published Docker ports can bypass host firewall rules.
4. Add further layers. Use TLS, least-privilege users, tested offline backups, and alerts on unexpected connections.

Sources

• Comparitech: We exposed an unprotected database to the internet. It was wiped in 2 hours and 54 minutes