CVE-2026-118763
HighCVSS 7.4Exploitation Probability (EPSS)
Low risk23th percentile - higher than 23% of all known CVEs
Summary
In sigstore-js 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. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin.
Risk Assessment
A malicious or compromised registry could steal user credentials, enabling unauthorized registry access and upload of malicious artifacts. The risk concerns supply chain integrity of images and artifacts.
Recommendation
Upgrade sigstore-js to version 0.7.2 and review registry configurations for trusted artifact sources.
Other vulnerabilities in sigstore-js
See all- CVE-2026-59891Critical
In sigstore-js prior to version 0.7.1, getRegistryCredentials() reads credentials from the Docker config file and selects an entry by checking whether any configured auth key contains the target registry string. Because this is a substring match rather than an exact host match, credentials configured for one registry can be selected for and transmitted to a different registry whose hostname has a substring relationship with a configured auth key.
- CVE-2026-48816Medium
A vulnerability in sigstore-js (versions prior to 3.1.1) allows an attacker to manipulate the transparency-log timestamp for inclusionProof-only entries in v0.2 bundles. Since the inclusion proof path does not cryptographically bind the timestamp, an attacker can influence certificate validity and timestamp threshold verification decisions.
- CVE-2026-48815High
In sigstore-js before version 4.1.1, the documented certificateOIDs option in sigstore.verify() is accepted by the public API but discarded before verification. This means required certificate extension OIDs are never checked, and applications relying on certificateOIDs to restrict which certificates may sign artifacts can accept unauthorized certificates.
- CVE-2026-48758Medium
A vulnerability in sigstore-js (versions prior to 3.2.1) allows mutation of the payload type after signing without invalidating the signature, breaking the type-binding guarantee of DSSE. The preAuthEncoding function uses Node.js ASCII encoding, enabling manipulation of the payloadType field.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS