CVE-2026-85732: 
Trivy vulnerability analysis and mitigation

CVE-2026-85732 is a blind Server-Side Request Forgery (SSRF) vulnerability in the oras-go Go library (by oras-project) for managing OCI artifacts. The flaw exists in the parseLink() function in registry/remote/utils.go, which accepts absolute URLs from registry-controlled Link response headers without validating the scheme, host, or port. All versions prior to 2.6.2 are affected. The vulnerability was published on September 16, 2026, and is noted by the maintainer as a duplicate of GHSA-3hr5-mjrr-hfjh, with remediation consolidated in that earlier advisory and fixed in v2.6.2. It carries a CVSS v3.1 base score of 4.7 (Medium) (GitHub Advisory, Red Hat).

The root cause is CWE-918 (Server-Side Request Forgery): parseLink() at registry/remote/utils.go:54 calls resp.Request.URL.Parse(link), which returns an absolute URL unchanged when the Link header contains one. The resulting URL is passed directly to http.NewRequestWithContext() in the pagination loop with no host comparison, scheme validation, or IP filtering. This affects three code paths: registry/remote/repository.go:Tags(), registry/remote/repository.go:Referrers(), and registry/remote/registry.go:Repositories(). A public proof-of-concept is available in the GitHub Security Advisory, demonstrating a malicious registry handler that sets a Link header pointing to an internal service, causing the victim's oras-go client to issue a GET request to that internal endpoint during pagination (GitHub Advisory, Fix Commit).

Successful exploitation enables blind SSRF from the victim's network, allowing an attacker to probe internal services (including cloud instance metadata endpoints), enumerate reachable hosts via timing and error differences, and trigger unintended side effects on internal HTTP services. If the victim's credential store contains an entry for the targeted internal host, those credentials are automatically attached to the forged request, potentially enabling credential exfiltration and follow-on authenticated attacks against internal services. Integrity and availability are not directly impacted; the primary risk is confidentiality loss through internal network reconnaissance and credential leakage (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, including concrete Go code demonstrating the attack. Exploitation is not automated and requires user interaction — the victim must perform a pagination-based listing operation (Tags, Referrers, or Repositories) against an attacker-controlled registry. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is 0.0, and the vulnerability is not listed in the CISA KEV catalog. The NVD SSVC assessment classifies exploitation status as "poc" (GitHub Advisory, Red Hat).

1. Set up a malicious OCI registry: Deploy an HTTP server that mimics an OCI-compliant registry, capable of responding to tag/referrer/repository listing requests (e.g., GET /v2/repo/tags/list).
2. Craft a malicious Link response header: Configure the registry handler to return a valid first-page JSON response along with a Link header pointing to an internal target, e.g., Link: <http://169.254.169.254/latest/meta-data/>; rel="next" (cloud metadata) or Link: <http://internal-service:8080/admin>; rel="next".
3. Social-engineer or position the victim: Induce the victim to query the attacker-controlled registry using oras-go (version ≤ 2.6.1) by calling repo.Tags(ctx, "", ...), repo.Referrers(ctx, ...), or registry.Repositories(ctx, ...).
4. Trigger SSRF via pagination: The victim's oras-go client calls parseLink(), which extracts the absolute URL from the Link header without validation and passes it to http.NewRequestWithContext(), issuing a GET request to the internal endpoint from the victim's network.
5. Infer internal service reachability: Observe timing differences or error messages returned to the attacker's registry (indirectly, via the victim's behavior) to confirm whether the internal service is reachable. If the victim's credential store has an entry for the target host, credentials are automatically attached to the forged request, enabling potential credential harvesting (GitHub Advisory).

• Network: Unexpected outbound GET requests from systems running oras-go to internal IP ranges, cloud metadata endpoints (e.g., 169.254.169.254), or non-registry hosts during OCI listing operations; connections to unusual ports (e.g., 8080, 8443) from the oras-go process.
• Logs: HTTP client logs or network flow logs showing GET requests to internal services immediately following OCI registry pagination calls; error messages such as invalid next link ... not the same origin as ... in patched versions (indicating attempted exploitation).
• Process/Application: oras-go application logs showing failed JSON parsing errors after pagination requests to unexpected hosts, which may indicate a blind SSRF attempt where the internal service returned non-JSON content.
• Credential Store: Unexpected authentication attempts to internal services using OCI registry credentials, potentially visible in internal service access logs (GitHub Advisory).

Upgrade oras-go to version 2.6.2 or later, which introduces an isSameOrigin() check in parseLink() that rejects any Link header URL whose scheme, host, or port differs from the originating request (Fix Commit, Release v2.6.2). As interim mitigations, implement network egress controls to restrict outbound connections from systems running oras-go to only known, trusted registry hosts; audit credential store configurations to minimize the number of internal service credentials stored alongside registry credentials; and restrict which OCI registries are trusted for pagination operations to known-good sources (GitHub Advisory).

The maintainer of oras-go acknowledged the report but identified it as a duplicate of the earlier advisory GHSA-3hr5-mjrr-hfjh (submitted 2026-06-17 vs. this report's 2026-07-02), consolidating the fix under that advisory. Red Hat tracked the issue via Bugzilla (Bug 2535554) and assigned it medium severity. No significant broader media coverage or notable researcher commentary beyond the advisory itself has been identified (GitHub Advisory, Red Hat Bugzilla).