Exposed Service
Exposed MongoDB Database
An exposed MongoDB database is a mongod instance reachable from the public internet (typically TCP 27017) with authentication disabled, so anyone who connects can read, modify, or delete every collection without credentials. It is one of the most reliably exploited data exposures on the internet and a frequent target of automated ransom-wipe campaigns.
Few exposures convert from "discovered" to "catastrophic" as quickly as an open MongoDB instance. The database engine is fast, schema-flexible, and trivially easy to stand up, which is exactly why so many teams ship it before they finish hardening it. When a mongod that holds production records, session tokens, or PII answers an unauthenticated query from an arbitrary IP address, the gap between an attacker finding it and an attacker owning it is measured in minutes, not weeks.
What it is
MongoDB is a document-oriented NoSQL database whose server process, mongod, listens by default on TCP port 27017 (with 27018/27019 used for shard and config-server roles). An "exposed MongoDB" finding describes an instance whose listening socket is bound to a public or all-interfaces address and that accepts connections without requiring authentication. Historically this was the out-of-the-box state: versions of MongoDB before 2.6 shipped with the server bound to 0.0.0.0 (all network interfaces) and access control disabled, so a fresh install was reachable by the entire internet with no username or password. MongoDB later changed the default bind address to 127.0.0.1 (localhost only) starting in version 3.6, but the localhost default is routinely overridden. Operators set bindIp: 0.0.0.0 or pass --bind_ip_all to make the database reachable from app servers, containers, or other hosts, and frequently forget to also enable access control (security.authorization: enabled). The result is a database engine that will execute privileged commands, including full collection reads, writes, and drops, for any client that can route a TCP packet to the port.
An unauthenticated MongoDB instance is not a theoretical risk; it is an actively harvested one. Automated campaigns have for years swept the internet for open mongod ports, copied or exported the data, dropped every collection, and inserted a single ransom note demanding Bitcoin, leaving organizations with no data and no leverage. Honeypot research in late 2025 found freshly deployed, authentication-less MongoDB instances receiving ransom notes within days of going live, confirming the attack pattern is fully automated and ongoing. The stakes are total: if your customer records, credentials, or session stores live in an open MongoDB, you stand to lose the data itself (wipe), lose control of it (mass exfiltration and resale), and lose the trust of regulators and customers who entrusted you with it. Because the database often holds the crown jewels rather than a single application's slice, a single open port can translate directly into a reportable breach, ransomware-grade recovery costs, and the kind of public incident that ends careers. The CWE program classifies the underlying weaknesses as Missing Authentication for Critical Function (CWE-306) and Binding to an Unrestricted IP Address (CWE-1327), both well-documented, high-impact failure modes.
At a glance
How attackers find and exploit it
- Enumerate candidate hosts by querying internet-wide scan engines (Shodan, Censys) or running a mass port scan for TCP 27017/27018/27019 across the target's known IP ranges and cloud allocations.
- Fingerprint each open port by sending a MongoDB wire-protocol handshake (an isMaster/hello command) to confirm a live mongod and read the version, build info, and replica-set role from the response.
- Test for missing authentication by issuing an unauthenticated administrative command such as listDatabases; if the server returns the database list instead of an authentication error, access control is off.
- Inventory and exfiltrate by enumerating databases and collections, then streaming documents out with mongoexport or mongodump; high-value targets are user, credential, session, and payment collections.
- Monetize through extortion by dropping all databases and writing a single collection (commonly named READ__ME_TO_RECOVER or similar) containing a Bitcoin ransom demand, often claiming the data was copied first.
- Pivot deeper where possible by reading connection strings, API keys, or internal hostnames stored in the data and using them to reach adjacent systems, or by abusing server-side JavaScript and stored credentials for lateral movement.
How to detect it on your surface
- Inventory every host in your external IP ranges, cloud accounts, and ephemeral container/Kubernetes environments, then scan for listening services on TCP 27017, 27018, and 27019.
- For each responding port, capture the service banner and version via an isMaster/hello probe and record whether the host is internet-routable rather than internal-only.
- Confirm whether authentication is enforced by attempting an unauthenticated, read-only command such as listDatabases and checking whether it succeeds or is rejected with an authorization error.
- Audit the running configuration of each mongod (net.bindIp / net.bindIpAll and security.authorization in mongod.conf, plus startup flags) to find instances bound to public or all-interfaces addresses.
- Cross-reference findings against firewall, security-group, and cloud network ACL rules to identify databases that are reachable from 0.0.0.0/0 rather than a restricted allowlist.
Detection signals
- An open TCP socket on 27017 (or 27018/27019) bound to a public/all-interfaces address that completes a MongoDB wire-protocol handshake.
- An isMaster/hello response that returns build and version metadata without ever prompting for credentials.
- A listDatabases or listCollections command that succeeds without authentication, returning real database and collection names.
- Scan-engine records (Shodan/Censys) tagging the IP as MongoDB with metadata such as version string, storage engine, and exposed database names.
- Presence of an anomalous ransom collection (for example READ__ME_TO_RECOVER, READ_ME_TO_RECOVER_YOUR_DATA, or a single document containing a Bitcoin address) where business data should be.
Validate before you report
- Confirm reachability from outside the perimeter by completing a TCP connection and MongoDB handshake from an external vantage point, distinguishing a genuinely public instance from one only reachable internally.
- Issue a single non-destructive, read-only command (listDatabases or db.runCommand({ connectionStatus: 1 })) to prove that the server executes commands without authentication, and capture the exact response as evidence.
- Record only metadata, database and collection names, document counts, and the server version, as proof of access; never read, export, write, or delete actual records during validation.
- Verify the configuration root cause by correlating the validated behavior with the host's bind address and authorization setting so the finding cites the specific misconfiguration, not just the open port.
- Capture an evidence bundle (timestamp, source IP, the command sent, and the unauthenticated response) so the finding is reproducible and defensible without re-touching the database.
What looks like this but isn't
- An open 27017 port that returns an authentication-required error to listDatabases is configured with access control and is NOT an unauthenticated exposure, even though the port is reachable.
- A honeypot, tarpit, or decoy mongod deliberately deployed by a defender can answer probes; confirm the instance is a real production/staging database before classifying it as a true exposure.
- Some load balancers, proxies, or non-MongoDB services answer on 27017; verify a valid MongoDB wire-protocol handshake rather than assuming the port number implies the service.
- An instance reachable only from a private VPC/peering range or a VPN-only address is not externally exposed even if it binds 0.0.0.0; confirm true internet routability before raising severity.
Remediation
- Immediately restrict network reachability: set net.bindIp to specific trusted private interfaces (or 127.0.0.1) instead of 0.0.0.0, and remove any --bind_ip_all flag, then restart mongod.
- Enforce firewall and cloud security-group rules so port 27017 is reachable only from an explicit allowlist of application hosts, never from 0.0.0.0/0.
- Enable access control by setting security.authorization: enabled, create a user-administrator account first, then provision a unique least-privilege user for each application or person that connects.
- Rotate any credentials, API keys, or tokens that were stored in or reachable through the exposed database, and treat the data as potentially exfiltrated until proven otherwise.
- Enable TLS/SSL for all client and intra-cluster connections so data in transit and authentication exchanges are encrypted.
- Patch the server to a supported, current release to close known issues such as the pre-authentication memory-disclosure flaw CVE-2025-14847 (MongoBleed), and verify backups exist and restore cleanly in case data was wiped.
Operational checklist
- Maintain an authoritative inventory of every MongoDB deployment, including ephemeral container and Kubernetes instances, and continuously scan external ranges for ports 27017/27018/27019.
- Adopt a secure-by-default deployment baseline (bind to localhost or private IPs, authorization enabled, TLS on) enforced via configuration management or infrastructure-as-code so new instances cannot ship open.
- Require authentication and least-privilege role assignment for every database user, and review user and role grants on a recurring schedule.
- Keep MongoDB on a supported version with a defined patch cadence, tracking advisories and the CISA Known Exploited Vulnerabilities catalog for MongoDB entries.
- Take and regularly test offsite, access-controlled backups so a ransom wipe is a recoverable inconvenience rather than a permanent loss.
- Enable database auditing and alert on anomalous administrative actions such as mass collection drops, unexpected listDatabases calls from new IPs, or creation of unfamiliar collections.
What to do next
An open MongoDB on the public internet is a breach that simply hasn't been billed yet: automated crawlers find these databases continuously, and the documented outcome is mass exfiltration followed by a ransom wipe. The decisive action is small and immediate, restrict the bind address, lock the port behind an allowlist, and turn on authorization, but only if you know the instance exists and have proof it answers strangers. Find your MongoDB ports today, confirm whether any answer an unauthenticated command, and close them before a crawler does the confirming for you.
Each guide is written by our team, reviewed by a named security contributor, and cited against primary sources such as OWASP, CISA, NIST, and MITRE. We update pages when the underlying guidance changes. See our contributors and company.
FAQs.
Why is an exposed MongoDB rated Critical rather than High?
Didn't MongoDB fix the default-bind problem years ago?
What is a MongoDB ransom wipe, and can I get my data back?
Can someone safely confirm an exposure without touching the data?
Is the open port alone enough to call it a finding?
How does Legba Adversary handle an exposed MongoDB database?
References
- 01
- 02
- 03
- 04
- 05
Weakness references (CWE)
Keep exploring
- Legba AdversaryValidated external attack surface, mapped in minutes.
- Exposure libraryBrowse finding types Adversary discovers and validates.
- Exposed API keys scannerFind and validate leaked secrets across your surface.
- EASM glossaryPlain-language explainers for attack-surface terms.
- Browser threat playbooksHow modern attacks start in the browser.
