ZoomEye scan finds 29,265 internet-exposed HashiCorp Vault instances

A ZoomEye scan has surfaced 29,265 HashiCorp Vault services that answer on the public internet, according to an analysis published on dev.to. The figure comes from a fingerprint query matching Vault's application signature, run against data collected on 24 September 2026 (UTC), and it counts deployments whose management API responded to that fingerprint from an outside network.

What the count does and does not say

The number is an exposure figure, not a vulnerability tally. The dev.to author is explicit that the query cannot tell whether any given instance is sealed, how its authentication is configured, or whether it is a leftover demo deployment. What it does establish is that the administrative surface of each of those services is reachable without first breaching a private network.

The post also runs a comparison query for etcd, which returns zero, and draws a methodological lesson from the result: fingerprint counts measure only what the fingerprint is defined to match. A product that does not emit a distinctive banner can return zero no matter how many instances are running, so a zero result should never be read as proof of absence.

Why an exposed Vault is different from other exposed services

Vault is a secrets manager: it holds database passwords, API keys, certificates and cloud tokens, and issues them through an authenticated API with leases and revocation. The dev.to analysis argues this makes its network interface categorically riskier than other commonly exposed tools. An exposed monitoring system leaks an inventory of hosts; an exposed Vault can hand over the credentials those hosts use to authenticate, and an attacker who gains access inherits the same lease semantics as a legitimate client.

HashiCorp's own operating guidance, cited in the post, is that Vault belongs on a private network reachable only by the systems consuming secrets and the operators administering them. That is framed as a design assumption rather than optional hardening: features such as auto-unseal, the storage backend and the cluster's internal communication all presume the network in front of Vault is controlled. A public fingerprint hit can indicate a development instance that was never decommissioned, a production deployment discoverable through a reverse proxy, or an operator treating an unguessable URL as an access control.

Exposure versus exploitability

The distinction matters for triage. A team that reads 29,265 as a count of vulnerable systems may treat it as somebody else's problem, since no specific CVE is implicated. Read instead as a measurement of exposure, the natural next step is to check whether your own deployment appears in the same query and, if it does, which network boundary it was supposed to sit behind.

Checks operators can run

The dev.to post suggests a short list of follow-ups:

• Run the ZoomEye query for the Vault fingerprint and see whether your deployment shows up in the results.
• Look beyond the API: a deployment behind a proxy may still expose the cluster port or the web UI.
• Confirm audit logging is enabled and shipped elsewhere, since the audit device is the record of who read which secret and when it was revoked.
• Treat any credential read through a suspected exposure as revoked rather than merely rotated, which is what Vault's lease model is built to support.
• Review whether development and test instances have public addresses, since forgotten test deployments often account for this kind of exposure.

Why it matters

Vault instances concentrate an organisation's credentials in a single system, so their network position is itself a security boundary. A five-figure count of publicly reachable services, whatever their individual configurations, means thousands of secret stores sit one authentication weakness, misconfigured proxy or abandoned test deployment away from giving an attacker working credentials for everything they broker. The mitigation is cheap and symmetrical: run the same query an outside observer would run, and move anything that answers behind a controlled network.