CVE-2026-50151

What it actually does

oras-go versions prior to 2.6.1 improperly trust a registry-supplied Location header during monolithic OCI blob upload. After the initial POST request, the client follows the returned Location for the subsequent PUT request even when it points to a different host, and it reuses the original Authorization header. A malicious or compromised OCI registry can therefore cause the client to send registry credentials, bearer tokens, or basic authentication material to an attacker-controlled endpoint. The primary impact is confidentiality loss of credentials; there is no direct code execution, integrity modification, or availability impact from the flaw itself.

Why it matters to the business

Organizations using software that embeds vulnerable oras-go versions may unintentionally leak OCI registry credentials when interacting with a malicious, compromised, or spoofed registry endpoint. Stolen credentials can allow attackers to pull private artifacts, enumerate repositories, access container images, or potentially push tampered artifacts depending on token scope. The issue has a CVSS score of 7.5, low EPSS at the time of assessment, no known KEV listing, and no public exploit maturity reported, but remediation is still important because exploitation is simple if an attacker can influence which registry the client contacts or compromise a registry response path.

How an attack unfolds

An attacker first positions a malicious OCI registry or compromises a registry endpoint that a vulnerable oras-go-based client will contact. When the client begins a monolithic blob upload, it sends an initial POST request with an Authorization header intended for the legitimate registry. The attacker-controlled registry responds with a Location header that points to an attacker-controlled host rather than a same-origin upload URL. Vulnerable oras-go versions follow that cross-host Location for the subsequent PUT request and incorrectly preserve the original Authorization header. The attacker-controlled endpoint receives the PUT request along with the victim's credentials or bearer token. The attacker can then attempt to reuse the captured credential against the intended registry or related OCI artifact services, subject to token validity, audience, expiry, and permissions.

How to fix it

Upgrade oras-go to version 2.6.1 or later in all applications, CLIs, services, CI/CD tooling, and build pipelines that depend on it directly or transitively. Rebuild and redeploy binaries or containers that statically vendor oras-go, because Go dependencies are commonly compiled into the final artifact. If immediate upgrade is not possible, mitigate by preventing clients from interacting with untrusted registries, restricting egress from build and deployment systems to approved registry domains, enforcing short-lived and narrowly scoped registry tokens, and monitoring or blocking cross-host redirects/Location headers during OCI upload workflows. Rotate any registry credentials that may have been exposed through interactions with untrusted registries while vulnerable versions were in use.

How to confirm the fix worked

Confirm dependency versions using Go module metadata, source manifests, SBOMs, and binary/container provenance. Look for github.com/oras-project/oras-go/v2 or oras-go dependencies earlier than 2.6.1 and verify all affected binaries have been rebuilt after the upgrade. In test environments, perform a monolithic blob upload against a controlled registry that returns a cross-host Location header and confirm the client does not forward Authorization to the different host. Validate network controls by confirming build systems and artifact tooling can only connect to approved OCI registry endpoints. Review SBOM and image-scanning output to ensure no deployed artifact still includes vulnerable oras-go versions.

Typical attack path

1. Identify an application, CLI, build system, CI job, or service that uses oras-go before version 2.6.1 for OCI artifact operations.
2. Cause the vulnerable client to interact with a malicious, attacker-operated, compromised, or spoofed OCI registry endpoint.
3. Respond to the client's initial monolithic blob upload POST with a Location header pointing to an attacker-controlled host.
4. Receive the client's follow-up PUT request at the attacker-controlled host, including the improperly reused Authorization header.
5. Extract bearer token, basic authentication value, or other credential material from the received request.
6. Attempt to use the captured credential to access, pull, enumerate, or modify OCI artifacts according to the credential's privileges.

How to detect it

To determine whether exploitation already occurred, review outbound proxy logs, egress firewall logs, HTTP client traces, CI/CD job logs, registry access logs, and artifact tooling debug logs for OCI blob upload sequences where a POST to one registry host is followed by a PUT to a different host. Pay particular attention to requests containing Authorization headers after a Location redirect or upload URL response. Investigate any traffic from build workers, release systems, developer workstations, or artifact automation to unknown domains immediately after registry upload attempts. On the registry side, look for upload initiation responses with Location headers that contain a different scheme, host, or port than the original registry. If a suspicious cross-host credential-forwarding event is found, treat the associated registry token as compromised, rotate it, and review registry audit logs for subsequent private image pulls, repository listing, tag operations, or pushes from unfamiliar IP addresses or user agents. There are no universal attacker-specific indicators for this issue; detection is primarily behavioral and based on cross-host Location handling and credential-bearing follow-up requests.

• Location: http://
• Location: https://
• Authorization: Bearer
• Authorization: Basic
• POST /v2/
• PUT /v2/
• /blobs/uploads/
• Docker-Upload-UUID
• oras-go
• cross-host Location
• 307 Temporary Redirect
• 308 Permanent Redirect

What your security team should do

• Inventory software, CI/CD jobs, build images, developer tools, and internal services that use oras-go directly or through OCI artifact libraries.
• Prioritize upgrading all oras-go dependencies to 2.6.1 or later and rebuilding any statically linked Go binaries.
• Restrict outbound network access from CI/CD and artifact-management systems to trusted OCI registry domains only.
• Rotate registry credentials used by systems that interacted with untrusted or newly introduced registries while running vulnerable oras-go versions.
• Review registry token scopes and reduce permissions to least privilege, especially for automation tokens used in build and release pipelines.
• Add detection for OCI upload flows where an initial registry POST is followed by a PUT to a different host while carrying an Authorization header.
• Monitor for unusual private artifact pulls, repository enumeration, or push activity following any suspected credential exposure.