TL;DR: CVE-2026-48815 in sigstore <= 4.1.0 let JavaScript callers pass certificateOIDs at the API boundary without those constraints reaching verification, so OID-based trust policy could silently fail even when signatures and issuer checks passed, according to Corgea. The lesson is that artifact trust is only as strong as the policy conditions that actually survive into the verifier.
At a glance
What this is: CVE-2026-48815 shows that sigstore <= 4.1.0 could accept certificateOIDs in JavaScript code yet fail to enforce them during verification, weakening OID-bound trust policy.
Why it matters: It matters because release gates, admission checks, and artifact validation workflows often rely on certificate extensions to narrow who can sign, and silent policy loss widens that trust boundary.
Context
CVE-2026-48815 is a policy-enforcement failure in a software supply-chain control, not a cryptographic break. The weakness sits in the gap between what JavaScript callers believed they were requiring and what the verifier actually checked, which is exactly the kind of boundary error that makes trust decisions drift from code intent.
For identity and access teams, the relevant lesson is that certificate extensions function as signer identity constraints when they are part of the verification path. If those constraints vanish before evaluation, the system still authenticates a signer but no longer proves that the signer matches the intended workload, issuer, or release context.
This is typical of modern pipeline trust failures: teams assume a documented control parameter is enforced because it is accepted by the API, but the real decision boundary is deeper in the library stack.
Key questions
Q: What breaks when certificateOIDs are accepted but not enforced in Sigstore verification?
A: The trust boundary breaks because the application believes it is restricting which certificates may sign an artifact, while the verifier silently evaluates a broader policy. Signature and issuer checks can still pass, so the workflow may accept a signer shape that the caller meant to exclude.
Q: Why do certificate extension checks matter in supply-chain verification?
A: They narrow the set of valid certificates to the signer identities a workflow actually intends to trust. Without extension checks, a certificate can still be technically valid while representing the wrong workload, issuer profile, or release context, which weakens admission and release gating decisions.
Q: What are the signs that a verification library is dropping policy constraints?
A: The most obvious sign is a mismatch between the policy fields your code sets and the fields present in the final verifier object. If a trust knob exists in the API but disappears from the built policy, the control is not being enforced and should be treated as absent.
Q: Should teams rely on signature validation alone for artifact trust?
A: No. Signature validation proves that a certificate and private key were involved, but it does not prove that the signer matched the exact identity constraints your workflow expected. Teams should require enforced issuer, subject, and certificate-extension checks where trust decisions depend on them.
Technical breakdown
How the certificateOIDs boundary failed in sigstore
The vulnerable flow accepted certificateOIDs in the public JavaScript API, then omitted them when building the internal verification policy. That means the caller could express a certificate extension requirement, review it in code, and still end up with a policy that only carried issuer and subject fields. In practice, this is a control translation failure: policy intent exists at the interface, but the verifier never receives it in executable form. When verification libraries are used inside build systems, admission checks, or release gates, that gap turns a narrow trust rule into a broader one than the application owner expected.
Practical implication: Treat API acceptance as untrusted until you confirm the same constraint is enforced at verifier execution time.
Why OID-based signer trust matters for supply-chain controls
OID checks are commonly used to distinguish one certificate shape from another, such as a specific workload identity, issuer profile, or extension value. In supply-chain workflows, that matters because a valid signature alone may still come from the wrong signer class if the certificate extension boundary is not enforced. The risk is not that cryptography fails, but that the policy no longer constrains which valid certificates are acceptable. That is a governance problem as much as a technical one, because release approval logic often depends on those constraints being true.
Practical implication: Map any certificate-extension requirement to the exact verification step that enforces it, not just to the caller configuration.
What changed in the 4.1.1 enforcement path
The fixed path serializes the OID pairs into policy and then compares them against the signer certificate extensions during verification. That is the critical architectural shift: the constraint moves from caller input to verifier logic, where it can actually block an unapproved signer. For teams operating JavaScript build or release tooling, this is also a reminder that transitive dependencies can hide trust-boundary regressions. If a wrapper or dependency chain still pins the vulnerable version, the apparent policy control remains fragile even when the surrounding pipeline looks healthy.
Practical implication: Upgrade the library wherever verification runs and revalidate any trust decisions made under the vulnerable version.
Threat narrative
Attacker objective: Cause an artifact signed with an unintended certificate shape to be accepted by a workflow that believed it was enforcing tighter signer constraints.
- Entry occurs when a JavaScript application passes certificateOIDs into sigstore.verify() or createVerifier() on a vulnerable version.
- Credential or signer restriction is lost because the OID map never reaches the internal verification policy.
- A broader set of certificates can satisfy the remaining issuer and subject checks, allowing an unintended signer shape to pass.
- The impact is a trust-policy bypass in build, release, or admission workflows that rely on OID-bound verification.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
This is a trust-policy translation failure, not a cryptographic failure. The important problem is that the application expressed a signer constraint that never survived into the verifier. In governance terms, the control existed as configuration intent but not as an enforced boundary, which is exactly where identity and supply-chain assurance fails. Practitioners should treat this as a verifier integrity issue, not a signature algorithm issue.
OID-bound verification is a signer identity control, and that makes this an identity problem as much as a supply-chain problem. Certificate extensions are often used to narrow acceptable workload or release identities. When those checks disappear, the system still sees a certificate, but it no longer proves the intended identity of the signer. That distinction matters for NHI governance because machine and workload trust often depends on extension-level assertions, not just on a valid public key.
Policy acceptance at the API boundary is not control enforcement. Security teams routinely assume that a named option in a library reflects an active control, but library internals can silently drop that option. That creates governance debt because reviewers, auditors, and platform teams think the trust model is tighter than it really is. The practical conclusion is simple: verify that every signer constraint is preserved all the way to evaluation.
Artifact trust needs explicit boundary testing, not version awareness alone. Knowing that a package is patched is useful, but the real assurance question is whether your code ever depended on an enforcement path that was absent in older versions. In release and admission pipelines, teams should validate not just the version number but the specific certificate conditions that the verifier actually checks.
Certificate extension checks are part of workload identity governance. When those checks vanish, the organisation loses the ability to distinguish acceptable machine identities from merely valid ones. That raises the bar for NHI policy design because the control objective is not just authentication, but authenticated identity narrowing. Practitioners should treat extension enforcement as a mandatory part of trust architecture, not an optional enhancement.
From our research library:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
- Read next: Machine Identity, PKI and Certificate Lifecycle Guide
What this signals
Certificate-extension enforcement is a workload identity control, not a cosmetic verifier option. If a pipeline depends on OID-bound certificates, the organisation has to prove that the condition survives all the way into evaluation, otherwise the trust model is wider than the policy review suggests. That is a classic governance gap in NHI-adjacent supply-chain controls.
Named concept: policy-boundary drift. This is what happens when a security requirement is accepted at the interface but lost before the decision point. The implication for practitioners is to test the full verifier path, not just the configuration surface, whenever certificate-based trust controls are part of release governance.
For practitioners
- Upgrade every vulnerable sigstore dependency Move sigstore to 4.1.1 or later anywhere JavaScript verification runs, including transitive dependencies and wrapper libraries that call sigstore.verify() or createVerifier().
- Re-run affected artifact decisions Review prior release, admission, and dependency-approval decisions that depended on certificateOIDs so you can determine whether a broader signer set may have been accepted.
- Audit trust-policy code paths for dropped constraints Inspect verification helpers, custom wrappers, and shared pipeline libraries to confirm certificate extension requirements survive from caller input into the final verifier policy.
Key takeaways
- CVE-2026-48815 shows how a verifier can accept a security constraint and still fail to apply it, leaving a trust policy broader than the application intended.
- The practical risk is not a broken signature primitive but a missing enforcement boundary that can let unintended signers satisfy the remaining checks.
- Teams should upgrade vulnerable versions and revalidate any release or admission decisions that depended on certificate extension enforcement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | OID checks failing at verification time weaken certificate-based signer authentication. |
| NHI-05 — Overprivileged NHI | Dropped OID constraints widen which machine identities can pass trust gates. | |
| Recommendation — Verify that certificate-bound authentication rules survive into the final verifier before approving artifacts. Constrain acceptable signer identities so verification logic cannot admit a broader certificate class than intended. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | The issue concerns authentication of external signing identities via certificates. |
| Recommendation — Apply IA-9 to ensure certificate-based authenticator requirements are actually enforced at verification time. | ||
| CIS Controls v8 | CIS-5 — Account Management | The control gap affects lifecycle governance over non-human signing identities. |
| Recommendation — Inventory and govern signing identities so policy checks do not rely on unenforced certificate attributes. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The flaw enables unintended signer credentials to pass trust gates and move into release paths. |
| Recommendation — Map verification bypasses to credential access and lateral movement risks in your supply-chain detection logic. | ||
Key terms
- Certificate Extension: A certificate extension is an additional field that adds identity, usage, or policy information to a digital certificate. In supply-chain trust workflows, extensions often narrow which workload, issuer, or signer profile is acceptable for a specific verification decision.
- Verification Policy: Verification policy is the set of rules that determines whether an identity credential will be accepted at authentication or onboarding. In wallet environments, the policy must specify trusted issuers, acceptable standards, revocation checks, and fallback handling, or assurance becomes inconsistent across ecosystems.
- OID-Bound Trust: OID-bound trust is a verification approach that uses object identifiers in certificate extensions to restrict which signers are acceptable. It is useful when a general valid certificate is not specific enough to prove the intended workload or release identity.
- 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.
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 helps practitioners connect workload identity controls to the broader trust decisions their programmes depend on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org