CVE-2026-50151: oras-go: credential forwarding via unvalidated Location header in blob upload
Summary
oras-go follows a registry-controlled Location header during the monolithic blob upload flow 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 send the caller's credentials to an attacker-controlled endpoint.
Affected Versions
tested: v2.6.0 (commit 03243809936cce826494b5506f724c6dc11115b1, as-of 2026-01-24) range: unknown; likely affects earlier v2.x releases that include the same upload flow
Impact
Credential leak to an attacker-controlled endpoint and client-side ssrf to a cross-host target.
Affected Component
- registry/remote/repository.go:878-916 (blobStore.completePushAfterInitialPost)
Reproduction
Attachments include poc.zip with a local-only harness (no real registry required). It runs a fake registry server that returns a cross-host Location and a second server that records whether it received Authorization.
bash unzip -q -o poc.zip -d /tmp/poc cd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001 make canonical make control
Recommended Fix
- validate Location before uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls - never forward Authorization when the upload target changes host or scheme
references
- security policy: https://github.com/oras-project/oras-go/security/policy - vulnerable code: registry/remote/repository.go (see blobStore.completePushAfterInitialPost)
Other sources
oras-go is a Go library for managing OCI artifacts. Prior to 2.6.1, registry/remote/repository.go in blobStore.completePushAfterInitialPost follows a registry-controlled Location header during monolithic blob upload and reuses the Authorization header from the initial POST request for the subsequent PUT request, allowing a malicious registry to return a cross-host Location and receive the caller's credentials at an attacker-controlled endpoint. This issue is fixed in version 2.6.1.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/oras.land/oras-go/v2to a version that resolves this vulnerability.Fixed in 2.6.1 - Upgrade
Upgrade
oras-goto a version that resolves this vulnerability.Fixed in 2.6.1 - Configuration
In blobStore.completePushAfterInitialPost, never forward the `Authorization` header when the upload target changes host or scheme; validate the returned `Location` before uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload URLs.
oras-go (registry/remote/repository.go blobStore.completePushAfterInitialPost) Authorization forwarding on cross-host Location = never
Event History
Frequently Asked Questions
What is the severity of CVE-2026-50151?
CVE-2026-50151 has a high severity score of 7.5.
What are the potential risks associated with CVE-2026-50151?
CVE-2026-50151 allows for unauthorized access due to SSRF, potentially allowing attackers to send unauthorized requests.
How do I fix CVE-2026-50151?
To remediate CVE-2026-50151, update to the latest version of oras-go that includes the patch provided for this vulnerability.
What is the nature of the vulnerability in CVE-2026-50151?
CVE-2026-50151 is an SSRF vulnerability that can be exploited through controlled `Location` headers during blob uploads.
Which software is affected by CVE-2026-50151?
The vulnerability affects the oras-go software, specifically versions prior to the fix implemented in the latest updates.