GHSA-pf56-329r-95rw is a critical-severity (CVSS 9.6) CWE-522 vulnerability in @sigstore/oci. O3 Security confirms whether GHSA-pf56-329r-95rw is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Credential confusion in @sigstore/oci can leak registry credentials to an attacker-controlled registry
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-pf56-329r-95rw.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-pf56-329r-95rw plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 367,996 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@sigstore/ocinpmDescription
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/[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 from0.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 thesubject-nameofactions/attest*whenpush-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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @sigstore/oci | all versions | 0.7.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @sigstore/oci. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @sigstore/oci to 0.7.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pf56-329r-95rw is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-pf56-329r-95rw is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-pf56-329r-95rw. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pf56-329r-95rw in your dependencies?
O3 detects GHSA-pf56-329r-95rw across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.