Listen to this Post
oras-go implements the OCI distribution-spec monolithic blob upload flow, which consists of two sequential HTTP requests: an initial `POST` to initiate the upload, and a subsequent `PUT` to the `Location` URL returned by the registry to complete the upload. During this flow, the library reuses the `Authorization` header from the initial `POST` request for the follow-up `PUT` request without validating the target URL.
The vulnerability arises because the `Location` header is fully controlled by the registry response. A malicious registry can return a cross-origin `Location` URL pointing to an attacker-controlled endpoint. When oras-go issues the `PUT` request to this attacker-supplied URL, it blindly forwards the caller’s `Authorization` credentials. This allows an attacker to capture sensitive bearer tokens or basic authentication credentials that were originally intended only for the legitimate registry.
The flawed logic resides in `blobStore.completePushAfterInitialPost` within `registry/remote/repository.go` at lines 878–916. The library does not validate the scheme, hostname, or port of the `Location` header against the original request’s target. As a result, an attacker who controls a registry (or can MITM the registry response) can redirect the upload to any cross-host destination while retaining the victim’s credentials.
This issue has two primary consequences: (1) credential exfiltration – the attacker receives the `Authorization` header and can reuse it to impersonate the victim against other services; (2) client-side SSRF – the attacker can coerce the oras-go client to send authenticated `PUT` requests to arbitrary internal or external endpoints, potentially exposing internal services.
The vulnerability affects all v2.x releases prior to v2.6.1, including v2.6.0 (commit 03243809936cce826494b5506f724c6dc11115b1, as of 2026-01-24). The fix, released in v2.6.1, validates the `Location` header by comparing scheme, hostname, and effective port against the original request, and never forwards `Authorization` when the upload target changes host or scheme.
DailyCVE Form:
Platform: `oras.land/oras-go/v2`
Version: `< 2.6.1`
Vulnerability: Credential forwarding via unvalidated Location header
Severity: High (CVSS 7.5)
Date: 2026-07-01
Prediction: Patch available in v2.6.1 (2026-07-01)
What Undercode Say:
- Affected Versions: v2.0.0 through v2.6.0 inclusive
- Fixed Version: v2.6.1
- Dependent Packages: 327 packages rely on oras-go/v2
- Dependent Repositories: 185 repositories
- Attack Vector: Network (registry-controlled `Location` header)
- Confidentiality Impact: High (credential leak)
Exploit:
The provided proof-of-concept demonstrates the attack using a local harness:
Extract the PoC archive unzip -q -o poc.zip -d /tmp/poc Navigate to the PoC directory cd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001 Run the fake registry that returns a cross-host Location make canonical Run the second server that records received Authorization headers make control
The fake registry responds to the initial `POST` with a `Location` header pointing to the attacker’s second server. When oras-go issues the `PUT` request to that cross-host URL, the second server logs the forwarded `Authorization` header, demonstrating successful credential exfiltration.
Protection:
- Upgrade to oras-go v2.6.1 or later immediately.
- If upgrading is not possible, validate the `Location` header before the `PUT` request by enforcing that the scheme, hostname, and effective port match the original registry URL.
- Never forward the `Authorization` header when the upload target changes host or scheme.
- Consider implementing an explicit opt-in allowlist for cross-host upload URLs if cross-origin uploads are required.
Impact:
- Credential Leak: An attacker-controlled registry can capture the victim’s `Authorization` header (bearer token or basic auth) and reuse it to impersonate the victim against other services.
- Client-Side SSRF: The attacker can force the oras-go client to send authenticated `PUT` requests to arbitrary internal or external endpoints, potentially exposing internal services or causing unintended side effects.
- Supply Chain Risk: Any application that uses oras-go to push blobs to a registry is vulnerable if the registry is malicious or compromised. This includes CI/CD pipelines, container image builders, and artifact management tools.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
