CVE-2026-48815

What it actually does

In sigstore-js versions prior to 4.1.1, the public sigstore.verify() API accepts the documented certificateOIDs option but drops it before performing certificate verification. As a result, required certificate extension object identifiers are not enforced. Applications that depend on certificateOIDs as an authorization control may treat signatures from otherwise valid Sigstore certificates as authorized even when the signing certificate does not contain the required extension OIDs. The primary impact is integrity loss through authorization bypass in artifact-signature verification workflows.

Why it matters to the business

Organizations using sigstore-js to gate software releases, dependency ingestion, container promotion, build provenance, or artifact deployment may incorrectly approve artifacts signed by identities that were not intended to be trusted. This can weaken software supply-chain controls and allow unauthorized code or packages to move through automated pipelines. The issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but affected deployments should still prioritize remediation because exploitation can directly undermine trust decisions in CI/CD and artifact validation systems.

How an attack unfolds

An attacker first identifies an application, build pipeline, artifact repository, or deployment gate that uses sigstore-js prior to version 4.1.1 and relies on the certificateOIDs option to restrict which certificates are allowed to sign artifacts. The attacker obtains or uses a valid Sigstore signing certificate that chains correctly but does not contain the certificate extension OIDs required by the target policy. They then sign a malicious or unauthorized artifact with that certificate and submit it to the affected verification workflow. Because the vulnerable library discards the certificateOIDs option before verification, the artifact may pass signature validation even though the certificate should have been rejected by policy. If downstream automation trusts the verification result, the unauthorized artifact can be accepted, promoted, published, or deployed.

How to fix it

Upgrade sigstore-js to version 4.1.1 or later wherever it is used directly or transitively. Review package manifests and lockfiles for vulnerable sigstore-js versions and refresh dependencies in CI/CD images, build tooling, release automation, artifact validation services, and developer workstations that perform signature verification. If immediate upgrade is not possible, do not rely on certificateOIDs as the sole authorization control; add an explicit post-verification certificate inspection step that confirms required extension OIDs are present before accepting an artifact. Rebuild and redeploy any long-lived tooling containers or runners that vendor Node.js dependencies. After patching, consider re-verifying recently accepted artifacts that were approved by workflows using vulnerable versions and certificateOIDs-based policy.

How to confirm the fix worked

Confirm that all relevant Node.js dependency trees resolve sigstore-js to 4.1.1 or later using package manager tooling such as npm ls sigstore, pnpm why sigstore, yarn why sigstore, or lockfile inspection. Search application and pipeline code for sigstore.verify() calls that use certificateOIDs and verify those paths run with the patched package. Add a regression test using a valid Sigstore certificate or verification bundle that lacks the required OID and confirm verification fails when certificateOIDs is configured. Validate that build agents, release containers, admission controllers, artifact scanners, and offline verification tools have been rebuilt with the corrected dependency. For high-assurance environments, reprocess recent verification logs and confirm artifacts accepted under the old verifier would still pass with sigstore-js 4.1.1 or later.

Typical attack path

1. Identify a CI/CD, package validation, container admission, or artifact promotion workflow using vulnerable sigstore-js versions before 4.1.1.
2. Determine that the workflow relies on sigstore.verify() with the certificateOIDs option to enforce signer authorization.
3. Create or obtain a valid Sigstore certificate that does not include the required certificate extension OIDs.
4. Sign an unauthorized artifact, package, container image, or provenance statement with that certificate.
5. Submit the signed artifact to the affected verification workflow.
6. The vulnerable verifier validates the certificate chain and signature but fails to enforce the required OID policy.
7. The artifact is accepted by downstream automation as trusted despite not meeting the intended authorization policy.

How to detect it

There is no universal network signature or process artifact that proves exploitation, because abuse appears as a successfully verified Sigstore artifact rather than a crash or obvious intrusion event. To assess prior exploitation, collect verification logs from CI/CD systems, artifact repositories, package publishing workflows, container promotion gates, admission controllers, and release automation that used sigstore-js before 4.1.1. Identify periods where sigstore.verify() was called with certificateOIDs configured, then re-verify the same artifacts using sigstore-js 4.1.1 or later and the intended OID policy. Investigate any artifact that was previously accepted but now fails due to missing certificate extension OIDs. Review Sigstore certificate metadata, Rekor transparency log entries where available, build provenance, source repository events, package publication events, and deployment records for unexpected signing identities, issuers, subjects, SAN values, or absent required extension OIDs. Treat accepted artifacts from unfamiliar signers, external contribution paths, unusual build runners, or anomalous release times as higher priority for forensic review.

What your security team should do

• Inventory all use of sigstore-js across source repositories, CI/CD runners, artifact validation services, release tooling, and container images.
• Prioritize upgrades to sigstore-js 4.1.1 or later for systems where signature verification determines whether software is published, promoted, or deployed.
• Search code for sigstore.verify() and certificateOIDs usage to identify workflows where this vulnerability has security relevance.
• Add automated dependency checks that fail builds on sigstore-js versions earlier than 4.1.1.
• Create a negative verification test case proving certificates without required extension OIDs are rejected.
• Review recently accepted artifacts that were verified by vulnerable workflows, especially those from external contributors, less-trusted build contexts, or automated promotion paths.
• Monitor Sigstore verification logs, artifact repository events, CI/CD approvals, and deployment records for artifacts signed by unexpected identities or certificates missing required policy OIDs.
• Document fallback controls for artifact authorization so certificate extension checks are not the only gate in critical release paths.