The number
A ZoomEye query for app="Harbor" returned 57,117 matching hosts, collected on 2 October 2026 with sub_type=all and a page size of one record. The count is the fingerprint match total for the registry. A registry is a supply chain component, and its position is different from the other products in this series: the other services read data, while this one decides what code runs.
What the surface tells an attacker
Harbor presents a web interface and a registry API. The interface exposes a login page that identifies the product and often the version, and a public project exposes the images inside it, including their tags and manifest details. The registry API serves image manifests and layers to any client that can authenticate, and project visibility settings decide whether a project is public.
The version matters more here than elsewhere because registries have been the subject of advisories affecting the API and the job service. The interface also frequently reveals the projects an organisation maintains by name, which maps directly to the services it deploys.
What the count does not say
57,117 hosts identify as Harbor. It does not say how many have public projects, how many allow self-registration, how many enforce a vulnerability scan policy before an image can be pulled, or how many sit behind an identity provider. Each of those is a per-instance configuration, and each changes the risk.
Why the exposure matters
A registry that can be written to is a code execution primitive against every host that pulls from it. The interface supports robot accounts with scoped permissions, and a robot account with push access to a project is enough to replace a tag that a deployment consumes. Registries that allow anonymous pull but require authentication for push reduce that risk, and registries that permit registration of a new account with default project permissions do not.
Read access has its own value. An image contains the application's files, its dependency manifest, and sometimes a configuration layer that was baked in during the build. Public projects therefore disclose more than the existence of a service.
What to do
Disable self-registration, disable public projects unless a project is intentionally published, and confirm that push access requires authentication and is scoped to a robot account with a narrow project. Enforce a scan policy on push so that a vulnerable base image is visible before it is deployed.
Keep the registry on an internal network or behind a proxy that authenticates, and confirm the job service and the database are not separately reachable, because a registry deployment is several services and the interface is only one of them. Finally, verify that image tags consumed by deployments are immutable or pinned by digest, so replacing a tag is not sufficient to change what runs.
References
- Harbor documentation. https://goharbor.io/docs/
- ZoomEye. https://www.zoomeye.ai/
Top comments (0)