My MongoDB database got exposed without authentication. What should I do?
MongoDB is the classic open-database story: for years instances shipped listening on all interfaces with no authentication, and automated gangs have wiped tens of thousands of them — copying the data and leaving a ransom note in its place. If yours was reachable, act fast and assume the data is gone unless your backups say otherwise.
First: don’t panic — close the port, then check your backups.
The damage with MongoDB is usually done by a bot, not a person: dropped databases and a ransom note. Closing the port stops further harm; your recovery depends entirely on backups, not on paying. Don’t wipe the note until you’ve documented it.
// the 60-second version
- Firewall port 27017 immediately and bind Mongo to localhost.
- Enable authentication and create a proper admin user.
- Look for dropped databases and a
README/RECOVERransom collection. - Restore from a clean backup — never pay; the data was taken, not held.
01Understand what’s at risk
An open MongoDB with authentication off lets anyone connect and run any command. That means:
- Full data access — read every collection: users, sessions, PII, business data.
- Destruction —
dropDatabase()wipes everything in seconds. - Ransom — automated campaigns exfiltrate, drop your databases, and insert a collection (often
README,RECOVERor similar) demanding Bitcoin. - Secrets in the data — tokens, keys and hashes stored in documents are now out.
MongoDB is one of the most-targeted databases for these ransom sweeps, and several gangs may hit the same instance. Some leave a note without ever copying the data — so paying typically returns nothing. Assume the worst about confidentiality, and rely on backups for recovery.
02Stop the bleeding — take it off the internet
ufw deny 27017
net: bindIp: 127.0.0.1 # localhost only port: 27017
Restart with systemctl restart mongod. If a remote app needs it, restrict to that app’s IP and use a private network/VPN or TLS — never the open internet.
03Enable authentication
The root cause is almost always disabled auth. Connect locally, create an admin user, then require authorization:
use admin
db.createUser({
user: "admin",
pwd: "<strong-secret>",
roles: [ { role: "root", db: "admin" } ]
})
security: authorization: enabled
- Create least-privilege users per application/database — don’t let apps use the root account.
- Rotate any credentials or secrets that were stored in documents.
04Read the logs — what happened?
Check the MongoDB log for connections and destructive commands around the exposure window:
grep -iE "authenticated|dropDatabase|connection accepted" /var/log/mongodb/mongod.log
- Connections from unknown IPs — assume the data was copied.
dropDatabase/ mass deletes pinpoint when you were hit.- A database/collection you didn’t create (the ransom note) confirms a ransom sweep.
05Recover from backups — don’t pay
- Restore from a known-good backup to a freshly secured instance.
- Document the ransom note (screenshot, export) before removing it.
- Paying is strongly discouraged: in these automated sweeps the data is frequently never retained, so there’s nothing to return.
If documents held personal data, this is likely a reportable breach (GDPR and similar). Involve legal/compliance.
06Make sure it can’t happen again
- Bind to localhost/private networks and reach Mongo via VPN or SSH tunnel.
- Always run with authorization enabled — never expose an auth-less instance.
- Per-app, least-privilege users instead of a shared root.
- Tested backups are your ransomware insurance.
- Monitor connections and alert on dropped databases; keep Mongo patched.
Was this guide useful?
These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.