1,551 Elasticsearch and 1,462 Memcached Endpoints: Two Cache Layers With Different Defaults

Two ZoomEye host searches collected on 18 September 2026 returned 1,551 observable services on port 9200 and 1,462 on port 11211. Port 9200 is Elasticsearch's HTTP interface. Port 11211 is Memcached's default listener. The counts are similar; the security stories are not.

Elasticsearch: authentication that became a default

Elasticsearch's history with exposure is a case study in changing defaults. Early versions shipped with no authentication at all, and the result was a long series of incidents in which reachable clusters were read, modified or held for ransom. The 2017 Meow attack campaign deleted data from thousands of unsecured instances across Elasticsearch, MongoDB and other databases.
Modern Elasticsearch versions enable the security features by default, including authentication and TLS, when deployed through the standard distribution and configuration tooling. That change explains why the reachable population is in the low thousands rather than the hundreds of thousands: the default posture moved.
The remaining 1,551 endpoints are worth understanding individually. A reachable 9200 could be a cluster with authentication enabled and a firewall rule that is too permissive, which is a moderate finding. It could be a cluster with security explicitly disabled during a migration and never re-enabled, which is a serious one. It could be a read-only proxy or a monitoring endpoint. The port number alone does not distinguish these.

Memcached: a protocol with no authentication to enable

Memcached is a different case, because the protocol has no authentication mechanism at all. There is no requirepass equivalent, no user model and no access control. The only controls available are network-level: bind to a private interface, firewall the port, or use a Unix socket.
That design decision was reasonable when Memcached was written for a trusted data centre network. It becomes a problem when the port is reachable, because the protocol supports both read and write operations, and the values stored in a cache frequently include session tokens, serialised objects and application configuration.
Memcached also has a history of being used as a reflection vector in amplification attacks, because it can return a response much larger than the request over UDP. That is a separate concern from data exposure, and it is addressed by the same control: do not expose the port.

Why the two counts are close but the risk is not

1,551 and 1,462 are within 6% of each other. The similarity is coincidental. Elasticsearch's exposure is a residual population of misconfigured or legacy deployments, and each one may or may not be authenticated. Memcached's exposure is a population of services that cannot be authenticated by design, so every reachable instance is unauthenticated by definition.
For an assessment, that distinction changes the remediation order. A reachable Elasticsearch cluster should be checked for its security configuration before anything else, because the fix may be a single setting. A reachable Memcached instance needs a network change, because there is no setting that helps.

The check

For Elasticsearch, query the cluster's security configuration and confirm that authentication is enabled and that the cluster is not reachable from outside the network. For Memcached, enumerate listening services on 11211 and confirm the bind address. If an instance is bound to a public interface, the fix is to bind it to a private one and restart, which is a configuration change rather than a code change.
Both checks are cheap. The reason they are worth running is that both services are frequently deployed by application teams as internal components, and internal components are the ones that escape perimeter review.

What the numbers support

The defensible claim is that both cache layers remain reachable at similar scale, and that the similarity conceals a difference in kind. Elasticsearch exposure is a configuration problem with a configuration fix. Memcached exposure is a protocol design limitation with only a network fix. Treating them as the same category because the counts match would be a mistake.

References

• ZoomEye host search, dorks port:9200 (1,551) and port:11211 (1,462), collected 18 September 2026
• Elasticsearch documentation on security settings and default configuration
• Memcached documentation and protocol specification