Port 27017 – MongoDB (mongod NoSQL Database Wire Protocol)

Port 27017 is the default port for MongoDB, the document-oriented NoSQL database. The mongod server process listens here and speaks the binary MongoDB wire protocol — the same protocol used by the mongosh/mongo shells and by every application driver. The marquee risk on this port is brutally simple: for years MongoDB shipped listening on all interfaces with no authentication enabled by default, so an exposed port 27017 frequently means anyone who can reach it gets full read/write access to every database — no credentials, no exploit, just mongosh mongodb://<target>:27017 and show dbs. That single default caused one of the largest data-exposure events on the internet, and open, unauthenticated MongoDB instances are still found in the tens of thousands. Related ports in the same deployment: 27018 for shard members and replica-set nodes, 27019 for config servers, the mongos query router (also 27017), and the long-removed legacy HTTP status page on 28017.

Why It’s Open

MongoDB is fast to deploy and forgiving to developers, which is exactly why it ends up exposed. A mongod process binds 27017 the moment it starts, and application servers, ORMs/ODMs, and admin tooling all connect to it over the wire protocol. In a properly built deployment that traffic stays on a private network or loopback; in practice, cloud VMs, Docker containers, and Kubernetes services routinely publish 27017 to the world because a docker run -p 27017:27017 or an over-broad security group is easier than wiring up a private subnet.

The historical default made this catastrophic. Early MongoDB releases started mongod listening on 0.0.0.0 (all interfaces) with authentication off, so any newly stood-up database was, by default, an open door. The official Linux packages began pinning bindIp: 127.0.0.1 around the 2.6 era (2014), and MongoDB 3.6 (2017) finally made localhost-only binding the server default — but the millions of instances built before that, and every deployment that flips bindIp back to 0.0.0.0 “to make it work” without also enabling --auth, remain exposed. The neighbouring ports round out a cluster: 27018 for mongod shard/replica-set members, 27019 for config servers, and 28017, which used to host MongoDB’s built-in HTTP status/admin page (deprecated in 3.2, removed in 3.6) — if you see 28017 answering HTTP, you are looking at a very old MongoDB.

Common Risks

• Unauthenticated access (the big one). A MongoDB bound to 0.0.0.0 with no auth grants full read and write to every database to anyone who can reach port 27017. There is no exploit involved — connect, show dbs, and read or overwrite collections at will.
• Data-wipe ransom attacks. Automated campaigns scan for open 27017, drop the databases, and leave a ransom note collection demanding Bitcoin. Many attackers delete the data outright, so paying returns nothing.
• Weak or default SCRAM credentials. Even where authentication is enabled, weak passwords on the admin database fall to brute force, and reused/default app credentials hand over the same access.
• NoSQL injection from the application tier. Apps that build queries from untrusted input are vulnerable to operator injection ($ne, $gt, $where, $regex), which can bypass login logic or exfiltrate data even when the database itself isn’t directly exposed.
• Sensitive data and secrets in memory. The MongoBleed flaw (see CVEs) lets an unauthenticated attacker read uninitialised server heap memory over the wire — leaking credentials, session tokens, and keys from an otherwise “locked” instance.
• Information disclosure via build info. buildInfo, serverStatus, and isMaster/hello responses reveal the exact version, storage engine, and topology, telling an attacker precisely which bugs apply.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The first question on an open 27017 is whether it demands authentication at all. If it doesn’t, you are one command from the whole dataset. Confirm the service, then try an unauthenticated connection before anything heavier.

Detect the service and version

nmap -sV -p 27017 <target>

Pull build info and database list with NSE

nmap --script mongodb-info,mongodb-databases -p 27017 <target>

mongodb-info returns build info and server status; mongodb-databases lists databases (and flags which are empty) — both succeed only when the instance allows unauthenticated commands, which is itself the finding.

Connect with no credentials (the critical test)

# Modern shell
mongosh "mongodb://<target>:27017"

# Legacy shell (MongoDB < 5.0)
mongo --host <target> --port 27017

If you land at a prompt without being asked for a password, the instance is unauthenticated. Enumerate and sample data:

show dbs
use <database>
show collections
db.<collection>.find().limit(5).pretty()
db.stats()
db.getCollectionNames()
db.getSiblingDB("admin").system.users.find().pretty()

Brute-force SCRAM credentials (only where auth is on)

nmap --script mongodb-brute -p 27017 <target>

