CVE-2026-118763

Summary

@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location

Affected versions and vulnerable location

• Confirmed on sigstore-js at 3a83271 (current HEAD).
• File: packages/oci/src/registry.ts.
  • signIn() installs the credential as a DEFAULT header on the shared client: this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: 'Basic ' + basicAuth } }) (:126-128) or ... 'Bearer ' + token (:145-147), plus creds.headers from the Docker config (:104).
  • uploadBlob() reads the Location response header (:184), builds uploadLocation = new URL(location.startsWith('/') ? this.#baseURL + location : location) (:190-192), and PUTs the blob to it through the same client: await this.#fetch(uploadLocation.href, { method: 'PUT', body: blob, headers: { [HEADER_CONTENT_TYPE]: ... } }) (:198).
• There is no check that uploadLocation's host (or scheme) equals the registry host before the PUT is sent.

Root cause

Because signIn() sets Authorization via .defaults(), it is attached to every request the client issues, including requests to a host the client read out of a server response. When a POST to .../blobs/uploads/ returns an absolute Location pointing to a different host, uploadBlob() PUTs the blob there with the registry Authorization header still attached. If the challenge scheme was basic, that header carries the raw registry username:password; if bearer, it carries the access token; creds.headers custom auth headers ride along too.

The library's HTTP layer (make-fetch-happen / minipass-fetch) strips Authorization on cross-host redirects it follows internally, which protects the HEAD ... { redirect: 'follow' } at :167. It does not help here, because the PUT to the upload Location is a fresh, explicit this.#fetch() call, not a followed redirect, so the default header is applied unconditionally.

This is a residual of GHSA-pf56-329r-95rw / CVE-2026-59891 (credential confusion in @sigstore/oci). The fix for that advisory (commit 85c5838) changed only credentials.ts, replacing a key.includes(registry) substring match with an exact host match when SELECTING which Docker credential to load. It never touched registry.ts, which controls WHERE the loaded credential is sent. The cross-host send remains.

Attacker model

A user pushing a signed artifact/attestation to an OCI registry via attachArtifactToImage(). The credential leaks to any host the registry names in the blob-upload Location. This is reachable when the registry is malicious or compromised, or when a registry that legitimately redirects blob uploads to third-party storage is impersonated. The OCI distribution spec permits absolute upload Location values (registries commonly redirect blob storage to a separate host), so a compliant-but-hostile registry can steer the PUT to an attacker host and capture the credential. This is the same "attacker-controlled registry" threat model accepted for GHSA-pf56.

Reachability trace

index.ts:43 attachArtifactToImage() -> new OCIImage(...).addArtifact() -> image.ts:67 this.#client.signIn(credentials) (installs the default Authorization header) -> image.ts:76/79 this.#client.uploadBlob(...) -> registry.ts:198 PUT to the response-supplied Location with the default Authorization header attached. Same RegistryClient instance throughout, so the default persists.

Reproduction

Source-verified. No live push against a hostile registry was executed in this pass. Confirmed:

rg -n "defaults\(|HEADER_AUTHORIZATION|Location|new URL\(|this.#fetch\(uploadLocation" packages/oci/src/registry.ts
git log --oneline -3 -- packages/oci/src/credentials.ts packages/oci/src/registry.ts

signIn() sets Authorization via .defaults(); uploadBlob() PUTs to uploadLocation.href (which may be an absolute cross-host URL) with no host check; the GHSA-pf56 fix commit is the latest change to credentials.ts, while registry.ts has only dependency bumps since.

Suggested fix

Do not send the registry Authorization (or creds.headers) to an upload Location on a different host. Compare uploadLocation.host (and require https) against the registry host before the PUT; if it differs, issue the PUT without the credential (matching how registries that redirect to pre-signed storage URLs expect the upload to be unauthenticated), or explicitly re-authenticate for that host. More generally, avoid attaching the credential via a client-wide .defaults() and instead attach it per-request only to the registry host.

How it was found and a note on tooling

Every place @sigstore/oci was traced to attach a credential to an outbound request and checked whether the request host can be steered by a server response. The blob-upload Location path attaches the client-default Authorization to a PUT whose host comes from the registry response, with no host-equality check, and the GHSA-pf56 fix touched only the credential-selection code, not this send path. I used AI assistance for the trace and drafting and manually verified the cited lines and the fix scope at HEAD 3a83271. Verification is source-only; I did not execute a push against a hostile registry.

Independent re-verification at HEAD (2026-07-31)

Re-read at HEAD 3a83271. Unchanged, and the two halves sit in the same file:

126-127: this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: `Basic ${basicAuth}` } })
145-146: this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: `Bearer ${token}` } })
104:     this.#fetch = this.#fetch.defaults({ headers: creds.headers })

and in uploadBlob():

const uploadLocation = new URL(
  location.startsWith('/') ? `${this.#baseURL}${location}` : location
);
...
await this.#fetch(uploadLocation.href, { method: 'PUT', ... });

The ternary is the whole issue. A relative Location is anchored to #baseURL, but an absolute one is
passed to new URL() verbatim, so its host is whatever the registry response said. There is no comparison
against the registry host or scheme before the PUT, and because the credential was installed with
.defaults() rather than passed per-request, it is attached automatically.

Worth separating from the redirect case: the HEAD at the top of uploadBlob() uses
redirect: 'follow', and the fetch layer does strip Authorization across hosts on redirects it follows
itself. That protection does not apply here, because the PUT is a fresh explicit call the library makes to
a URL it parsed out of a response body header, not a redirect being followed.

This has not been executed against a hostile registry, so the leak is traced from the source rather than
observed on the wire. The control flow above is unambiguous, but it is better to state the limit than imply
a packet capture that has not been created.