- OX Security found that Harbor's webhooks accept internal addresses. On cloud-hosted instances, a registered user can make the server fetch its own cloud credentials. Fixes exist in four release lines.
- OX argues a Moderate score understates the risk, because Harbor's cloud identity is broad and sits above its own project permissions.
- Upgrade, check whether self-registration is on, and ask what Harbor's cloud role can reach.
A severity score rates a flaw. It does not rate where the flaw sits. A bug in a component that holds keys to many systems can matter more than its number suggests. A newly disclosed weakness in Harbor, the open-source container registry, shows how.
OX Security reports that Harbor's webhook feature can be aimed at internal addresses. That lets a registered user make the server fetch its own cloud credentials. The GitHub advisory (GHSA-2phj-cp9f-qq6w) scores the flaw 6.4, rated Moderate. OX argues the impact is worse than a typical server-side request forgery (SSRF). The facts it lays out support that.
Why Harbor's position matters
Harbor is a CNCF project that stores container images. OX cites more than 29,000 GitHub stars and more than 10 million pulls of its Core image. It sits between build pipelines, vulnerability scanners and Kubernetes clusters. On a shared instance, project-level permissions keep tenants apart.
That central role is the point. If an attacker steals Harbor's cloud credentials, they inherit everything Harbor's cloud identity can reach. OX names storage buckets, the Kubernetes API and internal databases.
How the attack works
A webhook is an automatic message. When an event happens in a project, such as an image push, Harbor sends a web request to an address the project owner picked.
When someone creates a webhook, Harbor runs a check called validateTargets(). It confirms the address starts with http or https. It confirms the address is a valid URL. That is all it does.
Private addresses pass. So do addresses on the server itself, and so does the cloud metadata address, 169.254.169.254.
Delivery adds no protection. A file named webhook_job.go hands the saved address to a plain HTTP client. OX found no filter on IP addresses anywhere between saving the webhook and sending the request.
The metadata address matters because it is the cloud Instance Metadata Service. The internet cannot reach it. From inside a cloud server, though, it hands out temporary access credentials on request. Harbor's job service becomes that inside caller.
The steps are short. First, the attacker creates a project. That makes them its ProjectAdmin automatically. Next, they create a webhook aimed at the metadata address. Harbor replies HTTP 201, which means it accepted the address without complaint. Any project event then fires the request, and the credentials come back.
OX's test used a stock install. It ran Harbor v2.12.0, set up with the official Docker Compose installer and left on default configuration. A listener caught the outbound request after an image push.
A small door into a large identity
Most SSRF flaws require administrator access to set the outbound address. This one needs only a registered account. On instances that let people sign themselves up, an email address gets you in.
OX's scan found 6,370 reachable instances. Every one ran a pre-fix version. Of these, 718 are cloud-hosted, where the metadata service can be reached directly. In the scan, 66% of the scanned instances expose a system information endpoint without a login. That endpoint leaks their configuration.
Twenty-five instances allow self-registration. Four of those sit in Azure or GCP address ranges. OX says any internet user could register on those four and pull the host's managed-identity credentials.
OX also describes what sits behind some of these registries. It points to a registry on Azure that lets the public pull two AI model-serving containers, one running llama.cpp and the other a vLLM multimodal server. Credentials in a setup like that typically open up GPU compute, model storage and machine-learning workspaces, according to OX.
Another registry supplies a service mesh to Kubernetes clusters worldwide. One component there has more than 560,000 pulls. Some instances trace back to national supercomputing sites and research universities. They do not allow self-registration. But accounts go to researchers, collaborators and guests, so OX says the pool of possible attackers is large.
Why a Moderate score may understate the risk
This shows the gap between a flaw and the identity it borrows. The score describes the flaw. The exposure comes from what the stolen identity can do.
OX says Harbor's cloud role is usually wide. It can read and write the shared image storage. It also holds keys for the scanner integration and for replication.
In shared setups, that breaks the wall between tenants. Cloud credentials sit above Harbor's own project permissions. OX says one tenant could read or overwrite another tenant's images at the storage layer.
OX reports a second problem that surfaced during the fix. The job service wrote the full webhook response into a task log. Any ProjectAdmin on the project can read that log. Against the metadata service, the response holds the access key, secret key and session token. One malicious webhook would then show the credentials to the whole project team.
What to do and ask
Harbor accepted OX's report on September 22, 2026. It has shipped fixes on four release tracks. Teams on 2.13 should move to v2.13.6, those on 2.14 to v2.14.5, those on 2.15 to v2.15.3, and those on 2.16 to v2.16.0. OX lists Harbor 1.7.0 and later as affected.
Leaders can put five questions to their teams. Which Harbor version do we run, and is it on a fixed line? Is self-registration on, and who outside vetted staff can create projects? What can Harbor's cloud role reach, and does it need that much? Can we block the job service from calling internal and metadata addresses at the network layer? Have we checked webhook settings and task logs for addresses that point inward?
If a suspicious webhook turns up, treat the instance's cloud credentials as exposed and rotate them.
The lesson is about trust. A registry is trusted to hold images. In practice it also holds a cloud identity. Anyone who can make it send a request borrows that trust.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OX Security.
