CVE-2026-48815 shows how Sigstore OID checks can vanish

At a glance

What this is: This advisory shows that sigstore <= 4.1.0 accepted certificateOIDs in JavaScript policy code but did not enforce them in verification.

Why it matters: It matters to IAM and NHI practitioners because trust policy for build, release, and admission gates can look narrower in code than it is at runtime.

By the numbers:

• Only 38% have automated certificate lifecycle management in place.
• 57% of organisations lack a complete inventory of their machine identities.
• Certificate expiry is the leading cause of outages for 45% of organisations.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

👉 Read Corgea's analysis of CVE-2026-48815 and sigstore policy enforcement

Context

CVE-2026-48815 is a policy-enforcement failure in a JavaScript verification library, not a cryptographic break. The primary problem is the gap between what application code believes it requested and what the verifier actually enforces, which is a familiar risk pattern in identity and access governance as well as in software supply chain controls.

In build, release, and admission workflows, certificate constraints often act as the narrowest trust filter for workload identity and signer identity. When those constraints are parsed but dropped, teams may still see valid signatures while losing the policy boundary they relied on to distinguish approved signers from merely valid ones.

For IAM and NHI programmes, this is an intersection point between workload identity, certificate governance, and policy assurance. The issue is atypical in that the failure is not missing configuration at the caller, but a library path that silently failed to carry the control forward.

Key questions

Q: What breaks when certificate policy is only documented and not enforced?

A: The organisation gets inconsistent issuance, weak cryptography, and renewal behaviour that depends on human memory instead of control design. Document-only policy does not stop an engineer from choosing the wrong template or extending validity beyond acceptable bounds. Enforced policy is what prevents bad trust decisions from entering production in the first place.

Q: Why do certificate extension OIDs matter in workload identity verification?

A: They let teams distinguish one otherwise valid certificate from another based on workflow, issuer, or signer shape. Without them, verification may rely only on generic certificate validity, which is often too broad for build gates, admission controls, and release approvals. That weakens identity assurance for machine and workload identities.

Q: How do security teams know if a verification library is actually enforcing policy?

A: They need tests that exercise the policy object end to end, not just tests that the API accepts the expected parameters. A good check proves that the verifier rejects bundles when the expected issuer, subject, or extension values are missing. If a field disappears between input and enforcement, the control is not real.

Q: What should teams do when a trust-policy bug affected past approvals?

A: They should identify the affected verifier versions, replay recent decisions, and reapprove any artefacts that depended on the broken control path. Historical approvals are not automatically invalid, but they are suspect if the decision relied on an option the library did not enforce. That is especially important for release and admission gates.

Technical breakdown

How certificateOIDs should constrain trust policy

In a verification workflow, certificate OIDs are intended to add a second identity layer on top of issuer and subject checks. They let a team say that a valid signer must not only chain to the right issuer, but also present the expected certificate extension values that distinguish a workload, workflow, or signing role. That is especially useful in build and admission systems where generic validity is too broad. In CVE-2026-48815, the public API accepted those constraints, but the policy object built for verification did not preserve them. The result is a narrower policy in source code than in runtime enforcement.

Practical implication: review any verification wrapper that assumes OID-bound signer restrictions are being enforced because the API accepted them.

Why dropped policy fields create a trust-boundary bypass

Policy bugs are dangerous when they fail closed in documentation but open at runtime. Here, signature validation, issuer checks, and subject identity checks could still succeed, so the control appeared to work while the most specific trust condition disappeared. That means a bundle can satisfy the remaining rules even if the required certificate extensions are absent or wrong. In supply-chain terms, the issue is not just a missing metadata field. It is an authorization boundary problem, because the system is authorising a signer on a broader basis than the application intended.

Practical implication: treat verification libraries as security controls that need control-path testing, not just dependency version testing.

What changed in sigstore 4.1.1

The fix translated certificateOIDs into verifier policy and then explicitly compared expected OIDs against signer certificate extensions. That shift matters because it moves the constraint from caller intent into the verification decision itself. The same release train also addressed a separate timestamp trust issue, which is another reminder that provenance tooling can contain more than one trust boundary. For teams using transitive dependencies, the relevant question is not whether sigstore is present somewhere in the graph, but whether any live policy decision depends on extension checks that older versions ignored.

Practical implication: upgrade every runtime path that performs certificate-based verification and re-run any controls that relied on OID restrictions.

Threat narrative

Attacker objective: The objective is to get an unapproved signer accepted by a release, build, or admission gate that should have rejected it.

1. Entry occurs when an attacker or untrusted signer produces a bundle that already satisfies the remaining signature, issuer, and SAN checks.
2. Escalation happens when the application believes certificateOIDs are narrowing the trust decision, but the verifier silently ignores them.
3. Impact is a successful trust-policy bypass, allowing a signer to pass verification without the required certificate extension values.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• JetBrains Marketplace AI Plugin Campaign — 15 malicious JetBrains Marketplace plugins steal AI API keys from 70,000+ developers via supply chain attack.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Policy knobs are not control boundaries unless the verifier actually enforces them. CVE-2026-48815 is a textbook example of a trust condition that existed in code, documentation, and operator intent, but not in runtime enforcement. That gap is especially dangerous in identity and supply-chain tooling because teams often assume validation options are equivalent to policy. The practitioner lesson is to test the control path, not the configuration syntax.

