Container Registries and Orchestration: 57,017 Harbor and 78,059 Consul Fingerprints
Two sides of the same deployment
Container registries distribute images to the hosts that run them. Service discovery and configuration systems tell those hosts where everything else is. Together they describe an application platform's internal map, and their internet exposure is worth measuring separately because each exposes a different capability.
The measurements
Queried on 25 September 2026 through the ZoomEye SDK with application fingerprints: app="Harbor" returned 57,017 matching assets, app="Consul" returned 78,059, and app="Docker Registry" returned 1. Counts represent fingerprint matches in ZoomEye's index at query time.
What each exposure leaks
A reachable container registry is a distribution point. If an attacker can push to it, every host that pulls from it receives the attacker's image. If they can only read from it, the registry still discloses which images the organisation runs, including internal-only components whose names and versions are otherwise not published.
A reachable service discovery or configuration system is a map. Consul, for example, can expose the service catalogue, health status, and in some configurations the key-value store used for dynamic configuration. That is a reconnaissance advantage that does not require exploiting anything: it tells the attacker what exists and often where it runs.
The Docker Registry count of 1 is a reminder that fingerprint naming is inconsistent across products. The official registry image presents itself in ways that the fingerprint may not match reliably, so a count of 1 should be read as a fingerprint limitation rather than as evidence that one registry is exposed.
Why the registry number deserves attention
The Harbor count is the one to act on. The same September 2026 exploitation cluster that included artifact repositories also demonstrated that the default configuration of a software distribution system can be an authentication bypass. A registry with an administrative interface reachable from the internet inherits the same risk category, and unlike an application server it can be used to distribute code to production.
Practical checks
- Restrict registry and service catalogue APIs to the networks that need them, and require authenticated, scoped tokens for pulls rather than anonymous access.
- Enable and verify content signing or provenance so that a pushed image can be attributed, since detection of a malicious push depends on being able to tell legitimate images from new ones.
- Review the key-value store for secrets placed there for dynamic configuration, and rotate anything that was reachable during a suspected exposure window.
Limitations
Fingerprint counts depend on how services present themselves and undercount deployments behind proxies or authentication gateways. Harbor saw a significant share of its deployments moved behind corporate identity providers after earlier advisories, which the count does not distinguish. All figures are single-date observations.
References
- ZoomEye search, executed 25 September 2026:
app="Harbor"returned 57,017 matching assets;app="Consul"returned 78,059;app="Docker Registry"returned 1 (SDK, sub_type=all, total count) - CISA Known Exploited Vulnerabilities catalog, September 2026 additions referenced for context: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- MITRE ATT&CK T1190 Exploit Public-Facing Application: https://attack.mitre.org/techniques/T1190
Top comments (0)