CVE-2026-48816

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 3.1.1, @sigstore/verify derives a transparency-log timestamp from tlogEntries[].integratedTime for bundle v0.2 inclusionProof-only entries even though the inclusion proof path does not cryptographically bind integratedTime, allowing an attacker who can supply an untrusted bundle to influence certificate validity and timestampThreshold verification decisions. This issue is fixed in version 3.1.1.

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 3.1.1, @sigstore/verify derives a transparency-log timestamp from tlogEntries[].integratedTime for bundle v0.2 inclusionProof-only entries even though the inclusion proof path does not cryptographically bind integratedTime, allowing an attacker who can supply an untrusted bundle to influence certificate validity and timestampThreshold verification decisions. This issue is fixed in version 3.1.1.

sigstore-js derives a transparency-log timestamp from tlogEntries[].integratedTime and uses it to validate certificate validity windows and satisfy timestampThreshold. For bundle v0.2, a tlog entry can be inclusionProof-only (no signed inclusionPromise/set), and the inclusion proof path does not cryptographically bind integratedTime. As a result, an attacker who can supply an untrusted bundle can influence time-based verification decisions by choosing integratedTime.

impact

If a consumer accepts attacker-provided bundle v0.2 inputs and relies on tlog-derived timestamps for certificate validity checks, verification can be influenced by an unauthenticated timestamp value. This is a trust gap: integratedTime is treated as a trusted observer timestamp under inclusionProof-only mode even though only the signed inclusionPromise/set path binds it.

affected code

• packages/verify/src/bundle/index.ts (adds a transparency-log timestamp whenever integratedTime != 0)
• packages/verify/src/timestamp/index.ts (converts integratedTime to a Date)
• packages/verify/src/verifier.ts (verifies timestamps before verifying tlog inclusion)
• packages/verify/src/tlog/index.ts + packages/verify/src/tlog/set.ts (only the inclusionPromise/set path binds integratedTime)

proof of concept

The attached poc.zip contains a self-contained harness that reproduces the behavior on the pinned commit and includes both a canonical test and a negative control.

repro:

1. extract poc.zip into a fresh directory and run the make targets:

unzip poc.zip -d poc
cd poc/poc-F-SIG-JS-TLOGTIME-001
make canonical
make control

2. confirm canonical.log includes:

[CALLSITE_HIT]:
[PROOF_MARKER]:

3. confirm control.log includes:

[NC_MARKER]:

suggested fix

Only treat integratedTime as a trusted timestamp when it is cryptographically bound (for example, via a verified signed inclusionPromise/set). For inclusionProof-only entries, do not count integratedTime toward timestampThreshold, and do not use it for certificate validity decisions unless there is another signed time source (for example, an rfc3161 timestamp).

poc.zip PR_DESCRIPTION.md SUBMISSION.md

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 3.1.1, @sigstore/verify derives a transparency-log timestamp from tlogEntries[].integratedTime for bundle v0.2 inclusionProof-only entries even though the inclusion proof path does not cryptographically bind integratedTime, allowing an attacker who can supply an untrusted bundle to influence certificate validity and timestampThreshold verification decisions. This issue is fixed in version 3.1.1.

sigstore-js provides JavaScript libraries for interacting with Sigstore services. Prior to 3.1.1, @sigstore/verify derives a transparency-log timestamp from tlogEntries[].integratedTime for bundle v0.2 inclusionProof-only entries even though the inclusion proof path does not cryptographically bind integratedTime, allowing an attacker who can supply an untrusted bundle to influence certificate validity and timestampThreshold verification decisions. This issue is fixed in version 3.1.1.

sigstore-js derives a transparency-log timestamp from tlogEntries[].integratedTime and uses it to validate certificate validity windows and satisfy timestampThreshold. For bundle v0.2, a tlog entry can be inclusionProof-only (no signed inclusionPromise/set), and the inclusion proof path does not cryptographically bind integratedTime. As a result, an attacker who can supply an untrusted bundle can influence time-based verification decisions by choosing integratedTime.

impact

If a consumer accepts attacker-provided bundle v0.2 inputs and relies on tlog-derived timestamps for certificate validity checks, verification can be influenced by an unauthenticated timestamp value. This is a trust gap: integratedTime is treated as a trusted observer timestamp under inclusionProof-only mode even though only the signed inclusionPromise/set path binds it.

affected code

• packages/verify/src/bundle/index.ts (adds a transparency-log timestamp whenever integratedTime != 0)
• packages/verify/src/timestamp/index.ts (converts integratedTime to a Date)
• packages/verify/src/verifier.ts (verifies timestamps before verifying tlog inclusion)
• packages/verify/src/tlog/index.ts + packages/verify/src/tlog/set.ts (only the inclusionPromise/set path binds integratedTime)

proof of concept

The attached poc.zip contains a self-contained harness that reproduces the behavior on the pinned commit and includes both a canonical test and a negative control.

repro:

1. extract poc.zip into a fresh directory and run the make targets:

unzip poc.zip -d poc
cd poc/poc-F-SIG-JS-TLOGTIME-001
make canonical
make control

2. confirm canonical.log includes:

[CALLSITE_HIT]:
[PROOF_MARKER]:

3. confirm control.log includes:

[NC_MARKER]:

suggested fix

Only treat integratedTime as a trusted timestamp when it is cryptographically bound (for example, via a verified signed inclusionPromise/set). For inclusionProof-only entries, do not count integratedTime toward timestampThreshold, and do not use it for certificate validity decisions unless there is another signed time source (for example, an rfc3161 timestamp).

poc.zip PR_DESCRIPTION.md SUBMISSION.md

Root has patched CVE-2026-48816 in the @sigstore/verify package for Root:npm. Multiple fixed versions available.