### 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.
### 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.
Update sigstore to 4.1.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansigstore's `certificateOIDs` verification constraints are silently dropped and never enforced affects sigstore (npm). Severity is high. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| sigstorenpm | <=4.1.0 | 4.1.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate sigstore to 4.1.1 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scansigstore's `certificateOIDs` verification constraints are silently dropped and never enforced affects sigstore (npm). Severity is high. ### 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| sigstorenpm | <=4.1.0 | 4.1.1 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard