CVE-2026-50151: 
Trivy vulnerability analysis and mitigation

CVE-2026-50151 is a credential forwarding vulnerability in the oras-go library (OCI Registry As Storage Go client) caused by an unvalidated Location header during the monolithic blob upload flow. During a blob push, the blobStore.completePushAfterInitialPost function follows the registry-returned Location header for the subsequent PUT request while blindly reusing the Authorization header from the initial POST, even if the Location redirects to a different host. Affected versions include oras.land/oras-go/v2 prior to v2.6.1; v2.6.0 (commit 03243809) is confirmed vulnerable, and earlier v2.x releases with the same upload flow are likely affected. The vulnerability was reported by researcher "1seal" (oleh), published as GHSA-jxpm-75mh-9fp7 on June 11, 2026, and added to the GitHub Advisory Database on July 1, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, ORAS Security Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery). The vulnerable code resides in registry/remote/repository.go lines 878–916, specifically the blobStore.completePushAfterInitialPost function. During the OCI monolithic blob upload protocol, a client first sends a POST to /v2/<name>/blobs/uploads/ to initiate the upload; the registry responds with a Location header indicating where to send the actual PUT with the blob data. The oras-go library unconditionally followed this Location and forwarded the original Authorization header to whatever host was specified — including attacker-controlled cross-origin hosts — without validating that the destination matched the original registry. A malicious registry could also downgrade the scheme from https to http, further exposing credentials in plaintext. A proof-of-concept (poc.zip) was included in the advisory, demonstrating the leak using a fake registry server and a second attacker-controlled server that records received Authorization headers (GitHub Advisory, Fix Commit).

Successful exploitation results in a high-confidentiality-impact credential leak: registry authentication tokens or credentials supplied by the caller are forwarded to an attacker-controlled endpoint. This can enable unauthorized access to OCI registries, container image repositories, or any other resource protected by the leaked credentials. Additionally, the vulnerability enables client-side SSRF, allowing a malicious registry to cause the oras-go client to issue authenticated HTTP requests to arbitrary internal or external hosts, potentially facilitating lateral movement within internal networks. There is no direct integrity or availability impact from the vulnerability itself (GitHub Advisory, ORAS Security Advisory).

1. Set up attacker infrastructure: Deploy two servers — a fake OCI registry server and a credential-capture server. The fake registry listens on a standard HTTPS/HTTP port and mimics the OCI Distribution Spec blob upload initiation endpoint (POST /v2/<name>/blobs/uploads/).
2. Craft malicious POST response: When the victim oras-go client initiates a blob upload via POST /v2/<name>/blobs/uploads/, the fake registry responds with HTTP 202 Accepted and sets the Location header to a URL on the attacker's credential-capture server (e.g., http://attacker.example.com/v2/test/blobs/uploads/evil-uuid).
3. Trigger credential forwarding: The oras-go client, running vulnerable code in blobStore.completePushAfterInitialPost, follows the cross-host Location and issues a PUT request to the attacker's server, automatically including the original Authorization header (e.g., Authorization: Bearer <token>).
4. Capture credentials: The attacker's credential-capture server records the incoming Authorization header, obtaining the victim's registry credentials or bearer token.
5. Abuse captured credentials: Use the stolen token or credentials to authenticate to the legitimate OCI registry, pull private images, push malicious images, or access other protected resources (GitHub Advisory, Fix Commit).

• Network: Outbound PUT requests from the oras-go client to unexpected external hosts during a blob upload operation (i.e., the PUT destination host differs from the registry host used in the initial POST).
• Network: HTTP requests carrying Authorization headers directed to hosts not matching the configured OCI registry hostname or IP.
• Network: Unexpected HTTP (non-HTTPS) requests carrying Authorization headers, indicating a potential scheme downgrade exploitation.
• Logs: Application or HTTP access logs showing a POST /v2/<name>/blobs/uploads/ followed by a PUT to a different host than the registry.
• Logs: Error messages in patched versions: blob upload Location "<host>" is on a different host than the registry "<registry>" — presence of this error in logs may indicate an attempted exploitation against a patched client (Fix Commit).

Upgrade oras.land/oras-go/v2 to version v2.6.1 or later, which validates that the Location header returned by the registry refers to the same host (scheme, hostname, and effective port) as the original request before issuing the PUT and forwarding the Authorization header. The fix also rejects scheme downgrades from https to http. No configuration-based workaround is available for unpatched versions; the only effective mitigation is upgrading. Downstream projects using oras-go (e.g., pulumi/pulumi-kubernetes) should also update their dependency to pull in the patched version (v2.6.1 Release, GitHub Advisory).

The fix was authored by ORAS project maintainer TerryHowe with AI assistance (Claude Sonnet 4.6) and reviewed and approved by contributor sabre1041. The v2.6.1 release addressed five security advisories simultaneously, indicating a coordinated security patch effort by the ORAS project team. The Go vulnerability database (golang/vulndb) opened a tracking issue for this advisory (golang/vulndb#5882), and Tenable added a container security plugin (ID 444249) for detection. Downstream projects such as pulumi/pulumi-kubernetes have already committed dependency updates to incorporate the fix (v2.6.1 Release, Fix PR).