Certificate extension governance is becoming part of machine identity governance. When build and admission systems rely on certificate OIDs to distinguish one workload identity from another, those OIDs function like an identity attribute. If the verifier drops them, the programme has an identity assurance gap, not just a software defect. This makes OWASP-NHI and NIST control alignment relevant even in JavaScript supply-chain code.

Trusted provenance can still be over-broad provenance. The bug reinforces a named concept we see repeatedly in supply-chain identity work: policy-to-enforcement drift: the requested trust rule is narrower than the rule that actually governs the decision. Once that drift exists, code review alone is insufficient because the source looks compliant while runtime behaviour is not. The conclusion is to validate that policy fields survive into the enforcement engine.

Dependency graph risk now includes verification semantics, not just vulnerable packages. Organisations increasingly consume transitive trust libraries as infrastructure, which means an unnoticed API boundary failure can affect many downstream gates at once. That broadens the blast radius beyond a single repository. Practitioners should treat verification libraries as shared identity infrastructure and manage them accordingly.

Supply-chain controls need identity-style lifecycle oversight. Even when the issue is not a compromised certificate, the same operational disciplines apply: inventory, version pinning, runtime validation, and re-checking historical decisions after a fix. This is where machine identity governance and software supply-chain governance overlap in practice. Teams should assume that a silent enforcement gap can leave prior approvals open to question.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• For teams mapping policy drift to lifecycle risk, The 52 NHI breaches Report shows how overlooked identity controls turn into repeatable exposure patterns.

What this signals

Policy-to-enforcement drift is the risk signal here: teams increasingly express identity constraints in code, but the real control value depends on whether the runtime verifier preserves them. That should push IAM, PAM, and platform teams to test enforcement paths the same way they test authentication flows, especially when those paths govern build and admission decisions. The closer the control is to software supply chain gates, the more important it becomes to validate it like identity infrastructure.

Machine identity programmes should expect more overlap between certificate governance, workload identity, and software supply-chain validation. The operational signal is that teams cannot separate verification tooling from identity governance just because it sits in a developer workflow. Re-check whether your controls align with the NIST Cybersecurity Framework 2.0 and the NIST SP 800-207 Zero Trust Architecture model when trust decisions depend on certificate attributes.

When identity controls are embedded in libraries, the remediation burden spreads across versioning, policy documentation, and historical decision review. That creates a programme-level requirement to link dependency scanning with identity inventory and trust-policy review, because a vulnerable verifier can make a well-designed policy functionally invisible. The management lesson is simple: if the runtime cannot prove the control, the control does not exist.

For practitioners

• Inventory every live sigstore verification path Find all call sites using sigstore.verify() or createVerifier(), including transitive wrappers in build, release, admission, and artifact-validation services. Confirm whether any of them rely on certificateOIDs to distinguish approved signers, because those paths are the ones where policy drift matters most.
• Upgrade and pin the fixed version everywhere Move any JavaScript verification stack to sigstore 4.1.1 or later, then lock the version in package manifests, lockfiles, and deployment images. If transitive dependencies block the update, use an override or resolution until the parent dependency is rebuilt.
• Revalidate historical allow decisions Re-run artifact verification for recent release or admission decisions that depended on OID-bound signer policy. If the older library path was used, treat past approvals as potentially broader than intended and re-evaluate the affected artefacts.
• Add runtime tests for policy-field preservation Create a control test that asserts certificateOIDs survive policy construction and are rejected when the signer certificate lacks the expected extension values. Keep the test in CI so future dependency changes cannot silently reintroduce the same failure mode.

Key takeaways

• CVE-2026-48815 is a policy-enforcement bug, not a cryptographic flaw, and that distinction matters because the visible control was broader than the runtime control.
• The affected path is especially relevant to machine identity and supply-chain governance because certificateOIDs often serve as the narrowest trust condition for approved signers.
• Teams should upgrade, replay recent approvals, and add control-path tests so policy fields cannot disappear between application intent and verifier enforcement.

Key terms

• Policy Enforcement Drift: The gap between the access policy an organisation believes it has and the policy actually enforced at runtime. In proxy and edge systems, drift appears when configuration, plugins, failover, or bypass conditions cause the control to behave differently from the intended rule set.
• Certificate extension OID: A numeric identifier used to represent a certificate extension in X.509 and related identity workflows. Teams use OIDs to bind certificates to a specific signer shape, workload, issuer, or policy requirement, which makes them important when generic certificate validity is not specific enough for trust decisions.
• Verification policy boundary: The point at which trust decisions become enforced rather than merely expressed in code. In secure build and release systems, this boundary determines which issuer, subject, and certificate attributes are mandatory, and whether the gate truly blocks anything outside that set.
• Machine Identity: The digital identity of a machine, device, or workload — such as a server, container, or VM — used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

What's in the full article

Corgea's full article covers the operational detail this post intentionally leaves for the source:

• The exact vulnerable code path and proof-of-concept output showing how certificateOIDs disappeared during policy construction
• The 4.1.1 fix mechanics, including OID translation and enforcement against signer certificate extensions
• Dependency-scoping guidance for JavaScript package graphs that consume sigstore transitively
• Reference links to the advisory, NVD entry, and upstream patch history for validation work

👉 Corgea's full article covers the vulnerable code path, the fix boundary, and the dependency checks teams need to run.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity policy to operational control across modern security programmes.