MongoDB Running Without Authentication
What Is This Vulnerability?
A MongoDB instance running without authentication allows anyone who can reach the network port to read, modify, or delete all data in every database. Thousands of MongoDB instances are exposed on the internet without authentication, and automated bots continuously scan for them to steal or ransom the data they contain.
Why It Happens
MongoDB ships with authentication disabled by default in many installation methods. Developers spin up instances for local development without auth and deploy them the same way. Docker images of MongoDB start without authentication unless explicitly configured. Cloud deployments sometimes expose the default port (27017) to the public internet through misconfigured security groups.
Example Code
version: "3.8"
services:
mongodb:
image: mongo:7
ports:
- "27017:27017"
volumes:
- mongo_data:/data/db
volumes:
mongo_data:version: "3.8"
services:
mongodb:
image: mongo:7
ports:
- "127.0.0.1:27017:27017"
environment:
MONGO_INITDB_ROOT_USERNAME: ${MONGO_USER}
MONGO_INITDB_ROOT_PASSWORD: ${MONGO_PASSWORD}
volumes:
- mongo_data:/data/db
command: ["mongod", "--auth", "--bind_ip", "127.0.0.1"]
volumes:
mongo_data:How Hackers Exploit It
Automated bots scan the entire internet for open port 27017. When they find an unauthenticated MongoDB instance, they dump all databases, delete the data, and leave a ransom note demanding Bitcoin payment for its return. Attackers also use exposed MongoDB instances to harvest user credentials, personal data, and intellectual property for sale on dark web marketplaces.
How to Fix It
Enable authentication by starting MongoDB with the --auth flag and creating admin users. Bind MongoDB to localhost or a private network interface rather than 0.0.0.0. Use firewall rules and security groups to restrict access to the MongoDB port. Enable TLS for connections. Use SCRAM-SHA-256 authentication and create dedicated database users with minimal privileges for each application.