3.2 Million Redis and 1.9 Million MongoDB Services: The Steady Background of Exposed Data Stores

Month after month, the same services appear in internet scan data at the same order of magnitude: Redis in the millions, MongoDB in the millions, and a long tail of databases below them. These are not new vulnerabilities. They are a persistent configuration outcome, and they deserve a place in any account of enterprise exposure that goes beyond patching.

The scale

ZoomEye queries run on 20 October 2026 with sub_type="all" and a page size of one record returned:

Query	Matched assets
service="redis"	3,207,842
service="mongodb"	1,923,240
service="ldap"	1,089,053
service="ssh"	166,939,313
service="rdp"	16,527,336

These counts describe services that answered on a scanned port. They do not indicate authentication status, data content, or ownership. A Redis instance listening on a public address with requirepass set and a firewall allowlist is still counted.

Why data stores are a different category of exposure

Edge appliances and remote-access gateways appear in vulnerability reporting because they are exploited through specific flaws. Data stores appear in scan data because of how they are deployed, independently of any CVE.

The recurring pattern is familiar to anyone who has audited a cloud account: a database instance launched for a quick test, bound to all interfaces, with authentication left at default or disabled, and a security group rule that was meant to be temporary.

The difference from a vulnerable appliance is that no patch fixes this. There is no vendor update that closes a publicly reachable Redis with no password.

What a reachable data store actually risks

Three consequences follow, in ascending order of severity.

Data disclosure. Direct read access to the stored dataset, with no application-layer control in between.

Write access and integrity loss. Many of these systems permit writes from an unauthenticated client, meaning an attacker can alter records, plant content, or corrupt the dataset.

Module-based execution. Certain data stores support server-side scripting or module loading. Where an instance is reachable and unauthenticated, the step from data access to command execution has historically required no vulnerability at all.

That last point is why an exposed data store should be treated as a potential host compromise rather than a data-handling issue. The distinction changes the response: rotating application credentials is necessary, but so is examining the host itself.

The LDAP number and its own meaning

service="ldap" at 1,089,053 is worth separating from the databases. LDAP exposure is usually a directory service reachable beyond its intended client population, which is a different configuration error with a different consequence: authentication and directory enumeration.

A directory that answers unauthenticated queries can disclose user and group structure, which is reconnaissance value rather than data theft. That reconnaissance is often the first step in a chain that ends in credential attack.

A practical review, ordered by effort

Find the instances. Query the protocols you operate, restricted to your address ranges or providers. Compare the result against the asset register.

Classify by authentication mode. An instance requiring authentication is a lower priority than one that does not. Determine this from the application configuration, not from a scan.

Check bind addresses. A data store bound to a specific private interface is materially different from one bound to all interfaces. This is a configuration check that takes minutes.

Verify network policy independently of the binding. A store bound correctly but reachable through a permissive security group is still exposed. Check the policy as its own artifact.

Log and alert on authentication failures and connections from unfamiliar networks. Data stores usually have this capability disabled by default.

Inventory the hosts behind the numbers. The largest category of finding in these audits is a host nobody claims. Ownership resolution is the step that converts a scan result into a remediation task.

The honest framing

These numbers will be similar next quarter. Exposed data stores are a stable feature of the internet, not a spike, because they arise from deployment convenience rather than from a specific defect.

That makes them an unglamorous priority. They do not generate advisories, and they rarely produce a headline. They produce breaches that are discovered when a dataset appears for sale, which is considerably later than when they could have been found by comparing a scan against an inventory.

References

• ZoomEye, search interface, queried 20 October 2026 for the dorks listed above.
• CISA, Known Exploited Vulnerabilities Catalog, for context on which exposed services have recently been targeted.
• Redis, security documentation on access control.
• MongoDB, security checklist.