CVE-2026-48816

What it actually does

@sigstore/verify versions before 3.1.1 can make trust decisions using tlogEntries[].integratedTime from Sigstore bundle v0.2 inclusionProof-only entries even though that timestamp is not cryptographically bound by the inclusion proof. If an attacker can provide an untrusted Sigstore bundle to a verifier, they can alter the effective transparency-log timestamp used for certificate-validity and timestamp-threshold checks. The core impact is integrity: a verifier may accept an artifact/signature combination that should have been rejected because the claimed transparency-log time is not trustworthy.

Why it matters to the business

Systems that rely on Sigstore verification for software supply-chain controls may incorrectly accept tampered or otherwise noncompliant artifacts, weakening release, dependency, and deployment gates. This could allow unauthorized code or packages to pass automated trust checks, creating downstream risk for product integrity, incident response, and compliance evidence. Public exploitation is not currently indicated, the issue is not in CISA KEV, and EPSS is low, but organizations using sigstore-js in CI/CD or artifact validation should still prioritize remediation because the affected component is used specifically to enforce software provenance and integrity.

How an attack unfolds

An attacker first needs a path to submit or influence a Sigstore bundle that a target verifier treats as input, such as through a build pipeline, artifact registry workflow, package ingestion process, or deployment approval check. The attacker crafts or modifies a bundle v0.2 entry that uses an inclusionProof-only transparency-log representation and sets tlogEntries[].integratedTime to a value advantageous to the attack. Because vulnerable @sigstore/verify versions treat that field as authoritative for certain verification decisions even though it is not cryptographically bound to the proof, the attacker can influence checks that depend on signing time, certificate validity, or timestampThreshold policy. If the manipulated timestamp causes the verifier to consider the certificate and signature valid, the artifact may pass an integrity gate that should have failed.

How to fix it

Upgrade @sigstore/verify to version 3.1.1 or later wherever it is used directly or transitively. If consuming the broader sigstore-js ecosystem, update dependent Sigstore packages and regenerate lockfiles so the resolved @sigstore/verify version is fixed. For npm-based projects, review package-lock.json, npm-shrinkwrap.json, yarn.lock, or pnpm-lock.yaml for vulnerable @sigstore/verify resolutions and use package-manager overrides or resolutions if a transitive dependency has not yet updated. As a defense-in-depth measure, avoid accepting Sigstore bundles from untrusted sources without independent policy controls, and consider revalidating transparency-log metadata against the log service or trusted inclusion material for high-risk artifacts processed before the upgrade.

How to confirm the fix worked

Confirm the deployed dependency tree resolves @sigstore/verify to 3.1.1 or later using package-manager inspection commands such as npm ls @sigstore/verify, yarn why @sigstore/verify, or pnpm why @sigstore/verify. Verify all build images, CI runners, release tools, artifact-verification services, and developer tooling have rebuilt with updated lockfiles. Run regression tests that verify Sigstore bundles around certificate validity and timestamp-threshold boundary conditions, especially bundle v0.2 inclusionProof-only cases. For exposure assessment, search repositories and built artifacts for vulnerable @sigstore/verify versions and identify workflows that process externally supplied Sigstore bundles.

Typical attack path

1. Identify a workflow that accepts Sigstore bundles from an untrusted or semi-trusted source.
2. Prepare an artifact and associated signature/bundle intended to be evaluated by sigstore-js @sigstore/verify before version 3.1.1.
3. Use a Sigstore bundle v0.2 structure with an inclusionProof-only transparency-log entry.
4. Manipulate tlogEntries[].integratedTime to satisfy certificate validity or timestampThreshold checks.
5. Submit the bundle to the vulnerable verification workflow.
6. Rely on the verifier accepting the manipulated timestamp and approving an artifact that should have failed policy.

How to detect it

This vulnerability does not create a reliable host-level or network-level compromise indicator by itself; exploitation would usually appear as a questionable artifact-verification decision rather than a distinctive process, file, or connection. To investigate possible prior exploitation, review CI/CD logs, artifact promotion records, release approval logs, package ingestion events, and application logs from systems that used @sigstore/verify before 3.1.1. Focus on verifications involving Sigstore bundle v0.2 entries with inclusionProof-only transparency-log material and compare the bundle's tlogEntries[].integratedTime against authoritative transparency-log data where available. Re-query the relevant transparency log using log ID, log index, UUID, or entry hash from archived bundles and look for mismatches or suspicious timestamps that make an otherwise invalid certificate, signature, or timestampThreshold policy pass. Also review deployments or artifact promotions accepted shortly before or after certificate validity boundaries, policy cutoff times, or unexpected source changes. No named threat actors, ransomware use, or KEV exploitation is currently reported for this issue.

What your security team should do

• Inventory all applications, CI/CD jobs, release tooling, artifact registries, and dependency-scanning services that use sigstore-js or @sigstore/verify.
• Upgrade @sigstore/verify to 3.1.1 or later and rebuild any containers or CI images that package the vulnerable dependency.
• Treat workflows that verify externally supplied Sigstore bundles as higher priority than workflows that only verify internally generated bundles.
• Audit artifacts accepted before remediation where verification depended on Sigstore bundle v0.2 inclusionProof-only entries, especially near certificate-expiration or policy-threshold boundaries.
• Add software composition analysis checks for @sigstore/verify versions below 3.1.1 in source repositories and build outputs.
• Where feasible, preserve Sigstore verification inputs and results in CI/CD logs to support future provenance investigations.