350,000 Exposed Elasticsearch Instances: What Internet Measurement Says About Default Deployment
A ZoomEye query for app="Elasticsearch" returns 350,056 matching assets. That number is not a vulnerability count. It is a count of internet-reachable services that identify themselves as Elasticsearch, and it is large enough to be worth understanding rather than dismissing.
The problem
Elasticsearch was designed to run inside a trusted network. Early versions shipped with no authentication enabled by default, and the HTTP API accepts queries, index operations and cluster management commands from anything that can reach port 9200. The project has since added a security layer, but the deployment pattern that made the exposure common has not disappeared: a service installed for internal search, bound to all interfaces, and reachable from the internet because nobody checked.
How the measurement was taken
The figures in this article come from a single ZoomEye query executed on 2026-09-16:
- Search dork:
app="Elasticsearch" - Scope:
sub_type=all - Result: 350,056 matching assets
This is a product fingerprint query. It identifies assets that ZoomEye recognises as Elasticsearch. It does not confirm that any specific instance is unauthenticated, misconfigured or vulnerable to a particular CVE. A hardened cluster behind a reverse proxy with authentication can still match the fingerprint. The count measures exposure of the product surface, not confirmed compromise.
What the exposure actually means
Three distinct risks sit behind that number, and they should not be conflated.
Unauthenticated access. Where the security features are disabled or not configured, the REST API answers without credentials. An attacker who reaches the port can list indices, read documents and in many configurations delete data. The classic indicator is a root endpoint response that returns cluster metadata without a 401.
Information disclosure through metadata. Even with authentication enabled, misconfigured clusters can leak index names, mapping details and cluster health through error messages or unauthenticated endpoints. Index names alone often reveal what an organisation stores.
Lateral movement and resource abuse. A reachable cluster is a foothold. Attackers have used exposed search and database services for cryptomining, for staging data, and as a pivot into the surrounding network.
Where the concentration is
Exposure is not evenly distributed. The practical pattern observed across internet-wide measurement is that a small number of hosting providers and cloud regions account for a disproportionate share, because that is where default images and quick-start deployments live. A defender's first useful step is not the global number but their own: query the organisation's address space for the same fingerprint and compare it against the asset inventory. Discrepancies are the finding.
Practical next steps for defenders
Confirm the binding. Check whether the service listens on a public interface. network.host and the container port mapping are the two places this is usually decided. If the answer is "all interfaces because that was the default", that is the finding.
Enable and test authentication. Turn on the security features, create a non-default administrative user, and verify from outside the network that an unauthenticated request is rejected. Configuration that has never been tested from the attacker's position is an assumption.
Remove the default port from the public path. If the cluster must be reachable for a legitimate integration, put it behind an authenticated proxy and restrict source addresses. Direct exposure of port 9200 to the internet is rarely a requirement.
Inventory the data. If an instance was exposed, assume the data was read. Determine what indices existed and whether they contained personal, credential or business-sensitive material. That determines the notification and remediation path.
Watch for the follow-on. Exposed search services are frequently used as an initial access vector and then as a staging area. Check for unexpected indices, new users, snapshot repositories pointing at external storage, and outbound connections to unfamiliar hosts.
Limitations
A product fingerprint count cannot tell you how many of those 350,056 assets are unauthenticated, how many hold sensitive data, or how many are honeypots. ZoomEye's fingerprinting is based on observable service characteristics, and a service can change between the scan and the reader's inspection. The number should be read as a scale indicator for a known deployment problem, not as a breach count. Any organisation acting on this should measure its own exposure rather than reason from the global total.
References
- Elastic documentation, "Secure the Elastic Stack": https://www.elastic.co/guide/en/elasticsearch/reference/current/security-minimal-setup.html
- Elastic documentation, "Network settings" (
network.hostbinding): https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html - CISA, "Securing Elasticsearch": https://www.cisa.gov/news-events/alerts
- ZoomEye search interface: https://www.zoomeye.ai/
