How severe is GHSA-xf85-363p-868w?

No CVSS score has been assigned to GHSA-xf85-363p-868w yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-xf85-363p-868w?

GHSA-xf85-363p-868w affects the following packages: oras.land/oras-go/v2 (Go), oras.land/oras-go (Go). Ecosystems affected: Go.

How do I fix GHSA-xf85-363p-868w?

Update oras.land/oras-go/v2 to 2.6.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xf85-363p-868w is resolved across your whole dependency graph.

How do I detect GHSA-xf85-363p-868w in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oras.land/oras-go/v2. 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.

How do I mitigate GHSA-xf85-363p-868w if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-xf85-363p-868w?

O3 pinpoints whether GHSA-xf85-363p-868w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-xf85-363p-868w actively exploited in the wild?

No public exploit code has been indexed for GHSA-xf85-363p-868w yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-xf85-363p-868w?

GHSA-xf85-363p-868w has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 18th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-xf85-363p-868w?

GHSA-xf85-363p-868w is classified as CWE-319 (CWE-319), Server-Side Request Forgery (SSRF) (CWE-918). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation. This is a high-impact weakness class that often enables remote code execution or data exposure.

When was GHSA-xf85-363p-868w published, and has it been updated?

GHSA-xf85-363p-868w was published on July 1, 2026 and was last updated on July 24, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

Not in CISA KEV

GHSA-xf85-363p-868w

Fix: oras-project/oras-go@7a9f4b0

GHSA-xf85-363p-868w is a CWE-319 vulnerability in oras.land/oras-go/v2. O3 Security confirms whether GHSA-xf85-363p-868w is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

oras-go: Malicious registry can hijack Bearer token realm to exfiltrate credentials and refresh tokens

Also known asCVE-2026-48978GO-2026-5885

Published

Jul 1, 2026

Updated

Jul 24, 2026

Affected

2 pkgs

Patched

1 / 2

Exploits

None indexed

Exploitation data as of Sep 7, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

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-xf85-363p-868w.

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs18th percentile — riskier than 18% of all scored CVEsHighest risk

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.

Real-World Exposure

2 pkgs affected

🐹oras.land/oras-go/v2🐹oras.land/oras-go

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

oras-go's auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating its scheme or host. The realm field is server-controlled by design in the OCI/distribution spec — registries legitimately point token requests at a separate auth endpoint (e.g. Docker Hub's registry-1.docker.io -> auth.docker.io), so cross-host realms on public DNS names are not in themselves a vulnerability. Two specific patterns, however, are never legitimate under any registry trust model and can be abused by a malicious or compromised registry (or a man-in-the-middle on a plaintext connection):

SSRF to internal networks. A realm of http://169.254.169.254/... (AWS/Azure IMDS), http://10.0.0.x/... (RFC 1918), or http://127.0.0.1/... causes oras-go running on a cloud VM or corporate workstation to issue outbound HTTP requests from inside the user's trust boundary to an endpoint the user did not choose. The user's stored credentials are attached to those requests, but the principal harm is the network primitive — probing internal endpoints from the client. On IMDSv1 the response body is recoverable from log channels; on IMDSv2 the probe itself can still be used for service discovery.
TLS downgrade. A registry contacted over https:// can return a realm with an http:// scheme, causing oras-go to send the user's credentials over plaintext to the token endpoint. This defeats the transport security the user chose when typing https://.

What is NOT claimed

This advisory does not claim that credential forwarding to an arbitrary public attacker host through a server-controlled realm is, on its own, a vulnerability. The distribution spec defines realm as a server-controlled field; a strict same-host or same-eTLD+1 enforcement would deviate from the spec and break legitimate split-host deployments. Operators who want defense-in-depth against cross-host realm forwarding can use the opt-in Client.TrustedRealmHosts allowlist (added separately).

Affected versions

oras.land/oras-go/v2 <= v2.6.0

Severity

Medium. Network attack vector, low complexity, no privileges required, user interaction required (victim runs an oras command against the malicious or MITM'd registry), unchanged scope. Confidentiality impact is limited — IMDS probe responses can disclose information, and TLS downgrade exposes the realm request to passive observers — but the attacker does not obtain credentials beyond what the malicious endpoint already controls.

Affected code

registry/remote/auth/client.go — Client.Do() (bearer challenge handling)
registry/remote/auth/client.go — Client.fetchBearerToken() / fetchDistributionToken / fetchOAuth2Token

The realm parameter from parseChallenge is threaded through to http.NewRequestWithContext without scheme or host validation.

CWE

CWE-918: Server-Side Request Forgery (SSRF)
CWE-319: Cleartext Transmission of Sensitive Information

Patch

registry/remote/auth/client.go now rejects realm URLs that:

use a scheme other than http or https
use http when the registry was contacted over https (TLS downgrade)
use an IP literal in a loopback, link-local, private, or unspecified range, unless the registry itself was reached at the same hostname (so loopback / in-cluster deployments are unaffected)

Cross-host realms on public DNS names continue to be accepted.

Credit

Reported by bugbunny.ai.

Affected Packages

2 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`oras.land/oras-go/v2`	all versions	2.6.1
🐹Go	`oras.land/oras-go`	all versions	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for oras.land/oras-go/v2. 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 oras.land/oras-go/v2 to 2.6.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xf85-363p-868w 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-xf85-363p-868w 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-xf85-363p-868w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary oras-go's `auth.Client` follows the `realm` URL from a registry's `WWW-Authenticate: Bearer` challenge without validating its scheme or host. The `realm` field is server-controlled by design in the OCI/distribution spec — registries legitimately point token requests at a separate auth endpoint (e.g. Docker Hub's `registry-1.docker.io` -> `auth.docker.io`), so cross-host realms on public DNS names are not in themselves a vulnerability. Two specific patterns, however, are never legitimate under any registry trust model and can be abused by a malicious or compromised registry (or a ma

O3 Security · Impact-Aware SCA

Is GHSA-xf85-363p-868w in your dependencies?

O3 detects GHSA-xf85-363p-868w across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works