msfconsole -q
use auxiliary/scanner/mongodb/mongodb_login
set RHOSTS <target>
set USER_FILE users.txt
set PASS_FILE passwords.txt
run

The mongodb_login module also reports outright when authentication is disabled — a clean way to prove the no-auth condition at scale.

Test for the MongoBleed memory leak (CVE-2025-14847)

msfconsole -q
use auxiliary/scanner/mongodb/cve_2025_14847_mongobleed
set RHOSTS <target>
run

NoSQL injection against a fronting app

When the database sits behind a web app rather than on an open port, probe the app for operator injection — e.g. an authentication bypass payload:

{"username": {"$ne": null}, "password": {"$ne": null}}

Record every open port 27017, whether it accepted an unauthenticated connection, the database and collection names you enumerated, and any credential or leaked-memory evidence, so it all lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

The single most important thing to understand about port 27017 is that the biggest risk is not a CVE at all — it is the no-authentication default. An open, unauthenticated MongoDB needs no exploit; the “attack” is simply connecting. The CVEs below matter, but a hardened, authenticated, firewalled instance neutralises most of them, while a wide-open one is fully compromised regardless of patch level.

• CVE-2025-14847 — “MongoBleed.” Mismatched length fields in zlib-compressed wire-protocol headers let an unauthenticated client read uninitialised heap memory, leaking credentials, session tokens, keys, and other secrets straight off the wire. CVSS 8.7 (High). Affects a wide range of branches, fixed in 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17 and 8.2.3. Public PoC and in-the-wild exploitation were confirmed in late December 2025, and it landed on CISA’s Known Exploited Vulnerabilities list; Metasploit ships a scanner as auxiliary/scanner/mongodb/cve_2025_14847_mongobleed.
• CVE-2013-1892 — The classic MongoDB nativeHelper remote code execution. mongod before 2.0.9 and 2.2.x before 2.2.4 fails to validate requests to the nativeHelper function in SpiderMonkey, allowing a remote authenticated user to crash the server or execute arbitrary code via a crafted memory address. CVSS 6.0. Weaponised as Metasploit’s exploit/linux/misc/mongod_native_helper and archived as Exploit-DB 24935.
• CVE-2017-15535 — A flaw in the networkMessageCompressors (wire-protocol compression) option in MongoDB 3.4.x before 3.4.10 that could be abused to deny service or modify memory. CVSS 9.1 (Critical), though the feature is disabled by default, which sharply limits real-world exposure.
• CVE-2015-1609 — mongod before 2.4.13 and 2.6.x before 2.6.8 allows a remote unauthenticated attacker to crash the server (denial of service) via a crafted UTF-8 string in a BSON request. CVSS 5.0.
• CVE-2019-2386 — After a user is deleted, MongoDB Server improperly invalidates authorization sessions, so an authenticated user’s session can persist and become conflated with a new account that reuses the deleted username. CVSS 7.1. A real authorization bug — not a “crafted request” DoS.

Corrections to the previous version of this page. The old stub listed CVE-2019-2386 and CVE-2019-2389 with the same copy-pasted description — “allows remote attackers to cause a denial of service via a crafted request.” That is wrong for both. CVE-2019-2386 is the authorization-session-persistence issue described above, not a DoS. CVE-2019-2389 has been removed: it is a local issue in MongoDB’s packaged SysV init scripts (a user with write access to the PID file can cause arbitrary PIDs to be killed on shutdown) — a local privilege problem, not a remote attack against port 27017. Every CVE here has been re-verified against its NVD record and scoped to what actually reaches the wire.

Mitigation

• Enable authentication. Run mongod with --auth (or security.authorization: enabled), create an admin user, and enforce SCRAM-SHA-256. This is the single highest-impact control for this port.
• Bind to a trusted interface. Set bindIp to 127.0.0.1 and the specific private addresses that need access — never leave it on 0.0.0.0 on an internet-reachable host. Modern MongoDB defaults to localhost-only; keep it that way.
• Firewall port 27017 (and 27018/27019). Restrict access to application servers and cluster members only, using security groups, VPC rules, or host firewalls. Nothing on the public internet should reach these ports.
• Patch for MongoBleed and keep current. Upgrade to a fixed release (4.4.30 / 5.0.32 / 6.0.27 / 7.0.28 / 8.0.17 or later) to close CVE-2025-14847; as an interim workaround, disable zlib compression or switch the compressor to zstd/Snappy.
• Use TLS and strong, unique credentials. Encrypt client and intra-cluster traffic, and avoid reused or default passwords on the admin database.
• Parameterise queries in application code to shut down NoSQL injection — validate and type-check user input, and never pass raw user objects into query operators.
• Monitor and alert. Watch for unexpected dropDatabase operations, new admin users, ransom-note collections, and connections from unfamiliar source addresses.

