MongoDB exposed to the internet without authentication: bindIp and the breach scenario

A mongod process bound to all interfaces with authentication disabled exposes every database to any host that can reach port 27017. If you are responding to a scan, PAGE, or audit, confirm the exposure, measure the blast radius, and eliminate the surface.

What this means

MongoDB’s net.bindIp controls which interfaces accept connections. Modern packages default bindIp to 127.0.0.1; exposure usually follows an explicit override to a wildcard such as 0.0.0.0 or ::. Without authentication, any reachable host can list databases, read or write documents, and execute administrative commands.

If the port is reachable from an untrusted network while auth is disabled, page immediately. An attacker can enumerate, exfiltrate, modify, or drop data without credentials. On a replica set, an attacker with inter-node reachability can execute replSetReconfig or trigger elections because the commands are not access-controlled.

Common causes

Quick checks

Run these read-only commands to assess exposure.

# Interfaces mongod is listening on at the OS level
ss -tlnp | grep 27017

# Alternative if ss is unavailable
netstat -tlnp | grep 27017

// Inspect effective bindIp from a connected mongosh session
db.adminCommand({ getCmdLineOpts: 1 }).parsed.net

// Verify whether authentication is enabled in the running config
db.adminCommand({ getCmdLineOpts: 1 }).parsed.security

# Authentication failure patterns; if auth is disabled this line will be absent
grep -c "Authentication failed" /var/log/mongodb/mongod.log

# Unauthorized command attempts
grep "not authorized" /var/log/mongodb/mongod.log | tail -20

What to look for:

• ss output showing *:27017 or [::]:27017 means the socket is not restricted to localhost or a private interface.
• getCmdLineOpts showing bindIp: "0.0.0.0" or a list including 0.0.0.0 confirms the configuration source.
• Absence of security.authorization: "enabled" in the parsed config means access control is off. Absence of authentication log lines despite active connections supports the same conclusion.

How to diagnose it

1. Confirm the bind address from the server. Connect via mongosh from a trusted host and run db.adminCommand({ getCmdLineOpts: 1 }). Inspect parsed.net.bindIp. If the value is 0.0.0.0, ::, or a public IP, the listener is exposed beyond localhost.
2. Corroborate at the OS layer. Run ss -tlnp | grep 27017. Look for LISTEN sockets on 0.0.0.0:27017 or [::]:27017. If the process column shows docker-proxy instead of mongod, the port is being forwarded from a container; inspect the publish mappings with docker ps --filter publish=27017 --format "table {{.Names}}\t{{.Ports}}" or the equivalent pod spec.
3. Determine if authentication is enforced. Check parsed.security.authorization in the output from step 1. If the field is missing or set to disabled, the instance allows anonymous connections. Verify by opening an unauthenticated mongosh session and running show dbs; success without a login prompt confirms auth is off.
4. Test network reachability from an untrusted vantage point. From a host outside the trusted network, attempt a TCP connection to port 27017 with nc or telnet. If the handshake succeeds, the port is reachable. This confirms that firewall or security group rules are not compensating for a permissive bindIp.
5. Review logs for exploitation indicators. Search MongoDB logs for spikes in connection attempts from unexpected source addresses, Authentication failed messages, or unauthorized commands against system collections such as local.oplog.rs or config.*. If you see new connections from IP ranges that do not match your application fleet, treat the node as potentially compromised and snapshot it for forensic analysis before restarting.

Metrics and signals to monitor

Fixes

Restrict the bind address

Edit mongod.conf to limit net.bindIp to specific addresses. In most production deployments, this should be a private IP used for replica set inter-node traffic and 127.0.0.1 for local administrative access. Avoid wildcard binds unless a load balancer or sidecar absolutely requires it, and never combine a wildcard bind with authentication disabled.

net:
  bindIp: 127.0.0.1,10.0.0.5
  port: 27017

Warning: Restarting mongod to apply bindIp is disruptive. On a replica set, a restart can trigger an election and briefly remove the primary’s write capability. Before you change a member’s bind address, verify that the new IP is still reachable from every other replica set member. The member address recorded in rs.conf() must match an interface the node listens on after the restart; otherwise the member will fall out of sync.

Plan rolling restarts one member at a time. Use systemctl restart mongod or db.adminCommand({ shutdown: 1 }) from a local administrative session. Confirm rs.status() returns PRIMARY or SECONDARY with no sync lag before proceeding to the next node.

Enable authorization

Create an administrative user before you enable auth if one does not already exist. Then set security.authorization: enabled in mongod.conf and restart.

security:
  authorization: enabled

Warning: If you enable authorization and no user exists, you must create the first user via the localhost exception from a shell on the same machine. Ensure bindIp includes 127.0.0.1 before you restart with auth enabled. If you are managing the node remotely and bindIp does not include localhost, create the admin user now while auth is disabled, or you will lock yourself out.

After the restart, verify that an unauthenticated mongosh session can no longer run show dbs.

Enforce firewall rules

Even with a restricted bindIp, add defense in depth at the host and network perimeter. Block inbound TCP 27017 except from known application hosts, replica set members, and jump hosts. On cloud platforms, restrict security groups to specific CIDR blocks. Do not rely on bindIp alone to survive a misconfigured container port mapping or a NIC alias added later.

Prevention

• Treat mongod.conf as code. Store it in version control and scan changes for bindIp containing wildcard addresses or missing security.authorization.
• Automate configuration audits. Run db.adminCommand({ getCmdLineOpts: 1 }) via your configuration management tool and assert that parsed.net.bindIp does not include 0.0.0.0 in production.
• Default-deny network policies. Configure host firewalls and cloud security groups to deny port 27017 ingress before deploying MongoDB. Open access only after confirming the bind address and auth are correct.
• Validate container deployments. Docker and Kubernetes port mappings can override host-level bind behavior. Audit docker ps or pod specs for -p 0.0.0.0:27017:27017 or hostNetwork: true.
• Scan provisioning templates. Gold images, Helm charts, and Terraform modules sometimes ship with bindIp: 0.0.0.0 to simplify initial connectivity. Review them before first deployment.

How Netdata helps

• Connection anomaly detection. Netdata tracks serverStatus.connections.current and totalCreated. A sudden spike without an application deploy can indicate scanning or a connection storm.
• Assertion correlation. Track serverStatus.asserts.user alongside authentication failure log patterns to distinguish application errors from security probing.
• Traffic context. Netdata captures opcounters and network bytes. Correlate unexpected traffic with configuration-audit windows to identify when exposure began.
• Restart impact. If you must restart mongod to apply bindIp or auth changes, Netdata monitors election timing, replication lag, and opLatencies so you can verify the rolling restart completed without client impact.

Related guides

• How MongoDB actually works in production: a mental model for operators
• MongoDB pages evicted by application threads: when eviction becomes user latency
• MongoDB balancer stuck and jumbo chunks: permanent imbalance and how to fix it
• MongoDB WiredTiger cache dirty ratio high: the leading indicator nobody watches
• MongoDB WiredTiger cache pressure cascade: eviction stalls and latency spikes
• MongoDB cache too small: sizing the WiredTiger cache for your working set
• MongoDB checkpoint duration climbing: diagnosing slow WiredTiger checkpoints
• MongoDB checkpoint stall write freeze: when all writes stop with no error
• MongoDB chunk migration storms: moveChunk I/O pressure and range locks
• MongoDB connection churn: high totalCreated rate and thread creation overhead
• MongoDB connection refused at maxIncomingConnections: hitting the connection ceiling
• MongoDB connection storm spiral: reconnection floods after an election or deploy