CVE-2026-48978: 
Helm vulnerability analysis and mitigation

CVE-2026-48978 is a Server-Side Request Forgery (SSRF) and TLS downgrade vulnerability in the oras-go Go library (oras.land/oras-go), specifically in its auth.Client component. The vulnerability arises because auth.Client follows the realm URL from a registry's WWW-Authenticate: Bearer challenge without validating the URL's scheme or host, allowing a malicious or compromised registry to redirect token requests to internal network endpoints or force credential transmission over plaintext HTTP. Affected versions include oras.land/oras-go/v2 ≤ v2.6.0 (patched in v2.6.1) and oras.land/oras-go (v1) ≤ v1.2.7 (no patch available for v1). The vulnerability was reported by bugbunny.ai, published on June 11, 2026, and added to the GitHub Advisory Database on July 1, 2026. It carries a CVSS v4 base score of 2.1 (Low) per the GitHub Advisory Database, though the upstream security advisory rates it as Moderate severity (GitHub Advisory, ORAS Security Advisory).

The root cause is insufficient input validation (CWE-918: SSRF; CWE-319: Cleartext Transmission of Sensitive Information) in registry/remote/auth/client.go. The realm parameter extracted by parseChallenge from the WWW-Authenticate: Bearer header is passed directly to http.NewRequestWithContext without any scheme or host validation, meaning the library will blindly issue HTTP requests to whatever URL the registry specifies. Two exploitation patterns are identified: (1) SSRF to internal networks — a realm pointing to http://169.254.169.254/... (AWS/Azure IMDS), RFC 1918 addresses (e.g., http://10.0.0.x/...), or loopback (http://127.0.0.1/...) causes the client to probe internal endpoints from within the user's trust boundary; and (2) TLS downgrade — a registry contacted over https:// can return a realm with an http:// scheme, causing credentials to be transmitted in plaintext. The vulnerable code paths are Client.Do(), Client.fetchBearerToken(), fetchDistributionToken(), and fetchOAuth2Token() (GitHub Advisory, Patch Commit).

A malicious or compromised registry (or a man-in-the-middle attacker on a plaintext connection) can cause oras-go clients to probe internal cloud metadata services (e.g., AWS IMDSv1/v2, Azure IMDS) or RFC 1918 network endpoints, enabling internal service discovery and, in IMDSv1 environments, potential recovery of instance metadata from log channels. The TLS downgrade vector exposes the user's stored credentials and OAuth2/refresh tokens to passive network observers. While the attacker does not directly obtain credentials beyond what the malicious endpoint already controls, the SSRF primitive can be leveraged for lateral movement within cloud or corporate environments (GitHub Advisory, ORAS Security Advisory).

1. Set up a malicious registry: Deploy a registry server (or perform a MITM attack on an existing plaintext HTTP registry connection) that responds to OCI/distribution API requests.
2. Craft a malicious WWW-Authenticate header: Configure the registry to return a 401 Unauthorized response with a WWW-Authenticate: Bearer realm="http://169.254.169.254/latest/meta-data/" header (or another internal/RFC 1918 target) when a client attempts to authenticate.
3. Wait for victim interaction: The victim runs an oras command (e.g., oras pull, oras push) targeting the malicious or MITM'd registry, triggering the Bearer challenge flow.
4. SSRF probe executes: oras-go's auth.Client.Do() parses the realm parameter and, without validation, issues an HTTP GET request to http://169.254.169.254/latest/meta-data/ (or the specified internal endpoint) from within the victim's network trust boundary.
5. Harvest results (IMDSv1): If the client is running on a cloud VM with IMDSv1 enabled, the IMDS response body may be logged or otherwise recoverable, disclosing instance metadata such as IAM role credentials.
6. TLS downgrade variant: Alternatively, configure the registry (contacted over HTTPS) to return a realm with an http:// scheme; oras-go will send the user's credentials in plaintext to the specified HTTP endpoint, where they can be captured by a network observer (GitHub Advisory, Patch Commit).

• Network: Unexpected outbound HTTP requests from oras-go client hosts to 169.254.169.254, 127.0.0.1, or RFC 1918 addresses (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) on port 80 or other non-standard ports, originating from processes running oras commands.
• Network: Outbound HTTP (plaintext) requests to token/auth endpoints when the registry was configured or expected to use HTTPS, indicating a potential TLS downgrade.
• Logs: Application or system logs containing HTTP responses from 169.254.169.254 or other internal metadata endpoints, particularly in cloud VM environments.
• Logs: oras-go error messages referencing unexpected realm URLs in Bearer challenge handling (post-patch, these would appear as validation errors; pre-patch, silent success is the indicator of concern).
• Process: oras CLI or Go processes making outbound connections to internal IP ranges immediately following registry authentication attempts (GitHub Advisory).

Upgrade oras.land/oras-go/v2 to v2.6.1 or later, which introduces the 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. For v1 (oras.land/oras-go ≤ v1.2.7), no patch is available; users should migrate to v2. As a defense-in-depth measure, operators can configure the opt-in Client.TrustedRealmHosts allowlist (added in v2.6.1) to restrict cross-host realm forwarding. Additionally, network-level controls (e.g., blocking outbound access to 169.254.169.254 from container/VM environments) can reduce SSRF impact (ORAS Release v2.6.1, Patch Commit).

SUSE issued a security update (SUSE-SU-2026:2823-1) addressing this vulnerability in packages including Helm for SUSE Linux Enterprise and openSUSE Tumbleweed, indicating downstream distribution uptake (SUSE Advisory). The openSUSE security announce mailing list also published notifications for affected packages. No significant public researcher commentary or social media discussion has been identified beyond vendor advisory channels.