Real-World Example

In early January 2017, attackers began mass-scanning the internet for MongoDB instances listening on port 27017 with no authentication — a direct consequence of the old “bind to all interfaces, no auth” default. Finding an open database took no exploit at all: the tooling simply connected, dropped the existing databases, and inserted a single collection containing a ransom note demanding a few tenths of a Bitcoin to “restore” the data. Researchers tracking the campaign watched the victim count climb from roughly 2,000 databases to over 10,000, then past 28,000 and eventually 45,000-plus within weeks, as multiple competing groups raced to hit the same exposed hosts. The cruelest detail: many attackers never exfiltrated anything — they deleted the data and collected ransoms for backups that no longer existed, so paying returned nothing. The “MongoDB apocalypse” is the definitive lesson of this port: a single insecure default, multiplied across tens of thousands of unfirewalled deployments, is a bigger risk than any memory-corruption bug. It is also why MongoDB 3.6 shipped with localhost-only binding as the default.

FAQ

What is port 27017 used for?

Port 27017 is the default network port for MongoDB. The mongod database server listens here and communicates over the binary MongoDB wire protocol with the mongosh/mongo shells and with application drivers. In a cluster, shard and replica-set members typically use 27018, config servers use 27019, and the mongos query router also listens on 27017.

Is it dangerous to leave port 27017 open?

Very, if the database is unauthenticated or reachable from untrusted networks. For years MongoDB shipped with no authentication and bound to all interfaces, so an exposed 27017 often means anyone can read and overwrite every database. Exposed instances are actively scanned for data-wipe ransom attacks. Keep 27017 firewalled to trusted hosts and always enable authentication.

How do I check whether my MongoDB requires authentication?

Try to connect without credentials: mongosh "mongodb://<host>:27017" and run show dbs. If you reach a prompt and can list databases without being asked for a password, authentication is off and the instance is exposed. nmap --script mongodb-info,mongodb-databases -p 27017 <host> gives the same answer remotely, and Metasploit’s auxiliary/scanner/mongodb/mongodb_login reports when auth is disabled.

What is MongoBleed (CVE-2025-14847)?

MongoBleed is a high-severity flaw in MongoDB’s zlib wire-protocol decompression that lets an unauthenticated attacker read uninitialised server memory over port 27017, leaking credentials, tokens, and keys. Disclosed in December 2025 and quickly exploited in the wild, it is fixed in MongoDB 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17 and later; disabling zlib compression is an interim workaround.

What ports do MongoDB shards and config servers use?

By default, standalone mongod and the mongos router use 27017, mongod shard/replica-set members use 27018, and config servers use 27019. The legacy HTTP status page historically lived on 28017 but was deprecated in MongoDB 3.2 and removed in 3.6 — an answering 28017 indicates a very outdated deployment.

How do I secure port 27017?

Enable authentication (--auth with SCRAM-SHA-256), set bindIp to localhost plus only the private addresses that need access, firewall 27017/27018/27019 to application servers and cluster members, enable TLS, use strong unique credentials, patch to a MongoBleed-fixed release, and parameterise queries to prevent NoSQL injection. Rescan with nmap -p 27017 <host> to confirm the port is no longer openly reachable.

TL;DR

• Service: MongoDB (mongod NoSQL database) over the MongoDB wire protocol; mongos router on 27017, shards/replicas on 27018, config servers on 27019, legacy HTTP page on 28017
• Default port: 27017/TCP
• Biggest risk: an unauthenticated mongod bound to 0.0.0.0 — full read/write to every database with no credentials, and a magnet for data-wipe ransom attacks; plus the unauthenticated MongoBleed memory leak (CVE-2025-14847)
• Mitigation: enable authentication, bind to localhost/trusted interfaces, firewall 27017–27019, enable TLS, patch to a MongoBleed-fixed release, and parameterise queries against NoSQL injection

Related open-database and data-store ports worth reviewing alongside MongoDB: Elasticsearch on port 9200 (the sibling open-NoSQL exposure story), CouchDB on port 5984 (a fellow document database with its own no-auth default), Cassandra on port 9042, Redis on port 6379, MySQL on port 3306, and PostgreSQL on port 5432. Capture every finding in your pentest reporting tool as you go.