A container registry is the supply chain's front door. Every image that reaches production was pushed to it and pulled from it, and the tags in a registry describe what the organisation is running and when it last shipped. CVE-2022-46463 covers the Harbour search API returning that information without an authorisation check. The interesting part of the story is what happened afterwards.
The report and the response
The search endpoint, used by the web interface to find projects and repositories, returned results across the registry rather than only the projects the caller could access. Affected releases ran from the 1.x line through 2.5.3, with fixes in 2.5.4 and 2.6.1. An unauthenticated request could enumerate repository names, tags and in some cases the metadata that accompanies them.
The vendor's position, stated publicly by maintainers, was that public projects are a documented feature and that the information returned was therefore not confidential. That reading is defensible in isolation and incomplete in context. The header of a registry is not the confidential part; it is the targeting data for the confidential part. Knowing that a project called payments-gateway exists, with a tag matching a release date two weeks before a known library vulnerability, is reconnaissance that does not require reading a single layer.
What enumeration gives an attacker
Repository names in an internal registry leak organisational structure: team names, service names, environment suffixes, sometimes customer identifiers. Tags leak release cadence and version pinning, which identifies which images are stale. Manifests, when reachable, reveal base images, which is the fastest way to find every service still built on an image with a known critical flaw.
None of that requires authentication, which means none of it appears in audit logs as a login. It appears as a series of normal search requests, indistinguishable from the web interface doing its job.
There is a second issue in the same period worth pairing: default administrative credentials. The documented initial password for the built-in administrator account in the standard deployment is a string that has appeared in vendor documentation for years, and installations that never completed the rotation step are trivially accessible. The registry then becomes not just an inventory but a push target.
The governance problem
The reason to write about this defect rather than a more severe one is the pattern it represents. A design decision about visibility was made once, documented, and treated as closed. The population of deployments that then exposed an enumerable registry to the internet did not make that decision; they inherited it.
For defenders the practical consequence is that "not a vulnerability" and "not a risk" are separate determinations, and the second one belongs to the operator. A registry that returns its inventory to anonymous callers is functioning as designed and simultaneously briefing anyone who asks.
Reviewing your own registry
- 1.
Query the search endpoint anonymously and note exactly what it returns. The result is your real exposure, regardless of what the advisory says.
- 2.
Restrict the registry to authenticated access at the proxy for internal deployments, and use separate projects when public visibility is a requirement.
- 3.
Rotate the administrator password and audit for other default-credential deployments in the same environment, including CI runners that hold push rights.
- 4.
Review whether registry metadata is mirrored into a public index, since a private registry that syncs to a public one defeats the control.
- 5.
Monitor for enumeration patterns: sequences of search requests across many project names from a single address are reconnaissance, not usage.
References
NVD record for CVE-2022-46463, unauthorised repository enumeration through the Harbor search API.
Harbor security advisory and release notes for 2.5.4 and 2.6.1.
Harbor documentation on project visibility and the default administrator credential.