CVE-2026-50151: oras-go SSRF Vulnerability

CVE-2026-50151 Overview

CVE-2026-50151 is a credential exposure vulnerability in oras-go, a Go library for managing Open Container Initiative (OCI) artifacts. Versions prior to 2.6.1 blindly follow a registry-controlled Location header during monolithic blob uploads. The client reuses the Authorization header from the initial POST on the subsequent PUT request, even when the redirect points to a different host. A malicious registry can exploit this behavior to receive the caller's credentials at an attacker-controlled endpoint. The issue is tracked under [CWE-918: Server-Side Request Forgery (SSRF)] and is fixed in version 2.6.1.

Critical Impact
A malicious or compromised OCI registry can steal registry authentication credentials from any client using oras-go prior to 2.6.1 by returning a cross-host Location header during blob upload.

Affected Products

oras-project oras-go library versions prior to 2.6.1
Applications and CLI tools that embed oras-go for OCI artifact push operations
Container tooling relying on registry/remote/repository.goblobStore.completePushAfterInitialPost

Discovery Timeline

2026-07-17 - CVE-2026-50151 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-50151

Vulnerability Analysis

The flaw resides in registry/remote/repository.go, specifically inside blobStore.completePushAfterInitialPost. During an OCI monolithic blob upload, the client issues an initial POST to the registry. The registry responds with a Location header pointing to the URL used to complete the upload via PUT. oras-go follows this Location without validating that its host matches the original registry. The client then reuses the same Authorization header from the initial POST when sending the PUT to that new location.

Because OCI registry credentials are bearer tokens or basic-auth headers scoped to the intended registry, forwarding them to an arbitrary host constitutes a credential disclosure. This is a variant of [CWE-918] SSRF-style trust delegation: the server controls where the client sends authenticated requests.

Root Cause

The root cause is missing host validation on the Location header returned by the registry. The upload completion routine treats the redirect target as trusted and preserves sensitive request headers across hosts. Standard HTTP clients typically strip the Authorization header on cross-origin redirects, but the affected code path constructs the follow-up PUT request manually and copies headers explicitly.

Attack Vector

An attacker who operates a malicious registry, compromises a legitimate registry, or performs a man-in-the-middle attack on an unsecured registry connection can return a crafted response. Any client pushing a blob is coerced into transmitting its Authorization header to an attacker-controlled endpoint. The attacker then replays those credentials against the victim's real registry to read, modify, or plant artifacts.

// Patch excerpt: registry/remote/repository.go
// fix: validate Location host before blob upload to prevent credential leak (#1152)
 	"io"
 	"mime"
 	"net/http"
+	"net/url"
 	"slices"
 	"strconv"
 	"strings"

Source: oras-go commit 4683c46. The patch introduces net/url parsing so the client can compare the Location host to the original registry host before forwarding the Authorization header.

Detection Methods for CVE-2026-50151

Indicators of Compromise

Outbound HTTPS requests from build agents or CI runners to registry hostnames that do not match the configured push target.
Unexpected PUT requests carrying Authorization: Bearer or Authorization: Basic headers to non-registry domains.
Registry audit logs showing authenticated actions from IPs or user agents inconsistent with normal push workflows, indicating stolen credential replay.
Presence of oras-go versions earlier than 2.6.1 in go.mod or vendored dependencies of internal tooling.

Detection Strategies

Perform Software Composition Analysis (SCA) on Go modules to flag github.com/oras-project/oras-go at versions below 2.6.1.
Inspect egress proxy logs for blob upload flows that terminate at hostnames other than the intended registry.
Correlate CI/CD job registry credentials with registry-side authentication logs to identify anomalous source IPs.

Monitoring Recommendations

Enforce egress allow-lists on build systems so oras clients can only reach approved registry hostnames.
Alert on HTTP 3xx or 202 responses containing Location headers that redirect to external domains during container push operations.
Rotate and monitor short-lived registry tokens for reuse from unexpected client identities.

How to Mitigate CVE-2026-50151

Immediate Actions Required

Upgrade all applications and CLIs that depend on oras-go to version 2.6.1 or later.
Rotate any registry credentials, personal access tokens, or bearer tokens that may have been used with vulnerable clients pushing to untrusted registries.
Audit dependency graphs for transitive use of oras-go in container tooling, Kubernetes operators, and supply-chain utilities.

Patch Information

The fix is available in oras-go release v2.6.1 via pull request #1152. See the GitHub Security Advisory GHSA-jxpm-75mh-9fp7 for the coordinated disclosure details. The patch validates that the Location header host matches the original registry host before reusing the Authorization header on the follow-up PUT request.

Workarounds

Restrict oras-go clients to trusted, first-party registries only until upgrading to 2.6.1.
Use short-lived, narrowly scoped registry tokens so any leaked credential has minimal blast radius.
Route registry traffic through an egress proxy that enforces destination hostname allow-lists.

bash

# Update oras-go dependency to the patched release
go get github.com/oras-project/oras-go/v2@v2.6.1
go mod tidy

# Verify the resolved version
go list -m github.com/oras-project/oras-go/v2