CVE-2026-48816: 
JavaScript vulnerability analysis and mitigation

CVE-2026-48816 is an Insufficient Verification of Data Authenticity vulnerability in the @sigstore/verify npm package (part of sigstore-js) that allows an attacker who can supply an untrusted bundle to manipulate timestamp-based verification decisions. The flaw affects @sigstore/verify version 3.1.0 and was fixed in version 3.1.1. It was first reported on May 27, 2026, published to the GitHub Advisory Database on July 1, 2026, and assigned CVE-2026-48816. The CVSS v3.1 base score is 6.5 (Medium) (Github Advisory, Feedly).

The root cause (CWE-345: Insufficient Verification of Data Authenticity) lies in how @sigstore/verify handles bundle v0.2 transparency log entries that are inclusionProof-only (i.e., lacking a signed inclusionPromise or inclusionPromise/set). The library derives a timestamp from tlogEntries[].integratedTime and uses it to validate certificate validity windows and satisfy timestampThreshold, but the inclusion proof path does not cryptographically bind integratedTime. Affected code paths include packages/verify/src/bundle/index.ts, packages/verify/src/timestamp/index.ts, packages/verify/src/verifier.ts, and packages/verify/src/tlog/index.ts. An attacker who can supply a crafted bundle v0.2 with a manipulated integratedTime value can influence certificate validity and timestampThreshold verification decisions without any cryptographic binding. A proof-of-concept (poc.zip) was included in the advisory demonstrating the behavior (Github Advisory, Fix PR).

Successful exploitation allows an attacker to influence time-based signature verification decisions in systems that accept attacker-provided bundle v0.2 inputs and rely on tlog-derived timestamps for certificate validity checks. This creates a trust gap where an unauthenticated integratedTime value is treated as a trusted observer timestamp, potentially allowing an attacker to make an expired or otherwise invalid certificate appear valid, or to bypass timestampThreshold requirements. There is no confidentiality or availability impact; the impact is entirely on integrity (CVSS Integrity: High), as verification outcomes can be manipulated to accept signatures that should be rejected (Github Advisory).

1. Identify a target application: Find an application that uses @sigstore/verify version 3.1.0 and accepts externally-supplied Sigstore bundle v0.2 inputs for signature verification.
2. Craft a malicious bundle: Construct a bundle v0.2 tlogEntry that is inclusionProof-only (omitting the signed inclusionPromise/inclusionPromise/set) and set integratedTime to a chosen value — for example, a timestamp that falls within the validity window of an otherwise-expired certificate.
3. Supply the bundle to the verifier: Provide the crafted bundle as input to the target application's Sigstore verification workflow (e.g., via an API, file upload, or CI/CD pipeline artifact).
4. Bypass timestamp verification: Because @sigstore/verify 3.1.0 unconditionally trusts integratedTime from inclusionProof-only entries, the manipulated timestamp is used for certificate validity and timestampThreshold checks, causing the verifier to accept a signature it should reject.
5. Achieve verification bypass: The attacker's artifact or signature is accepted as valid, potentially enabling supply chain tampering or bypassing code signing enforcement (Github Advisory).

• Logs: Sigstore verification logs showing successful verification of bundle v0.2 entries that lack a signed inclusionPromise field, particularly where integratedTime falls outside the expected range for the certificate's known validity window.
• File System: Presence of Sigstore bundle files (.sigstore, .bundle) with v0.2 format containing tlogEntries that have inclusionProof but no inclusionPromise field.
• Application Behavior: Unexpected successful verification of artifacts signed with certificates that should be expired or outside the expected validity window, especially in CI/CD pipelines or package verification workflows using @sigstore/verify 3.1.0.

Upgrade @sigstore/verify to version 3.1.1, which fixes the issue by requiring a signed inclusionPromise to be present before treating integratedTime as a trusted timestamp source; entries without an inclusionPromise now return undefined and are not counted toward timestampThreshold. The fix was merged via PR #1659 (commit f074710) on May 22, 2026, and released as @sigstore/verify@3.1.1. No configuration-based workaround is available; upgrading is the only remediation (Fix PR, Release).

The vulnerability was reported by three researchers (1seal, Str1ckl4nd, Zyy0530) and published by sigstore maintainer bdehamer. The fix was reviewed and approved by ejahnGithub and merged promptly. No significant broader media coverage or notable public commentary beyond the GitHub advisory and associated pull request has been identified (Github Advisory).