CVE-2026-59891Critical· 9.6▾ AbyssalPoC availableCredential confusion in @sigstore/oci can leak registry credentials to an attacker-controlled registry
▾ Abyssal zone — Critical with a public exploit or in-the-wild use
impact 52.8 · likelihood 0.1 · exploitation 12
A public proof-of-concept already exists for this vulnerability — see Exploit availability below.
Public exploit / PoC code seen in 1 source. Availability, not in-the-wild use.
Exploit-prediction probability, daily snapshots since Jul 21.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.5%
1 GitHub repo
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:
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.
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.
<= 0.7.0 (all releases from 0.1.0).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.
@sigstore/oci (or the subject-name of actions/attest* when push-to-registry: true).@sigstore/oci < 0.7.1Upgrade to a patched release:
@sigstore/oci 0.7.1Field changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2021-30116Critical· 10.0Kaseya VSA before 9.5.7 allows credential disclosure, as exploited in the wild in July 2021
CVE-2020-5404Medium· 5.9The HttpClient from Reactor Netty, versions 0.9.x prior to 0.9.5, and versions 0.8.x prior to 0.8.16, may be used incorrectly, leading to a credentials leak during a redirect to a different domain
CVE-2019-11284High· 8.6Pivotal Reactor Netty, versions prior to 0.8.11, passes headers through redirects, including authorization ones
CVE-2026-48816Medium· 6.5sigstore-js has Insufficient Verification of Data Authenticity
CVE-2026-48758Medium· 5.4@sigstore/core has DSSE payloadType type-binding failure
CVE-2026-91982Medium· 4.3Vikunja before 2.6.0 continues to expose the raw TOTP shared secret after enrollment through the GET /api/v1/user/settings/totp and /api/v1/user/settings/totp/qrcode endpoints without re-authentication