CVE-2026-48816: sigstore-js Timestamp Verification Bypass

CVE-2026-48816 Overview

CVE-2026-48816 affects sigstore-js, a set of JavaScript libraries for interacting with Sigstore services. The @sigstore/verify package prior to version 3.1.1 derives a transparency-log timestamp from tlogEntries[].integratedTime for bundle v0.2 inclusionProof-only entries. The inclusion proof path does not cryptographically bind integratedTime, so an attacker supplying an untrusted bundle can influence certificate validity and timestampThreshold verification decisions. This weakness is classified as insufficient verification of data authenticity [CWE-345]. The issue is fixed in @sigstore/verify version 3.1.1.

Critical Impact
An attacker able to supply a crafted Sigstore bundle can manipulate the transparency-log timestamp used during verification, undermining signature trust decisions and enabling acceptance of otherwise invalid artifacts.

Affected Products

sigstore-js — @sigstore/verify package
All @sigstore/verify versions prior to 3.1.1
Applications consuming bundle v0.2 inclusionProof-only entries via @sigstore/verify

Discovery Timeline

2026-07-14 - CVE-2026-48816 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-48816

Vulnerability Analysis

The vulnerability resides in the timestamp derivation logic of @sigstore/verify. When processing a bundle v0.2 transparency-log entry that contains only an inclusionProof (without an inclusionPromise/SET), the library still returned a TimestampVerificationResult seeded from the entry's integratedTime field. Because the inclusion proof path proves membership in the Merkle tree but does not cryptographically bind integratedTime, that value is attacker-controlled when the bundle originates from an untrusted source. Downstream checks — including certificate validity windows and timestampThreshold — rely on this value, allowing an attacker to shift the effective verification time.

Root Cause

The function getTLogTimestamp in packages/verify/src/timestamp/index.ts treated every TransparencyLogEntry as a valid source of a verifiable timestamp. It did not distinguish between entries whose integratedTime is signed by a log (inclusionPromise / SET) and those where it is merely metadata alongside an inclusion proof. This is a classic insufficient verification of data authenticity flaw [CWE-345].

Attack Vector

An attacker who can deliver a crafted Sigstore bundle to a verifier — for example, through a supply-chain artifact, registry, or CI/CD input — can construct a bundle v0.2 entry containing only an inclusion proof and an arbitrary integratedTime. The verifier then accepts that timestamp, potentially validating certificates that were not valid at the true signing time or bypassing configured freshness thresholds.

typescript

// Security patch in packages/verify/src/timestamp/index.ts
// Reject integratedTime without inclusionPromise (#1659)
export function getTLogTimestamp(
  entry: TransparencyLogEntry
): TimestampVerificationResult | undefined {
  // Only entries with an inclusion promise provide a verifiable timestamp
  if (!entry.inclusionPromise) {
    return undefined;
  }

  return {
    type: 'transparency-log',
    logID: entry.logId.keyId,
    // ...
  };
}

Source: sigstore/sigstore-js commit f074710

Detection Methods for CVE-2026-48816

Indicators of Compromise

Sigstore bundles at version v0.2 containing tlogEntries with an inclusionProof but no inclusionPromise or SET.
Verification logs showing artifact acceptance where the certificate's notBefore/notAfter window would exclude the current time.
Anomalous integratedTime values that do not correspond to Rekor log activity for the given log ID.

Detection Strategies

Inventory Node.js projects and container images that depend on @sigstore/verify at versions below 3.1.1, including transitive dependencies via sigstore, cosign tooling wrappers, and npm provenance verification.
Cross-check accepted bundle timestamps against the corresponding Rekor log's public inclusion promise to detect discrepancies.
Enable verbose logging in verification pipelines to record which timestamp source (inclusionPromise vs. inclusionProof-only) was used per verification.

Monitoring Recommendations

Alert on CI/CD or artifact-verification services that continue to load pre-3.1.1 versions of @sigstore/verify after the patch is available.
Monitor package registries and provenance workflows for bundles that consistently rely on inclusionProof-only entries.
Track outcomes of signature verification jobs for sudden increases in accepted artifacts near certificate expiration boundaries.

How to Mitigate CVE-2026-48816

Immediate Actions Required

Upgrade @sigstore/verify to version 3.1.1 or later across all applications, build systems, and verification services.
Rebuild and redeploy container images and serverless functions that bundle the vulnerable version.
Re-verify recently accepted artifacts using the patched library to identify any that would now be rejected.

Patch Information

The fix is delivered in @sigstore/verify@3.1.1. The relevant change updates getTLogTimestamp to return undefined when an entry lacks an inclusionPromise, ensuring integratedTime is only trusted when cryptographically bound by the log. See the GitHub Security Advisory GHSA-xgjw-pm74-86q4, the pull request #1659, and the release notes for @sigstore/verify@3.1.1.

Workarounds

Reject bundle v0.2 transparency-log entries that lack an inclusionPromise before passing them to @sigstore/verify.
Require a Timestamp Authority (TSA) signed timestamp in verification policy so trust does not depend solely on the log-derived integratedTime.
Pin verification workflows to trusted, first-party bundle sources until the upgrade to 3.1.1 is complete.

bash

# Upgrade the vulnerable package to the fixed version
npm install @sigstore/verify@3.1.1

# Verify the resolved version across the dependency tree
npm ls @sigstore/verify

# For yarn-based projects
yarn up @sigstore/verify@3.1.1