CVE-2026-50151
ADVISORY - githubSummary
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.
unzip -q -o poc.zip -d /tmp/poc
cd /tmp/poc/poc-F-ORAS-LOCATION-UPLOAD-001
make canonical
make control
Recommended Fix
- validate
Locationbefore uploading (scheme + hostname + effective port) against the original request, or require an explicit opt-in allowlist for cross-host upload urls - never forward
Authorizationwhen 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(seeblobStore.completePushAfterInitialPost)
Common Weakness Enumeration (CWE)
Server-Side Request Forgery (SSRF)
Sign in to Docker Scout
See which of your images are affected by this CVE and how to fix them by signing into Docker Scout.
Sign in