MongoDB: The Database That Ships Without a Lock

No authentication, all interfaces

MongoDB's default configuration before version 6.0 did not enable authentication and bound to all network interfaces (0.0.0.0). Starting a fresh MongoDB instance and exposing port 27017 to the network gave anyone full read and write access to every database. No username, no password, no connection string tricks. Just connect and you are in.

MongoDB 6.0 and later versions improved the defaults by only binding to localhost, but millions of older instances remain in production. Cloud deployments where the bind address was explicitly set to 0.0.0.0 for application access continue to be exposed. As of early 2026, Shodan indexes over 48,000 MongoDB instances directly accessible on the internet without authentication.

The enumeration chain

Once connected to an unauthenticated MongoDB instance, the full database contents are available in four commands:

// Step 1: List all databases
show dbs

// Step 2: Select a database
use production

// Step 3: List all collections
show collections

// Step 4: Dump a collection
db.users.find().limit(100).pretty()

That is the entire process. No exploitation, no vulnerability, no bypass. The database simply has no access controls.

What we find in exposed instances

MongoDB is the most popular NoSQL database, used heavily in web applications, mobile backends, and IoT platforms. Exposed instances typically contain:

• User accounts with email addresses, hashed passwords (often MD5 or SHA-1 without salt), phone numbers, and physical addresses
• Payment records including partial credit card numbers, transaction histories, and billing addresses
• Healthcare data including patient records, appointment histories, and insurance information
• Application session data with active authentication tokens
• IoT telemetry including GPS coordinates, device identifiers, and usage patterns

In one authorized engagement, we found a MongoDB instance backing a healthcare scheduling application. It contained 2.3 million patient records with full names, dates of birth, Social Security numbers, and medical history. The instance had been exposed for over 14 months.

serverStatus reveals the infrastructure

The db.serverStatus() command returns detailed information about the MongoDB server and its host operating system:

db.serverStatus()
// Returns: hostname, OS type and version, kernel version,
// CPU architecture, memory (total and available),
// storage engine details, connection counts,
// network bytes in/out, uptime

This information is valuable for further exploitation. The OS version reveals potential kernel vulnerabilities. The hostname often indicates the cloud provider and deployment pattern. The memory and CPU details help estimate the value of the target.

From database access to server compromise

MongoDB supports server-side JavaScript execution through the $where operator and the db.eval() function (deprecated but still available on older versions). On instances where these features are enabled, you can execute arbitrary JavaScript on the server.

More practically, MongoDB's mongodump utility can export the entire database remotely:

mongodump --host target.com --port 27017 --out ./full_dump/

This creates a complete local copy of every database, every collection, and every document on the target instance. Depending on the data size, this can take minutes to hours, but there is nothing on the server side to prevent or detect it.

Ransom attacks on exposed instances

Starting in 2017, automated bots began scanning the internet for unauthenticated MongoDB instances, deleting all data, and leaving a ransom note demanding Bitcoin payment. These attacks continue in 2026. The bot connects, drops all collections, and inserts a single document:

{
  "readme": "Your database has been backed up. To recover your data, send 0.05 BTC to [address]. Contact recover_mongodb@protonmail.com"
}

In most cases, the attackers did not actually back up the data. They simply deleted it. Victims who paid received nothing. By 2025, an estimated 75,000 MongoDB instances had been hit by these automated ransom campaigns.

The CONFIG SET parallel

Similar to the Redis CONFIG SET attack for writing files to disk, MongoDB's older versions supported db.adminCommand({setParameter: 1, ...}) calls that could modify server behavior at runtime. While MongoDB does not have a direct file-write primitive like Redis, writable access to the database can be leveraged to modify application behavior if the application reads configuration from MongoDB (a common pattern in Node.js applications using MongoDB as a config store).

Defense

• Enable authentication: add security.authorization: enabled to mongod.conf
• Bind to localhost: set net.bindIp: 127.0.0.1 unless remote access is specifically required
• Create specific database users with the minimum required roles for each application
• Enable TLS for all client connections
• Use MongoDB Atlas (the managed service) which enforces authentication and network access controls by default
• Block port 27017 at the firewall level from all sources except known application servers
• Enable audit logging to track database access and detect unauthorized connections
• Regularly scan your own infrastructure for unauthenticated MongoDB instances using nmap -p 27017 --script mongodb-info