Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Checkout DevGuardView on GitHub
Search

GHSA-pf56-329r-95rw

CriticalCVSS 9.6 / 10
Published Jul 21, 2026·Last modified Jul 21, 2026
Affected Components(0)

No affected components available

Description

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.
Risk Scores
Base Score
9.6

The vulnerability can be exploited over the network without needing physical access. It is easy for an attacker to exploit this vulnerability. An attacker does not need any special privileges or access rights. The attacker needs the user to perform some action, like clicking a link. The vulnerability can affect other systems as well, not just the initial system. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data. There is a high impact on the availability of the system.

Threat Intelligence
8.8

Exploitation activity has been observed. Apply available patches or mitigations urgently.

EPSS
0.32%

The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

Critical severity
Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard