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

### 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