@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 0.7.2
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
The @sigstore/oci JavaScript library, part of the sigstore-js project, is affected when it pushes artifacts to a container registry. A malicious or compromised registry can redirect the upload to an attacker-controlled host, which can then receive the user's registry bearer token, Basic credentials, or other authentication headers.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- sigstore sigstore-js
fixed in 0.7.2
- @sigstore/ocinpm
fixed in 0.7.2
References 5
GitHub · sigstore/sigstore-js
Questions about CVE-2026-118763
What does this mean?
When pushing a signed artifact or attestation with attachArtifactToImage(), @sigstore/oci can send the registry's Authorization header to a different host named in the upload Location returned by the registry. That host could receive a bearer token or a Basic username and password, or other custom authentication headers.Source: github.com
Am I affected, and how do I check?
The package @sigstore/oci is affected in all versions before 0.7.2, and sigstore-js is affected before 0.7.2. The issue needs a registry that is malicious or compromised and returns a cross-host blob-upload Location, so check the installed @sigstore/oci version in your project's lockfile or with npm ls @sigstore/oci.Source: github.com
What should I do about it?
Upgrade @sigstore/oci to 0.7.2 or later, and sigstore-js to 0.7.2 or later. The fixed version is the one listed in the affected ranges.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data