CVE-2026-118763 in sigstore-js
Summary
by MITRE • 10/29/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in sigstore-js versions prior to 0.7.2 represents a critical authentication credential leakage flaw within the JavaScript libraries designed for interacting with Sigstore services. The core of this issue resides in the implementation details of the RegistryClient class, specifically involving how HTTP client instances are configured and utilized during artifact upload operations. When a user initiates an operation such as attachArtifactToImage(), the library employs a shared HTTP client that has been pre-configured with default headers derived from registry authentication mechanisms. These defaults include sensitive Authorization tokens, Docker configuration credentials, and other custom authentication headers necessary for legitimate interaction with trusted registries. The flaw emerges because these credentials are applied globally to the client instance rather than being scoped strictly to specific origins or endpoints during individual request execution.
The technical mechanism of exploitation relies on the behavior of the RegistryClient.uploadBlob() method when handling blob-upload locations provided by the registry itself. Upon receiving a response from an initial interaction with a registry, the library may obtain an absolute URL for uploading blobs. In this version, the client sends a fresh PUT request to this supplied location without performing any validation checks on the origin or scheme of the target host relative to the original registry. This design choice assumes that all URLs provided by a trusted registry are safe destinations for credential transmission. However, because cross-host PUT requests constitute new explicit HTTP transactions rather than simple redirects followed by the browser or standard client logic, they bypass typical redirect-time header stripping protections. Consequently, if an attacker controls or compromises a malicious registry, they can manipulate the upload location response to point toward a server under their control.
The operational impact of this vulnerability is severe, as it enables unauthorized access to sensitive authentication materials. A malicious actor operating such a compromised endpoint would receive the full suite of credentials associated with the user's Sigstore session or Docker configuration upon attempting an artifact push. This includes bearer tokens that grant elevated privileges within registry ecosystems, Basic authentication headers containing usernames and passwords, and any other custom security headers configured by the organization. The leakage of these credentials allows for potential account takeover, unauthorized modification of container images or software artifacts stored in registries, and further lateral movement within infrastructure where those credentials are reused. This scenario aligns with CWE-200, which classifies exposure of sensitive information to an unauthorized actor, as well as ATT&CK technique T1539, specifically highlighting the theft of web session cookies or authentication tokens through insecure transmission practices.
This issue is a residual effect stemming from CVE-2026-59891, where previous remediation efforts addressed credential selection logic within credentials.ts but failed to constrain the actual destination of those credentials in registry.ts. The fix implemented in version 0.7.2 resolves this architectural gap by decoupling registry-specific credentials from client-wide default configurations. By ensuring that authentication headers are only attached to requests directed at the specific origin of the trusted registry, the library prevents credential leakage even if a malicious endpoint is provided via API responses. Organizations relying on sigstore-js for supply chain security must upgrade immediately to version 0.7.2 or later to mitigate this risk. Additionally, developers should audit their CI/CD pipelines and deployment scripts to ensure that no older versions of the library are inadvertently utilized in production environments where sensitive artifacts are managed.