Is port 27017 (MongoDB) exposed to the internet without authentication?

Why MongoDB used to be reachable by default

IANA registers port 27017 for MongoDB. MongoDB’s own IP binding documentation confirms that from version 3.6 onward, the mongod and mongos binaries bind to localhost only out of the box — but that fix came after years of the opposite default. Earlier versions bound to all network interfaces with no authentication required, so a database brought online with no extra configuration beyond the defaults was immediately reachable, and immediately both readable and writable, from any network that could route to it.

What happened when that default met the internet at scale

Krebs on Security’s contemporaneous reporting documented what followed: starting in late December 2016 and escalating through January 2017, researchers including Victor Gevers of the GDI Foundation tracked a wave of automated attacks against internet-reachable, unauthenticated MongoDB instances. Attackers simply connected with no credentials, copied or deleted the data, and replaced it with a ransom note demanding Bitcoin. The count of compromised databases grew from roughly 200 to over 27,000 within about two weeks, driven by at least fifteen separate, uncoordinated attacker groups independently finding and re-ransoming the same exposed instances — meaning a given database could be wiped by multiple attackers before anyone in the organization noticed. A second wave hit again in September 2017. In both cases, most victims who paid the ransom never recovered their data, because many of the attackers had never kept a usable copy to begin with.

Why this still matters years later

The specific insecure default is fixed as of MongoDB 3.6, but the underlying mistake — binding a database to a public interface without enabling authentication — is still something an administrator can do manually, and cloud environments make it easy to stand up a new instance quickly without revisiting every setting. Automated internet-wide scanning means a newly exposed, unauthenticated MongoDB instance is typically found within minutes of going online, not months.

How to check your own exposure

AdminKit’s planned open ports check is designed to test whether port 27017 and other commonly-exposed database ports on your own public IP respond from outside your network — useful confirmation that a bind-address change or firewall rule actually took effect rather than assuming it did.

How to fix it

• Enable authentication using MongoDB’s SCRAM, x.509 certificate, or another supported mechanism — this alone defeats the no-credential attack pattern described above.
• Confirm net.bindIp is set to a private or loopback address, not 0.0.0.0 or an unrestricted range, consistent with MongoDB’s own post-3.6 default.
• Add a firewall rule restricting port 27017 to only the application servers that need it, rather than relying on the database’s own access controls alone.
• Review MongoDB’s own Security Checklist for Self-Managed Deployments for the full set of hardening steps beyond authentication and binding.

Defensive use only

Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.