## 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`)
## 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`)
Update oras.land/oras-go/v2 to 2.6.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanoras-go blob upload vulnerable to credential forwarding via unvalidated Location header affects oras.land/oras-go/v2 (go). Severity is high. ## 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`)
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| oras.land/oras-go/v2go | <2.6.1 | 2.6.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate oras.land/oras-go/v2 to 2.6.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanoras-go blob upload vulnerable to credential forwarding via unvalidated Location header affects oras.land/oras-go/v2 (go). Severity is high. ## 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`)
AI coding agents often install or upgrade packages automatically in go. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| oras.land/oras-go/v2go | <2.6.1 | 2.6.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard