Understanding the oras-go Credential Forwarding Vulnerability via Unvalidated Location Header

Overview

The oras-go library, used for interacting with OCI registries, is susceptible to a critical vulnerability that could lead to credential leakage and unauthorized access. This issue arises from the library's handling of the Location header during the blob upload process. Specifically, oras-go follows a registry-controlled Location header and reuses the Authorization header from the initial POST request for the subsequent PUT request. If a malicious registry returns a cross-host Location, oras-go can inadvertently send the caller's credentials to an attacker-controlled endpoint.

Understanding the Vulnerability / Threat

Root Cause Analysis

The root cause of this vulnerability lies in the way oras-go handles the Location header during the monolithic blob upload flow. The library fails to validate the scheme, hostname, and effective port of the Location header against the original request. This oversight allows an attacker to manipulate the Location header and potentially leak credentials to an attacker-controlled endpoint. This vulnerability can be classified under CWE-918, Server-Side Request Forgery (SSRF), as it enables an attacker to trick the server into making unintended requests.

Attack Surface & Vector

The attack surface for this vulnerability involves the blob upload process in oras-go. An attacker can exploit this vulnerability by controlling a malicious registry that returns a cross-host Location header. The vector of attack involves the client (using oras-go) making an initial POST request to the registry, which then responds with a Location header pointing to an attacker-controlled endpoint. The oras-go client, not validating the Location header, will then make a PUT request to this endpoint, potentially leaking credentials.

Exploitation Mechanics — Scenario Walkthrough

Scenario: Compromising a Corporate oras-go Instance 1. Initial Position: An attacker controls a malicious registry and targets a corporate environment that uses oras-go (version < 2.6.1) to interact with registries. 2. Triggering the Flaw: The attacker, through their controlled registry, responds to an initial POST request from the corporate oras-go client with a Location header pointing to an attacker-controlled endpoint. This Location header is crafted to have a different hostname or scheme than the original request. 3. What Breaks: The oras-go client, not validating the Location header, proceeds to make a PUT request to the attacker-controlled endpoint. In this request, it inadvertently includes the Authorization header from the initial POST request. 4. Attacker's Prize: The attacker now has access to the credentials (contained in the Authorization header) that were meant for the registry. This could allow the attacker to perform unauthorized actions, such as data exfiltration or lateral movement within the corporate network.

Real-World Impact

The impact of this vulnerability is significant. An attacker could exploit it to gain unauthorized access to sensitive data or systems. The vulnerability could lead to credential leakage to an attacker-controlled endpoint and enable client-side SSRF to a cross-host target. Given that the oras-go library is used in various projects for interacting with OCI registries, the potential for widespread impact exists.

Detection & Defense

Immediate Mitigations

- Upgrade to oras-go version 2.6.1 or later. - Implement validation of the Location header against the original request (scheme + hostname + effective port). - Configure an explicit opt-in allowlist for cross-host upload URLs.

Detection Strategies

- Monitor for unusual requests to external endpoints, especially those that include Authorization headers. - Implement SIEM rules to detect and alert on potential credential leakage.

Long-Term Hardening

- Adopt a defense-in-depth approach by implementing strict validation of all registry responses. - Regularly review and update dependencies to ensure they are free from known vulnerabilities. - Enforce policies that restrict the forwarding of Authorization headers to untrusted or external endpoints.

Key Takeaways

- The oras-go library is vulnerable to credential forwarding due to an unvalidated Location header. - CVE-2026-50151 affects versions prior to 2.6.1. - Exploitation can lead to credential leakage and client-side SSRF. - Immediate mitigation includes upgrading to version 2.6.1 or later and implementing Location header validation. - Long-term hardening involves adopting a defense-in-depth approach and regularly reviewing dependencies.

Sources

- GitHub Security Advisories: https://github.com/advisories/GHSA-jxpm-75mh-9fp7 - CVE-2026-50151