Credential confusion in  @sigstore/oci  can leak registry credentials to an attacker-controlled registry

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

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.

Source published

14 Jul 2026 16:54:50 UTC

Source modified

21 Jul 2026 18:43:52 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 9.6 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

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.

Source published

14 Jul 2026 17:17:15 UTC

Source modified

24 Oct 2026 21:10:00 UTC

Observed here

25 Oct 2026 14:19:22 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 9.6 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

### Impact This is a credential-exposure / credential-confusion issue. `getRegistryCredentials()` reads credentials from the Docker config file (`~/.docker/config.json`) and selects an entry by checking whether any configured auth key **contains** the target registry string: ```js Object.keys(dockerConfig.auths || {}).find((key) => key.includes(registry)) ``` 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 (for example, an attacker-controlled `cr.io` matches a configured `ghcr.io`). **Who is impacted:** Any consumer of `@sigstore/oci` that uploads artifacts to an OCI registry using credentials from a Docker config, where the destination registry/image reference can be influenced by an untrusted party. This includes `@actions/attest` and the `actions/attest`, `actions/attest-build-provenance`, and `actions/attest-sbom` GitHub Actions when run with `push-to-registry: true`, where the `subject-name` input determines the destination registry. This is classified as a **critical** vulnerability given the potential, in a theoretical worst-case scenario, to expose long-lived registry credentials. However, in practice, exploitation requires all of the following: - The Docker config on the host contains credentials for a registry. - The destination registry/image reference is influenced by an untrusted source. - The attacker controls a registry whose hostname is a substring of (or is otherwise contained within) a configured Docker auth key. Under those conditions, registry credentials present on the host (e.g. a GHCR, Docker Hub, or cloud-registry token) can be sent to an attacker-controlled registry during the authentication exchange. ### Patches Fixed in **`@sigstore/[email protected]`**. Credential selection now requires an **exact host match**: both the target registry and each Docker auth key are canonicalized — stripping any `https?://` scheme and path and normalizing the Docker Hub aliases (`index.docker.io` / `registry-1.docker.io` / `docker.io`) — and compared for equality. When no exact match exists, credential lookup now fails rather than falling back to an unrelated credential. - **Affected versions:** `<= 0.7.0` (all releases from `0.1.0`). - **Patched version:** `0.7.1`. Downstream consumers should pick up the patched `@sigstore/oci`; subsequent releases of `@actions/attest` and the `actions/attest*` GitHub Actions will bundle the fix. ### Workarounds - Treat the destination registry/image reference as trusted input — do not allow untrusted sources to influence the registry/image reference passed to `@sigstore/oci` (or the `subject-name` of `actions/attest*` when `push-to-registry: true`). - Limit the credentials available in the host's Docker config to only those required for the operation, and avoid authenticating to registries whose hostnames have substring relationships with potential untrusted destinations. - Scope registry tokens narrowly and prefer short-lived credentials.

Source published

21 Jul 2026 19:34:05 UTC

Source modified

21 Jul 2026 19:45:24 UTC

Observed here

24 Oct 2026 13:17:17 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

Publisher rating · CRITICAL