CVE-2026-48978: 
Helm vulnerability analysis and mitigation

CVE-2026-48978 is a Server-Side Request Forgery (SSRF) and TLS downgrade vulnerability in oras-go, a Go library for managing OCI artifacts. The auth.Client component follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating the scheme or host, enabling a malicious or compromised registry to redirect token requests to internal network endpoints or downgrade HTTPS connections to HTTP. Affected versions include oras.land/oras-go/v2 <= v2.6.0 and oras.land/oras-go (v1) <= 1.2.7 (no patch available for v1). The vulnerability was reported by bugbunny.ai, published to the GitHub Advisory Database on July 1, 2026, and carries a CVSS v4 base score of 2.1 (Low) (Github Advisory).

The root cause is insufficient validation of the realm parameter parsed from WWW-Authenticate: Bearer challenge responses in registry/remote/auth/client.go. The realm value is passed directly to http.NewRequestWithContext without checking the URL scheme or host, violating CWE-918 (SSRF) and CWE-319 (Cleartext Transmission of Sensitive Information). Two attack patterns are possible: (1) a malicious registry returns a realm pointing to an internal IP (e.g., http://169.254.169.254/, http://10.0.0.x/, http://127.0.0.1/), causing the client to probe internal endpoints from within the user's trust boundary; (2) a registry contacted over https:// returns an http:// realm, causing credentials to be transmitted in plaintext. The vulnerable code path flows through Client.Do(), Client.fetchBearerToken(), fetchDistributionToken, and fetchOAuth2Token (Github Advisory, Patch Commit).

Successful exploitation allows a malicious or MITM'd registry to cause the oras-go client to issue HTTP requests to internal network endpoints (cloud IMDS services, RFC 1918 addresses, loopback interfaces) from within the victim's trust boundary, enabling internal service discovery and, on IMDSv1, potential recovery of instance metadata from log channels. The TLS downgrade vector exposes the user's credentials and OAuth2/refresh tokens to passive network observers. Integrity and availability of the vulnerable system are not directly impacted; the primary risk is limited confidentiality exposure through SSRF probing and credential interception (Github Advisory).

No public exploit code or in-the-wild exploitation has been reported for CVE-2026-48978. The vulnerability requires user interaction — the victim must run an oras command against a malicious or MITM'd registry — and attack complexity is rated High. The EPSS score is approximately 0.21% (11th percentile), indicating a low probability of near-term exploitation. The CVE status is listed as "Deferred" and it is not present in the CISA Known Exploited Vulnerabilities catalog (Github Advisory).

1. Set up a malicious registry: Deploy a container registry that responds to OCI distribution API requests and can serve crafted WWW-Authenticate headers.
2. Craft a malicious Bearer challenge: Configure the registry to respond to unauthenticated requests with a WWW-Authenticate: Bearer realm="http://169.254.169.254/latest/meta-data/",service="registry" header (or another internal target such as http://10.0.0.1/ or an http:// downgrade of an https:// registry).
3. Lure the victim: Convince a user running oras-go (e.g., via a Helm chart pull, oras pull, or similar OCI artifact operation) to interact with the malicious registry — for example, by referencing a malicious image reference in a CI/CD pipeline or Kubernetes deployment.
4. Trigger the SSRF: When the victim's oras-go client receives the 401 Unauthorized response with the crafted WWW-Authenticate header, it follows the unvalidated realm URL and issues an HTTP request to the internal endpoint (e.g., AWS/Azure IMDS at 169.254.169.254) from within the victim's network.
5. Harvest results: For IMDSv1, the IMDS response body may be recoverable through log channels or error messages. For IMDSv2 or RFC 1918 targets, the probe can be used for internal service discovery. For the TLS downgrade variant, credentials transmitted in plaintext can be intercepted by a passive network observer (Github Advisory, Patch Commit).

• Network: Unexpected outbound HTTP requests from a host running oras-go to 169.254.169.254, 10.0.0.x, 172.16.x.x, 192.168.x.x, or 127.0.0.1 on port 80 or other non-standard ports, particularly following OCI registry authentication flows.
• Network: HTTP (plaintext) token requests to a token endpoint when the registry was originally contacted over HTTPS, indicating a potential TLS downgrade.
• Logs: Application or HTTP client logs showing GET or POST requests to internal IP ranges or IMDS endpoints originating from oras-go processes (look for fetchBearerToken or fetchDistributionToken context in Go stack traces).
• Logs: WWW-Authenticate headers in registry responses containing realm values pointing to RFC 1918 addresses, loopback addresses, or http:// schemes when the registry was contacted over https://.
• Process: Unexpected network connections from CI/CD runners, Kubernetes nodes, or developer workstations to cloud metadata endpoints (169.254.169.254) coinciding with OCI artifact pull/push operations.

Upgrade oras.land/oras-go/v2 to version v2.6.1 or later, which introduces a validateRealm() function in registry/remote/auth/client.go that rejects realm URLs using non-http/https schemes, http realms when the registry was contacted over https (TLS downgrade prevention), and IP literals in loopback, link-local, private, or unspecified ranges (Release v2.6.1). For v1 (oras.land/oras-go), no patch is available; migration to v2 is recommended. As an additional defense-in-depth measure, operators can configure the new Client.TrustedRealmHosts allowlist to explicitly permit only known legitimate token service hosts. IBM Sterling Order Management System Software users should apply the vendor-provided security bulletin update (IBM Advisory).

The vulnerability was reported by bugbunny.ai and addressed by maintainer TerryHowe as part of a broader security patch release (v2.6.1) that resolved five advisories simultaneously (Release v2.6.1). SUSE issued security updates for affected packages (including Helm, which depends on oras-go), and OpenSUSE published security announcements to their mailing lists. No significant broader media coverage or notable researcher commentary beyond the official advisory has been identified.