Summary
A server-side request forgery flaw in the oras-go OCI client allows a registry to redirect blob upload traffic to an attacker-controlled host while reusing the caller's Authorization header.
When a client performs monolithic blob uploads against a malicious or compromised registry, the registry's Location header can cause oras-go to send credentials to a different endpoint, exposing sensitive tokens or passwords.
A server-side request forgery flaw in the oras-go OCI client allows a registry to redirect blob upload traffic to an attacker-controlled host while reusing the caller's Authorization header.
When a client performs monolithic blob uploads against a malicious or compromised registry, the registry's Location header can cause oras-go to send credentials to a different endpoint, exposing sensitive tokens or passwords.
Affected context
This vulnerability appears in Go applications that embed oras-go as an OCI artifact client and perform monolithic blob uploads against remote registries.
It becomes relevant when the target registry is untrusted, misconfigured, or compromised, and the client treats the registry's Location header as trustworthy.
The issue manifests specifically when oras-go follows cross-host redirects during upload and automatically carries forward authentication headers.
This vulnerability appears in Go applications that embed oras-go as an OCI artifact client and perform monolithic blob uploads against remote registries.
It becomes relevant when the target registry is untrusted, misconfigured, or compromised, and the client treats the registry's Location header as trustworthy.
The issue manifests specifically when oras-go follows cross-host redirects during upload and automatically carries forward authentication headers.
Exploit preconditions
- Attack surface: Outbound HTTP(S) requests from oras-go clients to OCI registries during blob upload operations
- Required access: Ability to control or influence the registry endpoint used by the client (e.g., malicious registry, compromised registry, or poisoned configuration)
- Trigger point: Monolithic blob upload where the registry responds with a Location header pointing to a different host, prompting oras-go to issue a follow-up PUT request
- Why exploitation is possible: The client code implicitly trusts the registry-supplied Location header and reuses Authorization headers across host boundaries, allowing credential forwarding to attacker-controlled endpoints
- Attack surface: Outbound HTTP(S) requests from oras-go clients to OCI registries during blob upload operations
- Required access: Ability to control or influence the registry endpoint used by the client (e.g., malicious registry, compromised registry, or poisoned configuration)
- Trigger point: Monolithic blob upload where the registry responds with a Location header pointing to a different host, prompting oras-go to issue a follow-up PUT request
- Why exploitation is possible: The client code implicitly trusts the registry-supplied Location header and reuses Authorization headers across host boundaries, allowing credential forwarding to attacker-controlled endpoints
Why this happens
The underlying flaw is a trust violation in HTTP redirect handling and header propagation logic within the oras-go client.
The implementation of blobStore.completePushAfterInitialPost treats the registry's Location header as authoritative, constructing a subsequent PUT request to whatever host is specified without validating that it matches the original registry domain.
At the same time, the client blindly reuses the Authorization header from the initial POST, effectively leaking credentials to any host that the registry directs the client to.
This maps to CWE-918 (Server-Side Request Forgery), where server-side logic sends requests to unintended locations under attacker influence, in this case amplifying the risk via credential reuse.
The underlying flaw is a trust violation in HTTP redirect handling and header propagation logic within the oras-go client.
The implementation of blobStore.completePushAfterInitialPost treats the registry's Location header as authoritative, constructing a subsequent PUT request to whatever host is specified without validating that it matches the original registry domain.
At the same time, the client blindly reuses the Authorization header from the initial POST, effectively leaking credentials to any host that the registry directs the client to.
This maps to CWE-918 (Server-Side Request Forgery), where server-side logic sends requests to unintended locations under attacker influence, in this case amplifying the risk via credential reuse.
Potential impact
- Credentials (tokens, passwords, or API keys) used for registry authentication may be sent to attacker-controlled endpoints
- An attacker could harvest long-lived access tokens and perform unauthorized operations against legitimate registries or related services
- Compromise of CI/CD pipelines or artifact publishing workflows that rely on oras-go for OCI interactions
- Escalation of access within cloud or container infrastructure if registry credentials are broadly privileged
- Credentials (tokens, passwords, or API keys) used for registry authentication may be sent to attacker-controlled endpoints
- An attacker could harvest long-lived access tokens and perform unauthorized operations against legitimate registries or related services
- Compromise of CI/CD pipelines or artifact publishing workflows that rely on oras-go for OCI interactions
- Escalation of access within cloud or container infrastructure if registry credentials are broadly privileged
General mitigation guidance
Effective mitigation focuses on reducing trust in remote-controlled redirection and limiting credential propagation.
Common patterns include:
- Validating redirect destinations against an allowlist of expected hosts or enforcing same-host policies for follow-up requests
- Avoiding automatic reuse of Authorization headers across host or scheme changes, and scoping credentials tightly to specific domains
- Designing HTTP client wrappers that explicitly separate authentication concerns from redirect handling logic
- Using least-privilege tokens for registry access so that any accidental exposure has minimal blast radius
- Applying configuration controls that restrict interaction with untrusted registries or require explicit approval for new endpoints
Effective mitigation focuses on reducing trust in remote-controlled redirection and limiting credential propagation.
Common patterns include:
- Validating redirect destinations against an allowlist of expected hosts or enforcing same-host policies for follow-up requests
- Avoiding automatic reuse of Authorization headers across host or scheme changes, and scoping credentials tightly to specific domains
- Designing HTTP client wrappers that explicitly separate authentication concerns from redirect handling logic
- Using least-privilege tokens for registry access so that any accidental exposure has minimal blast radius
- Applying configuration controls that restrict interaction with untrusted registries or require explicit approval for new endpoints
How teams detect issues like this
Organizations can detect similar SSRF and credential forwarding issues through:
- Static analysis rules that flag HTTP client code reusing Authorization headers after host changes or unvalidated redirects
- Code reviews focused on redirect handling logic, looking for unchecked use of Location headers and implicit trust in server-controlled URLs
- Security policies requiring explicit host validation and credential scoping in network client abstractions
- Runtime monitoring and logging of outbound requests from build agents or artifact publishers, alerting on unexpected destinations or unusual registry domains
Organizations can detect similar SSRF and credential forwarding issues through:
- Static analysis rules that flag HTTP client code reusing Authorization headers after host changes or unvalidated redirects
- Code reviews focused on redirect handling logic, looking for unchecked use of Location headers and implicit trust in server-controlled URLs
- Security policies requiring explicit host validation and credential scoping in network client abstractions
- Runtime monitoring and logging of outbound requests from build agents or artifact publishers, alerting on unexpected destinations or unusual registry domains
