1,897,463 MongoDB services: how unauthenticated data stores became routine

The problem

MongoDB and Redis share a pattern: both were designed to run inside a trusted network, both became a common backend for quickly written applications, and both continue to appear at scale in exposure data. When authentication is optional in practice, it is often absent in production.

Method and scope

On 2026-09-30 (UTC) we queried ZoomEye for the MongoDB service fingerprint:

• Query: service="mongodb"
• Scope: all asset types, global
• Matching assets: 1,897,463
• Search link: https://www.zoomeye.ai/searchResult?q=c2VydmljZT0ibW9uZ29kYiI%3D We also attempted to scope exploitation history directly with a query for specific CVE identifiers. The queries vul.cve="CVE-2026-88771", vul.cve="CVE-2026-76461" and vul.cve="CVE-2026-94127" each returned zero matched assets. That result is reported here as a measurement limitation, not as evidence that those vulnerabilities are absent from the environment.

Why the count is a standing problem

A reachable database is different from a reachable web service. A web flaw usually requires a specific vulnerability to exist, while an unauthenticated data store requires only a connection. The reported outcome in these cases is rarely a single record; it is usually wholesale copying of a collection, often followed by a ransom note left in place of the data.
The pattern repeats because the convenient deployment habit is hard to break. A developer starts a container, connects from an application, and moves on. Authentication is deferred, binding is left at the default, and the firewall rule that was supposed to restrict access is created later or never. The service then stays reachable for years.

What to check

• Confirm the bind address and enable authentication, then verify from outside the host that an unauthenticated connection is refused.
• Restrict network access so that only application hosts can reach the database port.
• Enable role-based access control and give each application only the privileges it needs.
• Enable audit logging if the deployment supports it, and monitor for bulk read operations.
• Verify that backups are current and that a restore has been tested, because the recovery path matters when data is copied or deleted.

Reading the measurement

1,897,463 counts services matching the MongoDB fingerprint. It cannot report whether authentication is enforced, because that would require an authenticated connection. The figure measures visibility, which is a proxy for the population that must be checked by its owners.

Limitations

Cloud providers, managed database services and private networks hide most production instances from external measurement. The zero results from the vulnerability queries also show that the platform's vulnerability index does not cover every recent CVE at the time of collection. Both points should be stated plainly when a number like this is cited internally.

References

• MongoDB security checklists on authentication, authorization and network exposure.
• ZoomEye queries service="mongodb" and the vulnerability identifier queries, collected 2026-09-30 UTC.