What is the CVSS score of CVE-2026-59891?

CVE-2026-59891 has a CVSS 3.1 base score of 9.6 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of sigstore-js are affected by CVE-2026-59891?

A critical vulnerability in sigstore-js (@sigstore/oci) allows Docker registry credentials to be leaked to attackers who register registry domains similar to legitimate ones, threatening…. A patch is available.

How to fix or mitigate CVE-2026-59891?

Within 24 hours, identify all systems and build pipelines using @sigstore/oci and verify which versions are deployed by checking dependency lockfiles and package manifests for versions prior to 0.7.1. Within 7 days, upgrade all instances of @sigstore/oci to version 0.7.1 or later across development, CI/CD, staging, and production environments, validating the upgrade in a non-production environment first to ensure registry operations function correctly. Within 30 days, conduct a complete audit of Docker registry credentials used by systems that ran vulnerable versions and rotate any credentials that may have been exposed, prioritizing credentials with access to production or sensitive image repositories.

sigstore-js CVE-2026-59891

EUVD-2026-43960 CRITICAL

Insufficiently Protected Credentials (CWE-522)

2026-07-14 GitHub_M

GHSA-pf56-329r-95rw

Information Disclosure Docker Sigstore Sigstore Js

9.6

CVSS 3.1 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

9.6 CRITICAL

AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

vuln.today AI

5.3 MEDIUM

Network-delivered but needs a substring-colliding configured credential and victim action (AC:H, UI:R); primary impact is credential confidentiality only (C:H, I:N/A:N), no scope change on the vulnerable system.

3.1 AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N

4.0 AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch available

Jul 14, 2026 - 23:21 EUVD

Source Code Evidence Fetched

Jul 14, 2026 - 17:32 vuln.today

Analysis Generated

Jul 14, 2026 - 17:32 vuln.today

CVE Published

Jul 14, 2026 - 16:54 cve.org

CRITICAL 9.6

DescriptionCVE.org

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 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. This issue is fixed in version 0.7.1.

Articles & Coverage 1

News Critical Credential Leakage in Docker sigstore-js @sigstore/oci - CVE-2026-59891 Jul 15, 2026

AnalysisAI

Credential leakage in sigstore-js (specifically the @sigstore/oci package) before 0.7.1 allows Docker registry credentials to be transmitted to the wrong registry because getRegistryCredentials() matched configured auth keys against the target registry using a substring check instead of an exact host match. An attacker who can induce a victim to push or pull signatures/attestations against an attacker-named registry whose hostname has a substring relationship with a legitimately configured registry (e.g. 'cr.io' vs 'ghcr.io', or 'victim.127.0.0.1:5000' vs '127.0.0.1:5000') can capture the victim's stored registry credentials. There is no public exploit identified at time of analysis, and this is not listed in CISA KEV; the underlying weakness (CWE-522) is confirmed and fixed by the vendor in @sigstore/oci 0.7.1.

Technical ContextAI

The affected component is @sigstore/oci, part of the sigstore-js JavaScript libraries used to interact with Sigstore services and to push/pull signing artifacts to and from OCI (Open Container Initiative) registries. To authenticate to a registry, getRegistryCredentials() reads the local Docker config file (~/.docker/config.json) and picks an 'auths' entry. The root cause (CWE-522, Insufficiently Protected Credentials) is that credential selection used a substring/containment test: any configured auth key that merely contained the target registry string was treated as a match. Because registry hostnames frequently share substrings ('cr.io' is contained in 'ghcr.io'; a configured host can also be a substring of an attacker-chosen host like 'victim.127.0.0.1:5000'), the wrong credentials could be selected and sent over the network to an unintended registry. The fix replaces this with canonical exact host[:port] matching, adds a canonicalizeRegistry() helper that strips scheme/path, and normalizes Docker Hub aliases (docker.io, index.docker.io, registry-1.docker.io, https://index.docker.io/v1/) to a single canonical host. The only CPE provided is cpe:2.3:a:sigstore:sigstore-js:*:*:*:*:*:*:*:*.

RemediationAI

Vendor-released patch: upgrade @sigstore/oci to 0.7.1 or later, which replaces the substring credential match with exact canonical host[:port] matching; update your lockfiles and rebuild any tooling that pulls sigstore-js transitively. See the advisory GHSA-pf56-329r-95rw and the release at https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.1. If you cannot upgrade immediately, reduce exposure by ensuring the Docker config used by sigstore-js only contains credentials for registries you actually push/pull to, and remove or scope down any broadly-privileged registry tokens so a mis-selected credential is low-value; where feasible, run signing operations with a dedicated, minimal ~/.docker/config.json (or an isolated DOCKER_CONFIG directory) containing only the single registry credential needed for that job, and avoid pointing sigstore-js operations at untrusted or attacker-supplied registry hostnames. The trade-off of the isolated-config approach is added operational overhead per pipeline and the need to manage separate credential stores; it does not fully eliminate the substring flaw but shrinks the blast radius until 0.7.1 is deployed.