Vulnerability-Lookup

CVE-2026-118763 (GCVE-0-2026-118763)

Vulnerability from cvelistv5 – Published: 2026-10-29 17:01 – Updated: 2026-10-30 17:13

Title

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

Summary

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin.

Severity

7.4 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-30 15:20 UTC

CWE

CWE-522 - Insufficiently Protected Credentials

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 8129 records in the last 180 days details

References

5 references

URL	Tags
https://github.com/sigstore/sigstore-js/security/…	x_refsource_CONFIRM
https://github.com/sigstore/sigstore-js/pull/1762	x_refsource_MISC
https://github.com/sigstore/sigstore-js/commit/b8…	x_refsource_MISC
https://github.com/sigstore/sigstore-js/commit/e4…	x_refsource_MISC
https://github.com/sigstore/sigstore-js/releases/…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version	CPE status
sigstore	sigstore-js	Affected: < 0.7.2	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-118763",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T15:20:32.038162Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-30T17:13:12.761Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "sigstore-js",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.7.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 7.4,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "REQUIRED",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-522",
              "description": "CWE-522: Insufficiently Protected Credentials",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-29T17:01:40.294Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx"
        },
        {
          "name": "https://github.com/sigstore/sigstore-js/pull/1762",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-js/pull/1762"
        },
        {
          "name": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1"
        },
        {
          "name": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558"
        },
        {
          "name": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2"
        }
      ],
      "source": {
        "advisory": "GHSA-j63v-mwhm-56jx",
        "discovery": "UNKNOWN"
      },
      "title": "@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-118763",
    "datePublished": "2026-10-29T17:01:40.294Z",
    "dateReserved": "2026-10-28T19:20:05.017Z",
    "dateUpdated": "2026-10-30T17:13:12.761Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-118763",
      "date": "2026-10-31",
      "epss": "0.003",
      "percentile": "0.22728"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "sigstore-js",
                "vendor": "sigstore",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003c 0.7.2"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin."
          }
        ],
        "id": "CVE-2026-118763",
        "lastModified": "2026-10-30T19:39:14.897",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 7.4,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "CHANGED",
                "userInteraction": "REQUIRED",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 2.8,
              "impactScore": 4.0,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-118763",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-30T15:20:32.038162Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-10-29T17:18:07.230",
        "references": [
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/sigstore-js/pull/1762"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2"
          },
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Deferred",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-522"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-118763",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-30T15:20:32.038162Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-30T15:20:32.819Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "sigstore-js",
              "vendor": "sigstore",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 0.7.2"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "NONE",
                "baseScore": 7.4,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "CHANGED",
                "userInteraction": "REQUIRED",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-522",
                  "description": "CWE-522: Insufficiently Protected Credentials",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-29T17:01:40.294Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx"
            },
            {
              "name": "https://github.com/sigstore/sigstore-js/pull/1762",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/sigstore/sigstore-js/pull/1762"
            },
            {
              "name": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1"
            },
            {
              "name": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558"
            },
            {
              "name": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2"
            }
          ],
          "source": {
            "advisory": "GHSA-j63v-mwhm-56jx",
            "discovery": "UNKNOWN"
          },
          "title": "@sigstore/oci sends the registry Authorization header to a cross-host blob-upload Location"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2026-118763",
        "datePublished": "2026-10-29T17:01:40.294Z",
        "dateReserved": "2026-10-28T19:20:05.017Z",
        "dateUpdated": "2026-10-29T17:01:40.294Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

FKIE_CVE-2026-118763

Vulnerability from fkie_nvd - Published: 2026-10-29 17:18 - Updated: 2026-10-30 19:39

Severity

7.4 (High) - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1
	security-advisories@github.com	https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558
	security-advisories@github.com	https://github.com/sigstore/sigstore-js/pull/1762
	security-advisories@github.com	https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2
	security-advisories@github.com	https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "sigstore-js",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.7.2"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 0.7.2, packages/oci/src/registry.ts contains a RegistryClient.signIn() method that stores registry Authorization and Docker configuration headers as defaults on a shared HTTP client, while RegistryClient.uploadBlob() sends a fresh PUT to an absolute blob-upload Location supplied by the registry without checking that its origin or scheme matches the registry. A malicious or compromised registry can therefore direct a user pushing an artifact through attachArtifactToImage() to an attacker-controlled host and receive the registry bearer token, Basic credentials, or custom authentication headers. Redirect-time header stripping does not prevent the leak because the cross-host PUT is a new explicit request rather than a followed redirect. This is a residual of CVE-2026-59891, whose fix changed credential selection in credentials.ts but did not constrain where credentials are sent from registry.ts. Version 0.7.2 fixes the issue by separating registry credentials from client-wide defaults and sending them only to the registry origin."
    }
  ],
  "id": "CVE-2026-118763",
  "lastModified": "2026-10-30T19:39:14.897",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.4,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "NONE",
          "privilegesRequired": "NONE",
          "scope": "CHANGED",
          "userInteraction": "REQUIRED",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.8,
        "impactScore": 4.0,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-118763",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-30T15:20:32.038162Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-29T17:18:07.230",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sigstore/sigstore-js/commit/b855f46cfe81f26481c6d3f4b333dfd00f2fd1b1"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sigstore/sigstore-js/commit/e4ca65c3ab3c675456ab9b0bd04217ceccad3558"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sigstore/sigstore-js/pull/1762"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sigstore/sigstore-js/releases/tag/@sigstore/oci@0.7.2"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-j63v-mwhm-56jx"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Deferred",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-522"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

GHSA-J63V-MWHM-56JX

Vulnerability from github – Published: 2026-10-30 23:00 – Updated: 2026-10-30 23:00

Summary

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

Details

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.

Severity

7.4 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "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"
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

CVE-2026-118763 (GCVE-0-2026-118763)

FKIE_CVE-2026-118763

GHSA-J63V-MWHM-56JX

Summary

Affected versions and vulnerable location

Root cause

Attacker model

Reachability trace

Reproduction

Suggested fix

How it was found and a note on tooling

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

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour