29,265 internet-reachable HashiCorp Vault instances: the secret store on the open internet
Opening
Vault is a secrets manager. It holds the credentials that other systems use to authenticate to each other: database passwords, API keys, certificates, cloud access tokens. It exists to remove secrets from configuration files and place them behind an auditable API with leases and revocation.
A ZoomEye fingerprint query for the Vault application signature returns 29,265 services reachable from the public internet, collected on 24 September 2026 (UTC). The count describes deployments whose management API answers a fingerprint. It does not describe configuration, seal state or whether the deployment is a test instance.
Context and method
| Query | exact_count | What the query measures |
|---|---|---|
app="HashiCorp Vault" |
29,265 | Services matching the ZoomEye application fingerprint for HashiCorp Vault |
app="etcd" |
0 | Services matching the fingerprint for etcd |
The second query is included because of what it shows about method rather than about etcd. A count of zero is not a statement that no etcd instance is reachable; it is a statement that no reachable service answered the fingerprint as ZoomEye defines it. Fingerprint definitions vary in specificity, and a product that does not expose a distinctive banner will return a low or zero count regardless of how many instances are running. Reading a zero as absence would be a mistake.
Analysis and walkthrough
Why a secret store is the highest-consequence administrative interface
Vault's API surface is not a dashboard. It is the interface through which applications request credentials, and it is authenticated by mechanisms that include tokens, AppRole, cloud identity and certificates. A reachable Vault API from the public internet is a reachable store of the credentials to everything the deployment is wired to.
The consequences differ from those of an exposed monitoring tool. Zabbix exposure risks the inventory of hosts. Vault exposure risks the keys. A deployment that brokers database credentials for a fleet means an attacker who obtains access through it can authenticate to those databases as a legitimate client, with the same lease semantics the platform intends.
Why network position is the control that matters
HashiCorp's own operating guidance is that Vault should sit on a private network, reachable by the systems that consume secrets and by the operators who administer it. This is a design assumption rather than a hardening suggestion: the trust model for auto-unseal, for the storage backend, and for the cluster's internal communication assumes the network in front of it is controlled.
An instance answering a public fingerprint suggests one of a few situations. It might be a development or demonstration deployment that was never meant to persist. It might be production behind a reverse proxy whose hostname is discoverable. It might be a deployment whose operator assumed the unguessable URL was the access control. In each case the relevant question is the same: what can a client reach from the public address?
Distinguishing the exposure from a vulnerability
This measurement is not a claim that 29,265 Vault deployments are vulnerable to a specific CVE. It is a claim that 29,265 instances present an administrative interface to the public internet. Whether any particular instance is a problem depends on authentication configuration, network policy, audit logging and what the deployment holds.
That distinction matters in triage. A team that reads the number as a vulnerability count will treat it as somebody else's problem. A team that reads it as an exposure measurement will check whether its own instance appears in the same query.
Implications
Where ZoomEye fits
Secret stores are the class of system where an outside view is most valuable, because the operator's own view is defined by the perimeter they built. ZoomEye lets a team run the same fingerprint query an outside observer would run and compare it against the intended network position. The public interface is at https://www.zoomeye.ai.
Practical steps
- Run the query and check whether your deployment appears in it. If it does, the next question is which network boundary it was supposed to sit behind.
- Verify that the API is not the only reachable surface. A deployment behind a proxy may still expose the cluster port or the UI.
- Confirm that audit logging is enabled and shipped. On a secrets manager, the audit device is the record of who read what and when it was revoked.
- Treat any credential read through a suspected exposure as revoked, not merely rotated. Vault leases exist to make revocation specific.
- Review whether development instances have public addresses. The test deployment that nobody decommissioned is a recurring source of a high-consequence exposure.
- Do not read a zero count for a different product as evidence of nothing. Fingerprints measure what they are defined to measure.
References
- ZoomEye query interface:
app="HashiCorp Vault"andapp="etcd", collected 24 September 2026 (UTC) - ZoomEye: https://www.zoomeye.ai
- HashiCorp Vault documentation: https://developer.hashicorp.com/vault/docs
Top comments (0)