Updated 30 minutes ago
Port 27017 is MongoDB's front door. Every query, insert, and administrative command flows through this single TCP port. Thousands of organizations left that door wide open—no authentication, facing directly onto the public Internet. What happened next changed how the industry thinks about default configurations.
What Runs on Port 27017
MongoDB is a document database. Instead of rows and tables, it stores data as flexible JSON-like documents with schemas that can evolve without migrations. When MongoDB starts, it binds to port 27017 and waits for connections. Applications talk to it using a binary wire protocol optimized for speed. Your Node.js app, your Python script, the mongo shell—they all speak the same language to this port.
One port handles everything: reading documents, writing documents, creating indexes, running aggregations, administrative commands.
The Great MongoDB Ransom
Between late 2016 and early 2017, database administrators started arriving at work to find their MongoDB instances empty. In place of their data sat a single collection, usually named something like WARNING or PLEASE_READ. Inside: a ransom note demanding Bitcoin.
The attack pattern was simple: scan the Internet for open port 27017, connect without credentials, copy the data, delete everything, leave a ransom note. The whole thing could be scripted in an afternoon.
It worked because MongoDB's legacy default configuration was insane. The database bound to 0.0.0.0 (every network interface) and required no authentication. If you installed MongoDB and started it without reading the documentation, you were running a database that anyone on Earth could access with full administrative privileges.
Thousands of organizations did exactly this. Security researchers found over 28,000 exposed MongoDB instances within weeks1. The ransom demands were typically modest—0.2 to 1 Bitcoin—but many victims who paid discovered something worse than losing their money: the attackers had never backed up the data. They just deleted it and moved on to the next target.
Some databases held medical records. Others contained customer data, financial transactions, years of operational history. Gone.
Why Default Security Matters
MongoDB's maintainers fixed the defaults in version 3.62. The database now binds only to localhost (127.0.0.1) by default, and networked connections are denied unless explicitly configured by an administrator.
But the lesson extends far beyond MongoDB.
The ransom attacks succeeded because of a gap between how software ships and how it should run in production. MongoDB's original defaults prioritized developer convenience—you could install it, start it, and immediately begin storing data. No configuration required. That convenience became a liability the moment the database touched a public network.
Every database port is a door. The question is always: who should be able to open it?
Securing Port 27017
Bind to localhost unless you have a reason not to. If your application runs on the same server as MongoDB, configure the database to listen only on 127.0.0.1. No external connections possible. Problem solved at the network layer.
When remote access is necessary, use firewalls. Whitelist specific IP addresses. Never allow 0.0.0.0/0 (the entire Internet) to reach your database port. Layer your defenses: operating system firewall, cloud security groups, network ACLs. Assume any single layer might fail.
Enable authentication. Always. Create users with the minimum privileges they need. Your application shouldn't connect as admin. Reserve administrative credentials for actual administration, accessed only from trusted locations.
Encrypt the connection. TLS protects data in transit. This matters especially in cloud environments where your packets traverse shared infrastructure. The performance overhead is minimal; the protection against eavesdropping is substantial.
Additional Ports in Distributed Deployments
MongoDB's high-availability features introduce more ports to secure:
- 27018: Shard servers in a sharded cluster
- 27019: Config servers that store cluster metadata
- Replica set members: Communicate over their configured ports (usually 27017) to synchronize data and elect primaries
Each component needs firewall rules that allow internal cluster communication while blocking everything else. Use keyfile authentication or x.509 certificates to ensure only authorized MongoDB instances can join your cluster.
Cloud-Hosted MongoDB
Managed services like MongoDB Atlas, AWS DocumentDB, and Azure Cosmos DB handle much of this automatically. They run inside private networks with no direct Internet exposure. You connect through VPC peering or IP whitelisting.
The tradeoff: you lose some control but gain security defaults that assume the Internet is hostile. For many teams, that's the right choice.
The Broader Lesson
Port 27017 is just a number. The story behind it—tens of thousands of databases wiped because convenience defaults met the open Internet—applies to every service you expose.
Attackers scan continuously. Bots probe every IP address, every port, every protocol. If you leave a door unlocked, someone will open it. Usually within hours.
The MongoDB ransom attacks didn't exploit a vulnerability. They exploited a configuration choice. The database was working exactly as designed. It just wasn't designed for the environment it was deployed in.
Every port you open is a decision. Make it deliberately.
Frequently Asked Questions About MongoDB Port 27017
Sources
Sources
Was this page helpful?