GHSA-vh4v-2xq2-g5cg: ORAS Go forwards registry credentials across registry redirects
ORAS Go forwards registry credentials across registry redirectsReporter / public credit: JUNYI LIUSummaryORAS Go can forward registry credentials configured for one registry origin to a different HTTP origin during registry redirects.There are two related paths:A manifest or metadata request authenticates to the origin registry, then the origin returns a redirect to another host or port. The redirected request can carry the origin `Authorization` header to the redirect target.A blob upload `POST` authenticates to the origin registry, then the origin returns an upload `Location` on another host or port. The follow-up `PUT` can carry the origin `Authorization` header to the `Location` target.The upload `Location` issue appears related to the existing public fix in pull request #1152 / GHSA-jxpm-75mh-9fp7. The manifest redirect path is a residual adjacent route: the v2 branch after the upload `Location` fix still forwards Basic credentials on an authenticated manifest redirect.ImpactA registry response can cause an ORAS Go or ORAS CLI client to send configured registry credentials to an unintended endpoint. In common workflows, those credentials may come from a registry config / Docker-style auth file rather than command-line flags.This is a credential exposure across the registry-origin boundary. I am not claiming remote code execution, registry compromise, arbitrary token theft, or live third-party impact.Affected Versions Tested`oras-go v2.6.0`: affected.`oras-go` main at commit `a57383e580c8f2c97fb67dedfc5c9945c8c3614e`: affected.`oras-go` v2 branch at commit `d593d504779be8b69f0ba034ac9fd407d1fc8cfc`: upload `Location` path is blocked, but manifest redirect credential forwarding is still affected.ORAS CLI at commit `3d2646279c70ba60415440e44c2ff97896e4a209`, using `oras-go v2.6.0`: affected when using `--registry-config`.Security InvariantCredentials resolved for one registry origin should not be silently forwarded to a different origin reached through a registry redirect or upload `Location` response.Local Reproduction OverviewAll testing used loopback servers and fake credentials only.Manifest redirect flow:The client requests a manifest from the origin registry.The origin returns `401` with a Basic challenge.The client retries the origin request with the origin credential.The origin returns `307` to another port on the same hostname.The redirect sink receives the origin `Authorization` header.ORAS CLI stored-credential flow:A temporary registry config contains a fake Basic credential for the origin registry only.Run:The origin authenticates the request and redirects it to another port.The redirect sink receives the origin `Authorization` header.Blob upload `Location` flow:The client starts a blob upload with `POST` to the origin registry.The origin challenges with Basic and then accepts the authenticated `POST`.The origin returns an upload `Location` URL on another port.In affected versions, the follow-up `PUT` to the `Location` target carries the origin `Authorization` header.Expected ResultRedirect and upload `Location` targets on a different HTTP origin should not receive the origin `Authorization` header.Observed ResultIn affected versions, redirect or `Location` sinks received:Standalone ReproducerCandidate FixThe candidate fix does two things:In the auth client, wrap redirect handling so `Authorization` is removed when a redirect changes HTTP origin, while preserving any caller-provided `CheckRedirect` callback.In blob upload completion, only reuse the previous `POST` `Authorization` header when the upload `Location` remains on the same HTTP origin.The patch also adds regression coverage for both redirect cases:redirect before origin authentication reaches a different origin;redirect after origin authentication reaches a different origin.Validation PerformedThe repaired candidate fix blocked:manifest redirect credential forwarding;upload `Location` credential forwarding.Targeted tests passed:Prior Art / Duplicate NotesPublic pull request #1152 fixes credential forwarding via unvalidated blob upload `Location` and references GHSA-jxpm-75mh-9fp7. The residual manifest redirect path described here is adjacent but not covered by that PR's stated upload `Location` scope.Bearer realm credential exfiltration appears to be a separate issue family and is not part of this report's primary claim.Claim BoundariesProven:Origin registry Basic credentials can reach a different redirect or upload `Location` origin in local loopback tests.ORAS CLI stored registry credentials can reach a redirect sink in a normal manifest fetch workflow.The candidate fix blocks the tested redirect and upload `Location` credential exposures.Not claimed:Live third-party exploitation.RCE, host compromise, or registry compromise.Arbitrary-host exposure beyond the tested redirect/`Location` origin transitions.Bearer realm behavior as part of the same claim.
CVSS v4.0: 6.9