Data Stores on Reachable Addresses: 680,483 MongoDB, 350,304 Elasticsearch and 808,443 Solr Fingerprints

Data stores are the asset class where an exposure finding has the shortest path to consequence. There is no application layer to mediate, no authentication proxy in the normal deployment, and the data is already in the form the attacker wants.

Measurements taken 20 September 2026 returned 680,483 matches for app="MongoDB", 350,304 for app="Elasticsearch", 808,443 for app="Apache Solr", 194,077 for app="InfluxDB", 124,969 for app="ClickHouse" and 980,225 for app="CouchDB".

What these counts are

Each is a product fingerprint count: assets the dataset positively identifies as running that product on a reachable address. None of them is a count of unauthenticated data stores, and none is a count of exposed databases in the sense of a database that will answer a query from an anonymous caller.

That gap is the whole subject. A data store can be reachable and still require credentials. It can be reachable and bound to a loopback interface behind a proxy. It can be reachable and hold nothing of value.

The count tells you the product is widely deployed where it can be reached. It does not tell you what happens when you reach it.

Why this class is different

Three properties distinguish data stores from other exposed services.

The default deployment is often unauthenticated. Several of these products shipped without authentication enabled by default for years, and some still do in their simplest configuration. The historical default is why the exposure pattern persists.

The data is the objective. Compromising a web server yields a foothold. Compromising a data store yields the records, in bulk, in a format that requires no further exploitation.

The service is designed to be queried. A database port that accepts a connection is doing what it was built to do. There is no exploit required to read data from a store that does not ask for credentials.

Reading the spread

The counts range from 124,969 to 980,225. The variation reflects deployment popularity and fingerprint reliability in different proportions, and separating the two is not possible from the counts alone.

app="Apache Solr" returning 808,443 is a case where the fingerprint may match broadly, since Solr is frequently embedded in applications and its administrative interface has a recognisable signature. app="ClickHouse" at 124,969 and app="InfluxDB" at 194,077 are time-series stores whose deployment is more specialised.

A defender should treat the relative sizes as a rough ordering of how likely a given product is to appear in their own scan results, not as a ranking of risk.

The inventory method

Query your own ranges by port and by product. The port query finds the service; the product query confirms identity. Run both.

Check authentication, not just reachability. For each match, determine whether the service requires credentials. This is the finding that matters and it cannot be read from a fingerprint.

Check the binding. A service bound to all interfaces on a host with a public address is reachable. A service bound to loopback is not, regardless of what the fingerprint suggests.

Check what the store holds. A development cache and a customer database are the same fingerprint and different incidents.

Re-measure after the change. Binding a service to a private interface should change the query result.

The historical-default problem

Products that shipped without authentication trained a generation of operators to expect that behaviour. Documentation, tutorials and container images reproduced it. The result is a large installed base where the default configuration is the insecure one, and where the operator has to take an explicit action to be safe.

That is a product design decision with a long tail. It is also why this class of finding recurs in every measurement cycle rather than declining.

What the numbers justify

They justify asking the inventory question. They justify running the query against your own address space. They justify checking authentication on every match.

They do not justify a claim that 680,483 MongoDB instances are open, or that any specific count of records is exposed. Those claims require evidence the fingerprint does not provide, and stating them weakens the finding that is actually supported.

Using ZoomEye for data-store inventories

ZoomEye's product fingerprints let you enumerate this class across vendors in a single pass and compare the result against your own asset register. The useful output is not the global count but the list of matches in your ranges that nobody can account for.

References

• ZoomEye AI cyberspace search, queries executed 20 September 2026, sub_type=all: app="MongoDB" = 680,483; app="Elasticsearch" = 350,304; app="Apache Solr" = 808,443; app="InfluxDB" = 194,077; app="ClickHouse" = 124,969; app="CouchDB" = 980,225. Counts describe internet-observable matching assets at query time and do not confirm vulnerability, missing authentication or exploitation.
• ZoomEye search: https://www.zoomeye.ai/