oras-go EUVD-2026-45264

Requires the victim's oras-go v2 client to perform a monolithic blob upload (push) where the responding registry is attacker-controlled, compromised, or on-path (MITM), because the malicious Location header returned to the POST is the exploitation primitive. The credential leak triggers specifically when the registry returns a cross-host Location (different scheme/host/port than the original request) and the client has an Authorization header set on the initial POST. Limiting factors: the attacker must influence the registry endpoint the client talks to (clients pinned to a single trusted TLS registry are not exploitable by an external party), credentials must actually be present on the request for there to be anything to leak, and the impact is confined to confidentiality (credential/blob disclosure and SSRF) - no integrity or availability impact. Per CVSS PR:N the flaw needs no attacker privileges on the victim, but it does depend on the victim initiating an upload to a hostile registry, so it is not fully unauthenticated-drive-by against arbitrary targets.

The signals are moderately but not uniformly high. The published CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5) treats this as a network, no-privilege, no-interaction confidentiality breach, which overstates ease: exploitation realistically requires the victim client to push to a registry the attacker controls or has compromised (or an on-path MITM), so a real precondition exists that the base vector does not capture - verify deployment context before treating this as trivially remote. There is no CISA KEV entry and no evidence of active or widespread exploitation; EPSS is not provided in the input. A reproduction harness (poc.zip) is described by the reporter, demonstrating the credential-forwarding behavior in a controlled setup, so feasibility is confirmed even though in-the-wild abuse is not. Net: a real, credential-exposing library flaw worth prompt patching for anyone pushing to untrusted or multi-tenant registries, but lower urgency for clients that only ever talk to a single trusted first-party registry over TLS.

An attacker stands up (or compromises, or MITMs) an OCI registry and waits for a victim tool built on oras-go to push an artifact; the registry accepts the initial POST and returns a Location header pointing at an attacker-controlled host. oras-go follows that cross-host URL and replays the caller's Authorization credentials on the PUT, delivering the bearer/basic token - and the blob payload - to the attacker, who can then reuse the token against the legitimate registry. The reporter's poc.zip harness demonstrates exactly this with a fake registry returning a cross-host Location and a second server that records the received Authorization header.