MongoDB exposed to the internet

An unauthenticated MongoDB reachable from an untrusted network is not a brute-force target. There is nothing to brute force. Authentication is off by default, so an attacker connects and is, immediately, an administrator: every collection readable, every database droppable.

This is the only service on this site where the exposed state requires no attack at all. It is why MongoDB is the database that got ransomed at scale.

What actually happened, and why it matters now

Starting in late 2016 and running through 2017, tens of thousands of internet-facing MongoDB instances were found by automated scanning, had their databases copied or simply dropped, and were left with a single collection containing a ransom demand. No exploit was involved. The tooling connected, ran dropDatabase, and inserted a note.

The preconditions were MongoDB’s defaults at the time: no authentication, and a bindIp default of every interface. MongoDB 3.6 changed the binding default to loopback, which is why the wave subsided — but the authentication default never changed. It is still off.

So the modern version of this is one step away: any change that widens the bind — a container’s published port, bindIpAll added to fix a connection error, a security group with an over-broad rule — restores the 2017 conditions exactly, because the second layer was never there.

How it differs from the others

Worth being precise, because the reaction should differ too.

An open Redis or MySQL is a path to running code on the host — Redis via CONFIG SET dir and a file write, MySQL via FILE and UDFs. MongoDB has no equivalent. Its server-side JavaScript runs in a sandboxed interpreter with no filesystem or shell access, and there is no mechanism to make mongod write an arbitrary file to an arbitrary path.

So an open MongoDB is usually not a host compromise. It is a total data compromise: every document read, and every document destroyable, in one connection. For most people that is the worse of the two.

Don’t let that be reassuring. “They only got all the data” is not a good outcome, and the ransom crews did not need a shell to end companies.

The shortest path from exposed to closed

1. Enable authorization — the layer that should have been there. Read the page first; the order of operations is the whole trick.
2. Bind to a private interface — and check the container’s published port, not just the config.
3. Firewall 27017.
4. Fix the roles — so a leaked credential isn’t root.

Steps 2 and 3 take minutes and stop the bleeding. Step 1 is the one that means it can’t happen again.

Verify it worked

Is it reachable and open? From another host — not the server:

mongosh --host your.db --serverSelectionTimeoutMS 5000 --quiet \
  --eval 'db.adminCommand({listDatabases: 1})'

A timeout means the port is closed to you — good. requires authentication means it’s reachable but authorized — fix the binding.

A list of your databases means it is wide open right now. Stop reading and firewall the port.

Were you hit? The ransom pattern is distinctive — an unexpected database or collection, and your data gone:

db.adminCommand({ listDatabases: 1 })

Look for names you didn’t create: READ__ME_TO_RECOVER_YOUR_DATA, READ_ME_TO_RECOVER, PLEASE_READ, Warning, or similar. Then:

use admin
db.getUsers()

Users you didn’t create mean someone locked you out, which is the more sophisticated version — they enable auth with their own admin account.

Check for the note itself:

db.getSiblingDB('READ__ME_TO_RECOVER_YOUR_DATA').getCollectionNames()

And look at when things last changed:

sudo ls -lat /var/lib/mongodb | head
sudo grep -iE 'dropDatabase|createUser|authenticate' /var/log/mongodb/mongod.log | tail -30

Without audit logging — which Community doesn’t have — mongod.log is all you get, and at default verbosity it may not record much. That gap is exactly why the page exists.

Before you apply this

Do not pay the ransom. Analysis of the 2017 wave found that in a large share of cases the data was never copied at all — the tooling dropped the databases and demanded payment for data it did not hold. Paying funds the next round and recovers nothing.

Restore from backup, and treat the entire dataset as disclosed regardless of whether it was destroyed. You cannot distinguish “read then dropped” from “dropped” after the fact.

Response, in order:

1. Firewall the port first. Do not restart mongod — a restart clears currentOp and loses the connection state that might tell you who’s still attached.
2. Check listDatabases and getUsers for what’s been added, and note it before you change anything.
3. Rotate everything the data contained — application user password hashes, session tokens, API keys. Your users are affected even if your infrastructure is intact.
4. Restore from a backup taken before the earliest evidence of access, then enable authorization before putting it back on any network.

The host itself is probably fine — that’s the one mercy of MongoDB’s sandboxed JS. Rebuild the data from backup and rebuild the config properly; a full host rebuild is usually not required unless something else on the box was reachable.

If you have no backup from before the incident, the data is gone. That is the lesson of 2017, and it is why the two-minute version of this page is: enable authorization.

Related

• Hardening MongoDB — the full checklist.
• Enable authorization — the control that makes this impossible.