Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
MEDIUM severity

GHSA-xgjw-pm74-86q4

MEDIUM

GHSA-xgjw-pm74-86q4 is a medium-severity (CVSS 6.5) CWE-345 vulnerability in @sigstore/verify. O3 Security confirms whether GHSA-xgjw-pm74-86q4 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

sigstore-js has Insufficient Verification of Data Authenticity

Also known asCVE-2026-48816
Published
Jul 1, 2026
Updated
Jul 3, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Jul 3, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, a proxy for how much of the ecosystem is exposed.

@sigstore/verifynpm
10.0Mdownloads / week

Description

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
  1. confirm canonical.log includes:
[CALLSITE_HIT]:
[PROOF_MARKER]:
  1. 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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@sigstore/verify≥ 3.1.0&&< 3.1.13.1.1

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @sigstore/verify. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update @sigstore/verify to 3.1.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xgjw-pm74-86q4 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-xgjw-pm74-86q4 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-xgjw-pm74-86q4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

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 certific
O3 Security · Impact-Aware SCA

Is GHSA-xgjw-pm74-86q4 in your dependencies?

O3 detects GHSA-xgjw-pm74-86q4 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works
GHSA-xgjw-pm74-86q4: @sigstore/verify… | O3 Security