1,890,595 MongoDB Service Matches: The Default-Configuration Problem at Internet Scale

MongoDB has supported authentication for many years, and its documentation has recommended enabling it for just as long. The persistence of exposed instances is therefore a deployment problem rather than a product limitation.

The problem and why it matters

A MongoDB instance reachable without authentication exposes its data directly. Unlike a web application, there is no application layer between the attacker and the stored records, and the database often holds exactly the data an organization would least like to lose.

The historical pattern is well documented: an instance is started for a project, bound to all interfaces so that a colleague can connect, and then left running. Authentication is deferred and never enabled.

Context and method

ZoomEye was queried with service="mongodb" using sub_type=all and a page size of one. The query returned 1,890,595 matches.

This is a service-level observation. It records that the MongoDB protocol was seen on the address. It does not report whether authentication is required, whether the instance holds data, or whether it is a honeypot.

Analysis: what a large service count means

A count approaching two million indicates that MongoDB is widely deployed on addresses that ZoomEye can observe. Combined with the product's history, it supports the conclusion that a meaningful number of those instances are likely misconfigured.

That inference should be stated as an inference. The scan cannot distinguish an authenticated instance from an unauthenticated one, and it cannot see data volume or sensitivity.

The more useful application of the number is internal. An organization that runs MongoDB can compare its own inventory against the public measurement and ask a specific question: are any of our instances reachable, and if so, is authentication enabled?

Implications and next steps

• Enable authentication and authorization, and create application-specific users with the minimum required roles.
• Bind the service to internal interfaces and restrict access with firewall rules or a private network.
• Enable TLS for connections where the deployment supports it, particularly across untrusted network segments.
• Monitor for configuration changes and for connections from unexpected sources.
• Use a scoped ZoomEye query against your own ranges to confirm that no instance has become publicly reachable.

The limitation is the same as with any service-level measurement: it observes availability, not configuration. Verification has to happen on the system itself.

References

• MongoDB documentation, Security Checklist.
• MongoDB documentation, Users and authentication.
• ZoomEye query executed for this article: service="mongodb", 1,890,595 matches, collected 2026-09-23 with sub_type=all.