If self-registration is enabled on a vulnerable Harbor instance, any internet user can create an account and immediately pivot to attacking the underlying cloud infrastructure provider. This critical security oversight centers on a Server-Side Request Forgery (SSRF) vulnerability, identified as GHSA-2phj-cp9f-qq6w, which transforms a standard container registry feature into a conduit for unauthorized cloud access. Harbor, a widely utilized Cloud Native Computing Foundation project, serves as a central hub for managing container images across various environments. Because it often possesses high-level permissions to interact with storage buckets and orchestration platforms, any compromise of its host identity carries significant weight. Security researchers identified that the platform’s webhook system lacked sufficient validation, allowing users to redirect internal requests toward sensitive cloud metadata services. This flaw effectively permits an attacker to assume the role of the Harbor server itself, bypassing traditional network perimeters that usually guard internal resources.
1. Analyzing the Foundation: Why Harbor is a High-Value Target
Harbor functions as a vital component in modern software supply chains, often sitting at the intersection of development pipelines and production environments. It handles sensitive container images that frequently contain proprietary logic and internal configurations. Because Harbor is often deployed within cloud environments, it is typically granted an IAM role that allows it to interact with essential services like storage buckets or the Kubernetes API. This central position makes it an exceptionally high-value target for attackers. If the registry’s identity is compromised, the security boundaries between different projects and the underlying cloud infrastructure begin to dissolve. Security researchers discovered that the platform’s webhook functionality, intended to notify external systems of registry events, could be manipulated to target internal endpoints. This flaw allows an attacker to bypass the network isolation that typically protects cloud metadata services, which are otherwise unreachable from the public internet.
The technical core of this vulnerability lies in the way the application validates the destination of its outbound webhook requests. In cloud-native architectures, the Instance Metadata Service (IMDS) is a well-known target because it provides temporary security credentials to the host. Harbor’s failure to restrict webhook targets to public IP addresses or approved domains means that any user with enough permission to create a project can point a webhook at the IMDS address. When a routine event occurs, such as an image push, the Harbor server sends a request to its own internal metadata service, effectively fetching its own secret credentials and handing them to the user. This vulnerability is especially dangerous because it does not require administrative access to the entire Harbor instance; it only requires project-level permissions, which are automatically granted to any user who creates a project. This low barrier to entry makes the flaw a potent threat to organizations that allow self-registration or have many internal users.
2. Exploitation Mechanics: Navigating from Registration to Execution
The exploitation cycle begins with obtaining a foothold on the Harbor platform. If self-registration is active, an attacker simply creates a new account. Once inside, they create a new project, which automatically elevates them to the role of ProjectAdmin for that specific workspace. As a project administrator, the user has the authority to configure webhooks, which are intended for integration with external notification systems. The attacker enters the internal cloud metadata URL, such as the standard 169.254.169.254 address, as the target for the webhook. Surprisingly, the Harbor backend accepts this private IP address without returning an error, instead providing an HTTP 201 status that confirms the webhook policy has been successfully created and stored. This acceptance is the critical failure point, as it indicates a total lack of IP range validation. At this stage, the trap is set, and the attacker merely needs to wait for the registry to perform a routine action that triggers the notification.
To complete the attack, the user triggers a project event, most commonly by pushing a new container image to the repository. The Harbor job service then processes the event and attempts to deliver the webhook to the previously configured address. Because the request is generated from within the Harbor instance, it successfully reaches the cloud metadata service, which then responds with the temporary IAM credentials associated with the server’s role. These credentials, typically including the AccessKeyId and SessionToken, are then captured by the attacker. In many instances, the Harbor job service even logs the full response of the webhook, meaning the sensitive credentials appear directly in the project’s task logs. The attacker can then extract these secrets and use them to authenticate with the cloud provider’s API from any external machine. This allows them to manipulate cloud resources, access private data storage, or even pivot deeper into the organization’s cloud environment with the identity of the Harbor server.
3. Strategic Remediation: Securing Cloud Identities and Infrastructure
Addressing this vulnerability requires a combination of software updates and architectural hardening to protect the container registry and its host environment. The primary defense is to upgrade Harbor to versions v2.13.6, v2.14.5, v2.15.3, or v2.16.0, which implement stricter validation checks for webhook targets to prevent internal IP addressing. Additionally, organizations should re-evaluate their use of public self-registration. By restricting account creation to verified users through external identity providers, the pool of potential attackers is significantly reduced. Administrators should also implement network-level controls, such as egress filtering, to block the Harbor server from reaching the IMDS IP address. Using modern metadata protection features like IMDSv2, which requires a session token and prevents most SSRF-based exfiltration, adds another critical layer of security. These measures ensure that even if a similar vulnerability were discovered in the future, the blast radius would be contained and the server’s credentials would remain safe.
Security teams throughout 2026 responded to these findings by performing comprehensive audits of their registry logs and rotating all cloud credentials that might have been exposed. They recognized that the impact of the SSRF extended beyond the registry itself, as stolen IAM tokens could have provided access to shared storage and orchestration APIs. Consequently, these organizations implemented stricter IAM policies based on the principle of least privilege, ensuring that their Harbor instances only possessed the exact permissions required for image management. They also integrated automated scanning tools to detect unauthorized webhook configurations and alerted on any requests directed toward internal network ranges. By shifting toward a zero-trust model for internal service communication, they mitigated the risks associated with multi-tenant registry deployments. These proactive steps transformed the incident into a catalyst for better cloud security practices, ensuring that the software supply chain was hardened against similar exploitation vectors in the future.
WordsCharactersReading time
