Summary
A credential exposure vulnerability in sigstore-js allows a malicious or compromised OCI registry to redirect artifact-upload requests to an attacker-controlled host while registry authentication headers remain attached.
An attacker who controls the upload destination may capture bearer tokens, Basic credentials, or custom authentication headers when a user pushes an artifact through the affected OCI client.
A credential exposure vulnerability in sigstore-js allows a malicious or compromised OCI registry to redirect artifact-upload requests to an attacker-controlled host while registry authentication headers remain attached.
An attacker who controls the upload destination may capture bearer tokens, Basic credentials, or custom authentication headers when a user pushes an artifact through the affected OCI client.
Affected context
The issue occurs in the sigstore-js OCI registry client when registry credentials are stored as shared HTTP-client defaults and an upload location is accepted from the registry without validating its origin or scheme. It is most relevant when a user interacts with a malicious or compromised registry and the client follows an artifact upload workflow that sends a PUT request to the supplied absolute location.
The issue occurs in the sigstore-js OCI registry client when registry credentials are stored as shared HTTP-client defaults and an upload location is accepted from the registry without validating its origin or scheme. It is most relevant when a user interacts with a malicious or compromised registry and the client follows an artifact upload workflow that sends a PUT request to the supplied absolute location.
Exploit preconditions
- Attack surface: OCI artifact upload functionality in the sigstore-js registry client
- Required access: The attacker must control or compromise the registry, or influence the upload location it returns
- Trigger point: Blob upload during an artifact attachment or image-push operation
- Credential availability: The client must have registry bearer tokens, Basic credentials, or custom authentication headers
- Why exploitation is possible: The client sends a new request to the registry-provided absolute location without confirming that its origin and scheme match the intended registry, while shared client defaults can carry authentication headers to that destination
- Attack surface: OCI artifact upload functionality in the sigstore-js registry client
- Required access: The attacker must control or compromise the registry, or influence the upload location it returns
- Trigger point: Blob upload during an artifact attachment or image-push operation
- Credential availability: The client must have registry bearer tokens, Basic credentials, or custom authentication headers
- Why exploitation is possible: The client sends a new request to the registry-provided absolute location without confirming that its origin and scheme match the intended registry, while shared client defaults can carry authentication headers to that destination
Why this happens
The underlying bug combines overly broad credential scope with insufficient destination validation. Authentication headers are placed on a shared HTTP client rather than being associated with a specific trusted registry origin, and an upload URL supplied by the registry is treated as an acceptable destination without enforcing origin or scheme constraints.
This maps to CWE-522: Insufficiently Protected Credentials, because sensitive authentication material can be transmitted to an unintended host. Redirect handling does not address the issue because the cross-host upload is an explicitly constructed request rather than a browser-style redirect followed by the HTTP client.
The underlying bug combines overly broad credential scope with insufficient destination validation. Authentication headers are placed on a shared HTTP client rather than being associated with a specific trusted registry origin, and an upload URL supplied by the registry is treated as an acceptable destination without enforcing origin or scheme constraints.
This maps to CWE-522: Insufficiently Protected Credentials, because sensitive authentication material can be transmitted to an unintended host. Redirect handling does not address the issue because the cross-host upload is an explicitly constructed request rather than a browser-style redirect followed by the HTTP client.
Potential impact
- An attacker may capture registry bearer tokens
- Basic authentication credentials could be disclosed
- Custom authentication headers may be exposed
- Stolen credentials could enable unauthorized registry access
- Attackers could alter, delete, or replace artifacts permitted by the captured credentials
- Compromised credentials could support supply-chain tampering or lateral access to related systems
- An attacker may capture registry bearer tokens
- Basic authentication credentials could be disclosed
- Custom authentication headers may be exposed
- Stolen credentials could enable unauthorized registry access
- Attackers could alter, delete, or replace artifacts permitted by the captured credentials
- Compromised credentials could support supply-chain tampering or lateral access to related systems
General mitigation guidance
Mitigation generally focuses on binding credentials to the intended registry origin and reducing the scope of authentication state.
Common defensive patterns include:
- Keep registry credentials separate from client-wide request defaults
- Attach authentication headers only when the destination matches the configured registry origin
- Permit upload locations only when their scheme and authority satisfy an explicit allowlist or trusted-origin policy
- Reject unexpected cross-origin or insecure-scheme upload targets by default
- Minimize credential lifetime, scope, and repository permissions
- Avoid forwarding custom authentication headers across origin boundaries
- Use isolated clients or request contexts for different registries
Mitigation generally focuses on binding credentials to the intended registry origin and reducing the scope of authentication state.
Common defensive patterns include:
- Keep registry credentials separate from client-wide request defaults
- Attach authentication headers only when the destination matches the configured registry origin
- Permit upload locations only when their scheme and authority satisfy an explicit allowlist or trusted-origin policy
- Reject unexpected cross-origin or insecure-scheme upload targets by default
- Minimize credential lifetime, scope, and repository permissions
- Avoid forwarding custom authentication headers across origin boundaries
- Use isolated clients or request contexts for different registries
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules that identify credentials stored as global or shared HTTP-client defaults
- Code review checks for requests built from server-supplied absolute URLs
- Tests asserting that authentication headers are absent from cross-origin requests
- Policy checks requiring destination-origin and scheme validation before credentialed uploads
- Instrumentation that records credentialed requests and flags unexpected hosts without logging secret values
- Automated security review tools that trace sensitive headers from credential setup to request dispatch
Organizations can look for this class of issue through:
- Static analysis rules that identify credentials stored as global or shared HTTP-client defaults
- Code review checks for requests built from server-supplied absolute URLs
- Tests asserting that authentication headers are absent from cross-origin requests
- Policy checks requiring destination-origin and scheme validation before credentialed uploads
- Instrumentation that records credentialed requests and flags unexpected hosts without logging secret values
- Automated security review tools that trace sensitive headers from credential setup to request dispatch
