GHSA-J63V-MWHM-56JX
Vulnerability from github – Published: 2026-10-30 23:00 – Updated: 2026-10-30 23:00Summary
@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), pluscreds.headersfrom the Docker config (:104).uploadBlob()reads theLocationresponse header (:184), buildsuploadLocation = 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.7.1"
},
"package": {
"ecosystem": "npm",
"name": "@sigstore/oci"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-118763"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-30T23:00:17Z",
"nvd_published_at": "2026-10-29T17:18:07Z",
"severity": "HIGH"
},
"details": "### Summary\n\n@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location\n\n## Affected versions and vulnerable location\n\n- Confirmed on sigstore-js at `3a83271` (current HEAD).\n- File: `packages/oci/src/registry.ts`.\n - `signIn()` installs the credential as a DEFAULT header on the shared client: `this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: \u0027Basic \u0027 + basicAuth } })` (`:126-128`) or `... \u0027Bearer \u0027 + token` (`:145-147`), plus `creds.headers` from the Docker config (`:104`).\n - `uploadBlob()` reads the `Location` response header (`:184`), builds `uploadLocation = new URL(location.startsWith(\u0027/\u0027) ? this.#baseURL + location : location)` (`:190-192`), and PUTs the blob to it through the same client: `await this.#fetch(uploadLocation.href, { method: \u0027PUT\u0027, body: blob, headers: { [HEADER_CONTENT_TYPE]: ... } })` (`:198`).\n- There is no check that `uploadLocation`\u0027s host (or scheme) equals the registry host before the PUT is sent.\n\n## Root cause\n\nBecause `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.\n\nThe library\u0027s HTTP layer (`make-fetch-happen` / `minipass-fetch`) strips `Authorization` on cross-host redirects it follows internally, which protects the `HEAD ... { redirect: \u0027follow\u0027 }` 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.\n\nThis 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.\n\n## Attacker model\n\nA 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.\n\n## Reachability trace\n\n`index.ts:43 attachArtifactToImage()` -\u003e `new OCIImage(...).addArtifact()` -\u003e `image.ts:67 this.#client.signIn(credentials)` (installs the default Authorization header) -\u003e `image.ts:76/79 this.#client.uploadBlob(...)` -\u003e `registry.ts:198` PUT to the response-supplied `Location` with the default Authorization header attached. Same `RegistryClient` instance throughout, so the default persists.\n\n## Reproduction\n\nSource-verified. No live push against a hostile registry was executed in this pass. Confirmed:\n\n```bash\nrg -n \"defaults\\(|HEADER_AUTHORIZATION|Location|new URL\\(|this.#fetch\\(uploadLocation\" packages/oci/src/registry.ts\ngit log --oneline -3 -- packages/oci/src/credentials.ts packages/oci/src/registry.ts\n```\n\n`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.\n\n## Suggested fix\n\nDo 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.\n\n## How it was found and a note on tooling\n\nEvery 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.\n\n## Independent re-verification at HEAD (2026-07-31)\n\nRe-read at HEAD `3a83271`. Unchanged, and the two halves sit in the same file:\n\n```\n126-127: this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: `Basic ${basicAuth}` } })\n145-146: this.#fetch = this.#fetch.defaults({ headers: { [HEADER_AUTHORIZATION]: `Bearer ${token}` } })\n104: this.#fetch = this.#fetch.defaults({ headers: creds.headers })\n```\n\nand in `uploadBlob()`:\n\n```ts\nconst uploadLocation = new URL(\n location.startsWith(\u0027/\u0027) ? `${this.#baseURL}${location}` : location\n);\n...\nawait this.#fetch(uploadLocation.href, { method: \u0027PUT\u0027, ... });\n```\n\nThe ternary is the whole issue. A relative `Location` is anchored to `#baseURL`, but an absolute one is\npassed to `new URL()` verbatim, so its host is whatever the registry response said. There is no comparison\nagainst the registry host or scheme before the PUT, and because the credential was installed with\n`.defaults()` rather than passed per-request, it is attached automatically.\n\nWorth separating from the redirect case: the `HEAD` at the top of `uploadBlob()` uses\n`redirect: \u0027follow\u0027`, and the fetch layer does strip `Authorization` across hosts on redirects it follows\nitself. That protection does not apply here, because the PUT is a fresh explicit call the library makes to\na URL it parsed out of a response body header, not a redirect being followed.\n\nThis has not been executed against a hostile registry, so the leak is traced from the source rather than\nobserved on the wire. The control flow above is unambiguous, but it is better to state the limit than imply\na packet capture that has not been created.",
"id": "GHSA-j63v-mwhm-56jx",
"modified": "2026-10-30T23:00:18Z",
"published": "2026-10-30T23:00:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-118763"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/pull/1762"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/sigstore-js"
},
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.