GHSA-52V5-JR5W-GJXR
Vulnerability from github – Published: 2026-07-01 19:58 – Updated: 2026-07-01 19:58Summary
The documented certificateOIDs option in sigstore.verify() is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked.
Details
The public verify options include certificateOIDs and the documentation says those OID/value pairs “must be present in the certificate’s extension list.” The policy-construction path used by sigstore.verify() and createVerifier() only copies the SAN and issuer settings into the verification policy and completely ignores certificateOIDs.
As a result, callers can believe they are constraining verification to certificates carrying specific Fulcio or workload-identifying OIDs, while the actual verifier never receives those constraints. Any bundle that satisfies the remaining checks is accepted even if the required OID extensions are absent or mismatched.
This is reachable from supported usage through the documented certificateOIDs verify option.
PoC
const { createVerificationPolicy } = require("sigstore/dist/config");
const policy = createVerificationPolicy({
certificateIssuer: "https://issuer.example",
certificateIdentityEmail: "victim@example.com",
certificateOIDs: {
"1.2.3.4": "required-value",
},
});
console.log("certificateOIDs" in policy, JSON.stringify(policy));
// false {"subjectAlternativeName":"victim@example.com","extensions":{"issuer":"https://issuer.example"}}
Impact
Applications that rely on certificateOIDs to restrict which certificates may sign artifacts receive no such protection. Unauthorized certificates that should be rejected on extension policy can be accepted as long as they satisfy the remaining verification checks.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.1.0"
},
"package": {
"ecosystem": "npm",
"name": "sigstore"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48815"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T19:58:28Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThe documented `certificateOIDs` option in `sigstore.verify()` is accepted by the public API but discarded before verification, so required certificate extension OIDs are never checked.\n\n### Details\n\nThe public verify options include `certificateOIDs` and the documentation says those OID/value pairs \u201cmust be present in the certificate\u2019s extension list.\u201d The policy-construction path used by `sigstore.verify()` and `createVerifier()` only copies the SAN and issuer settings into the verification policy and completely ignores `certificateOIDs`.\n\nAs a result, callers can believe they are constraining verification to certificates carrying specific Fulcio or workload-identifying OIDs, while the actual verifier never receives those constraints. Any bundle that satisfies the remaining checks is accepted even if the required OID extensions are absent or mismatched.\n\nThis is reachable from supported usage through the documented `certificateOIDs` verify option.\n\n### PoC\n\n```javascript\nconst { createVerificationPolicy } = require(\"sigstore/dist/config\");\n\nconst policy = createVerificationPolicy({\n certificateIssuer: \"https://issuer.example\",\n certificateIdentityEmail: \"victim@example.com\",\n certificateOIDs: {\n \"1.2.3.4\": \"required-value\",\n },\n});\n\nconsole.log(\"certificateOIDs\" in policy, JSON.stringify(policy));\n// false {\"subjectAlternativeName\":\"victim@example.com\",\"extensions\":{\"issuer\":\"https://issuer.example\"}}\n```\n\n### Impact\n\nApplications that rely on `certificateOIDs` to restrict which certificates may sign artifacts receive no such protection. Unauthorized certificates that should be rejected on extension policy can be accepted as long as they satisfy the remaining verification checks.",
"id": "GHSA-52v5-jr5w-gjxr",
"modified": "2026-07-01T19:58:28Z",
"published": "2026-07-01T19:58:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-52v5-jr5w-gjxr"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/sigstore-js"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "sigstore\u0027s `certificateOIDs` verification constraints are silently dropped and never enforced"
}
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.