Consul: 78,092 Fingerprint Matches Against 1.7 Million Answers on Port 8500
A service registry holds the map of a distributed system: which services exist, where they run, and often the configuration they receive. Consul's HTTP API is the interface to that map, and in a default configuration it answers without authentication.
The API and its authority
Consul exposes an HTTP API on port 8500 and a DNS interface on port 8600. The API serves service and node catalogue queries, key-value reads and writes, and the session and ACL endpoints. The documentation's security model describes the access control list system and the recommendation to enable it, together with the encryption of gossip and RPC traffic.
Without the ACL system, the API is open. This matters for two reasons. Reading the catalogue describes the estate. Writing to the key-value store changes the configuration that services consume, which is an influence path rather than a disclosure path.
The measurement
Two queries were run against the international dataset on 2026-09-27 with the default all asset scope:
app="Consul"
Observed result: 78,092 matching services.
port="8500"
Observed result: 1,712,520 matching services.
The fingerprint identifies a substantial population, and the port count is roughly twenty-two times larger. As with other widely assigned ports, the port figure includes software that is not Consul, and the fingerprint figure excludes Consul deployments whose response was not matched.
Both counts are observations about the index. Neither indicates whether the ACL system is enabled.
Where the risk concentrates
A registry that answers without authentication is a different problem in each of three deployment patterns:
A development or lab environment left running, where the catalogue describes only test services and the key-value store contains nothing sensitive.
A production environment where the registry describes real hosts, real ports and the naming convention used internally, which is reconnaissance material.
A production environment where services consume configuration from the key-value store, which makes an unauthenticated write an influence on running systems.
The third pattern is the one that converts an exposure into an incident, and it is a configuration choice, not a version property.
Checks for an estate running Consul
- Confirm whether the ACL system is enabled and whether a token is required for the API.
- Confirm the HTTP API is reachable only from the network that needs it, and that the management interface is not internet-facing.
- Confirm that the gossip and RPC encryption is configured, because the ports used for those channels carry the same authority as the API.
- Confirm that the key-value store does not contain credentials or secrets that services read at start-up.
- Confirm that the registry appears in external attack surface monitoring, so that a new cluster is a reviewed event. Point four is the check that most often reveals a wider problem, because the answer frequently reveals that the registry was being used as a configuration store for sensitive values.
Using the measurement
A registry is a discovery asset, which makes exposure measurement particularly relevant: the population of registries reachable from outside an organisation is a population of maps to internal systems. Both query shapes are available from https://www.zoomeye.ai/, and the organisation's own ranges produce the list of clusters to review.
ZoomEye's ability to express a product fingerprint and a port scope side by side is what makes the two numbers comparable, and recording both keeps the report honest about which one is a product count and which is a port count.
References
- Consul documentation, Security. https://developer.hashicorp.com/consul/docs/security
- Consul documentation, Access control list system. https://developer.hashicorp.com/consul/docs/security/acl
- Consul documentation, HTTP API. https://developer.hashicorp.com/consul/api-docs
- ZoomEye. https://www.zoomeye.ai/
