GHSA-pf56-329r-95rw

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:

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/oci@0.7.1. 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.