CVE-2026-48978

What it actually does

oras-go versions prior to 2.6.1 improperly trust the realm value supplied in a registry WWW-Authenticate: Bearer challenge. When a client attempts to authenticate to a malicious or compromised OCI registry, the library may follow an attacker-controlled token endpoint without validating that the URL scheme and host are appropriate for the original registry. This enables server-side request forgery from the system running the oras-go-based client, including requests to loopback, private network ranges, cloud instance metadata services, or an insecure HTTP token endpoint even when the original registry connection used HTTPS. The likely impact is limited confidentiality exposure from reachable internal services or metadata endpoints; integrity and availability impact are not the primary risk described.

Why it matters to the business

Organizations using applications, CI/CD tooling, container artifact workflows, or supply-chain automation built on vulnerable oras-go versions could unintentionally allow an untrusted registry to make the client contact internal-only services. In practical terms, this can expose cloud metadata, service tokens, internal HTTP endpoints, or network topology information from build workers, developer machines, or automation hosts. The issue is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity, but it affects a foundational OCI artifact library, so exposure may be indirect through downstream tools rather than obvious package usage.

How an attack unfolds

An attacker first needs to influence an oras-go-based client to contact an OCI registry they control or a legitimate registry they have compromised. The registry responds to an artifact request with a crafted WWW-Authenticate: Bearer challenge whose realm points to an attacker-chosen URL, such as a cloud metadata endpoint, localhost service, private RFC1918 address, or plain HTTP token service. Vulnerable oras-go authentication code follows that realm while fetching a bearer or OAuth2 token. Because the scheme and host are not sufficiently constrained to the expected registry authentication authority, the client sends a network request from its own environment to the attacker-selected endpoint. If the endpoint responds with sensitive data or if request behavior reveals network reachability, the attacker can use the response or side effects to collect metadata, credentials, or internal service information. Exploitation generally requires user or workflow interaction with a malicious registry and is more plausible in automated build, artifact mirroring, or dependency retrieval pipelines that access externally supplied OCI registries.

How to fix it

Upgrade oras-go to version 2.6.1 or later wherever it is used directly or transitively. Because oras-go is commonly embedded in other Go-based OCI tooling, also update vendor dependencies, regenerate lockfiles, rebuild affected binaries, and redeploy packaged tools rather than only changing source manifests. If immediate upgrade is not possible, reduce exposure by allowing OCI artifact operations only against trusted registries, blocking egress from build and automation hosts to link-local metadata services such as 169.254.169.254, loopback targets, private network ranges not required for business use, and cleartext HTTP token endpoints. Enforce outbound proxy controls that deny unexpected authentication-token destinations, and avoid running untrusted registry interactions from hosts with privileged cloud roles or broad internal network access.

How to confirm the fix worked

Confirm all direct Go modules and vendored dependencies resolve github.com/oras-project/oras-go/v2 at version 2.6.1 or later. Use dependency tooling such as go list -m all, go mod graph, software composition analysis, SBOM scans, and container image scans to identify transitive inclusion in built tools. Validate rebuilt binaries by checking module metadata where available with go version -m. Functionally test by configuring a controlled OCI registry to issue a Bearer challenge with a realm pointing to a disallowed host or non-HTTPS endpoint and verify the patched client rejects or does not follow the unexpected realm. Also confirm network controls prevent artifact-processing systems from reaching metadata endpoints, loopback-only services, and unnecessary private address ranges.

Typical attack path

1. Identify an application, developer workflow, CI/CD job, or artifact automation process that uses oras-go prior to version 2.6.1.
2. Cause that client to pull from, resolve, copy, or otherwise interact with an attacker-controlled or compromised OCI registry.
3. Return a WWW-Authenticate: Bearer challenge containing a malicious realm URL pointing to an internal address, loopback service, metadata endpoint, or downgraded HTTP token endpoint.
4. Wait for the vulnerable oras-go auth client to follow the supplied realm while attempting to obtain a bearer or OAuth2 token.
5. Use the resulting client-side request to probe internal network reachability or retrieve data exposed by metadata or internal HTTP services.
6. If sensitive metadata or credentials are obtained, use them for follow-on access depending on their permissions and validity.

How to detect it

Look for evidence that systems running OCI artifact operations made unexpected outbound HTTP requests during registry authentication. Relevant sources include CI/CD job logs, artifact mirroring service logs, container registry proxy logs, application logs from tools using oras-go, outbound proxy logs, DNS logs, EDR network telemetry, host firewall logs, cloud VPC flow logs, and cloud metadata access logs where available. Focus on requests from build workers, developer workstations, automation runners, or artifact-processing services to link-local metadata addresses, localhost, private IPs, or unexpected HTTP token endpoints shortly after requests to an OCI registry. In application logs, search for Bearer authentication challenges, token fetch errors, redirects or requests to realm URLs, and registry authentication failures involving unusual hosts or http:// schemes. If exploitation is suspected, correlate the initial registry contact with any subsequent access to cloud metadata credentials and then review cloud identity logs for use of newly obtained temporary credentials.

• WWW-Authenticate: Bearer realm="http://169.254.169.254
• WWW-Authenticate: Bearer realm="http://169.254.169.254/latest/meta-data
• WWW-Authenticate: Bearer realm="http://169.254.169.254/latest/api/token
• WWW-Authenticate: Bearer realm="http://metadata.google.internal
• WWW-Authenticate: Bearer realm="http://169.254.169.254/metadata/identity/oauth2/token
• WWW-Authenticate: Bearer realm="http://127.0.0.1
• WWW-Authenticate: Bearer realm="http://localhost
• WWW-Authenticate: Bearer realm="http://10.
• WWW-Authenticate: Bearer realm="http://172.16.
• WWW-Authenticate: Bearer realm="http://192.168.
• GET /latest/meta-data
• GET /latest/api/token
• Host: 169.254.169.254
• Host: metadata.google.internal
• registry/remote/auth/client.go
• fetchBearerToken
• fetchDistributionToken
• fetchOAuth2Token
• github.com/oras-project/oras-go/v2 v2.6.0
• github.com/oras-project/oras-go/v2 v2.5.
• github.com/oras-project/oras-go/v2 v2.4.

What your security team should do

• Inventory applications, CLIs, CI/CD jobs, artifact mirroring services, and container supply-chain tools that use oras-go directly or embed OCI artifact functionality.
• Prioritize upgrading all oras-go usage to version 2.6.1 or later, including vendored and statically compiled Go binaries.
• Review build and automation hosts for excessive cloud instance roles or internal network access, since SSRF impact depends heavily on what those systems can reach.
• Restrict artifact workflows to trusted registries and require review before adding new external OCI registry sources.
• Implement egress filtering from developer, CI, and artifact-processing environments to block cloud metadata IPs, loopback destinations, and unnecessary RFC1918 ranges.
• Monitor for unusual outbound HTTP requests from artifact tooling to metadata, localhost, private IP, or unexpected token-service destinations following OCI registry authentication failures.
• If suspicious activity is found, rotate credentials that may have been exposed through metadata services or internal token endpoints and review cloud audit logs for subsequent use.