Answer in brief
CVE-2026-48816 records a Medium severity (CVSS 6.5) vulnerability in sigstore-js has Insufficient Verification of Data Authenticity. The current sources do not mark it as known exploited. The current feed maps @sigstore/verify (npm), @sigstore/verify (npm). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps @sigstore/verify (npm), @sigstore/verify (npm). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| @sigstore/verifynpm | >=3.1.0 <3.1.1 | 3.1.1 |
| @sigstore/verifynpm | =3.1.0 | 3.1.1 |
Published upstream
Jul 1, 2026
Evidence: source:nvd:source_dates:source-dates:recordSource modified
Oct 24, 2026
Evidence: source:nvd:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 2026
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: ```bash 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](https://github.com/user-attachments/files/25643656/poc.zip) [PR_DESCRIPTION.md](https://github.com/user-attachments/files/25643660/PR_DESCRIPTION.md) [SUBMISSION.md](https://github.com/user-attachments/files/25643662/SUBMISSION.md)
Quoted source text, attributed separately from HOL analysis.