Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 272/272 feeds/APIs · 469/469 docs · 7/9 advisories · checked 05:36 UTC Customize Public modeDiscuss ChangeIntel on Discord

sigstore's `certificateOIDs` verification constraints are silently dropped and never enforced

Exact source revision recorded 24 Oct 2026 13:17:17 UTC. It does not establish the source's current position. Latest evidence.

osv · GHSA-52v5-jr5w-gjxr

Published

### Summary 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 ```javascript const { createVerificationPolicy } = require("sigstore/dist/config"); const policy = createVerificationPolicy({ certificateIssuer: "https://issuer.example", certificateIdentityEmail: "[email protected]", certificateOIDs: { "1.2.3.4": "required-value", }, }); console.log("certificateOIDs" in policy, JSON.stringify(policy)); // false {"subjectAlternativeName":"[email protected]","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.

Source published
1 Jul 2026 19:58:28 UTC
Source modified
10 Sep 2026 03:50:12 UTC
Observed here
24 Oct 2026 13:17:17 UTC
Source terms
GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Publisher rating · HIGH

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 27 Oct 05:36 UTC · 272 of 272 readable · 271 fully read · documentation 469/469 current