What is the CVSS score of EUVD-2026-44502?

EUVD-2026-44502 has a CVSS 3.1 base score of 6.5 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. EPSS exploitation probability: 0.2%.

Is there a public PoC exploit available for EUVD-2026-44502?

Yes, a public proof-of-concept exploit is available for EUVD-2026-44502. Prioritise patching immediately. EPSS: 0.2%.

Is there a patch available for EUVD-2026-44502?

Yes, a patch is available for EUVD-2026-44502. Update the affected software to the latest version immediately.

sigstore-js EUVD-2026-44502

| CVE-2026-48816 MEDIUM

Insufficient Verification of Data Authenticity (CWE-345)

2026-07-01 https://github.com/sigstore/sigstore-js

GHSA-xgjw-pm74-86q4

Information Disclosure Microsoft Red Hat Canonical

6.5

CVSS 3.1 · Vendor: https://github.com/sigstore/sigstore-js

Severity by source

Vendor (https://github.com/sigstore/sigstore-js) PRIMARY

6.5 MEDIUM

AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

vuln.today AI

6.5 MEDIUM

Attacker must supply the crafted bundle (PR:L); no confidentiality or availability impact; integrity impact is high as certificate validity enforcement is bypassed.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Red Hat

6.5 MEDIUM

qualitative

Primary rating from Vendor (https://github.com/sigstore/sigstore-js).

CVSS VectorVendor: https://github.com/sigstore/sigstore-js

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 20:21 vuln.today

CVE Published

Jul 01, 2026 - 19:57 github-advisory

MEDIUM 6.5

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

10 npm packages depend on @sigstore/verify (2 direct, 8 indirect)

Ecosystem-wide dependent count for version 3.1.0.

DescriptionCVE.org

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:

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

confirm canonical.log includes:

[CALLSITE_HIT]:
[PROOF_MARKER]:

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

AnalysisAI

Timestamp forgery in sigstore-js allows an attacker supplying a crafted bundle v0.2 to manipulate certificate validity window checks by controlling the integratedTime field in an inclusionProof-only tlog entry. Because the inclusionProof-only code path in @sigstore/verify does not cryptographically bind integratedTime (unlike the signed inclusionPromise/set path), a low-privileged attacker who can present an untrusted bundle can cause the verifier to accept expired or not-yet-valid signing certificates as currently valid. A publicly available proof-of-concept exists; this vulnerability is not in CISA KEV.

Technical ContextAI

sigstore-js is the JavaScript/TypeScript implementation of the Sigstore supply chain signing and verification framework, used broadly in npm-ecosystem CI/CD pipelines. The affected package is @sigstore/verify (pkg:npm/@sigstore_verify). The root cause is CWE-345 (Insufficient Verification of Data Authenticity): in bundle v0.2, a tlog entry may be 'inclusionProof-only' - meaning it carries a Merkle inclusion proof but no signed inclusionPromise or signed entry timestamp (SET). The signed inclusionPromise/SET path cryptographically binds integratedTime via a log-server signature; the inclusionProof-only path does not. The affected code in packages/verify/src/bundle/index.ts unconditionally adds a transparency-log timestamp whenever integratedTime != 0, packages/verify/src/timestamp/index.ts converts it to a Date, and packages/verify/src/verifier.ts uses it for certificate validity and timestampThreshold checks before verifying tlog inclusion. Only packages/verify/src/tlog/set.ts enforces cryptographic binding of integratedTime, and that guard is bypassed in the inclusionProof-only code path.

RemediationAI

The upstream fix described in the advisory is to restrict trust in integratedTime to cases where it is cryptographically bound: only the signed inclusionPromise/set path should contribute integratedTime to timestampThreshold or certificate validity decisions; the inclusionProof-only path must not use integratedTime as a trusted timestamp unless an independent signed time source (e.g., an RFC 3161 timestamp) is also present. The GitHub Security Advisory at https://github.com/sigstore/sigstore-js/security/advisories/GHSA-xgjw-pm74-86q4 describes this fix, but a specific patched npm release version is not independently confirmed from the provided data - consumers must check the sigstore-js release history for a patched @sigstore/verify version. As a compensating control prior to patching, organizations should avoid passing bundle v0.2 inputs from untrusted or partially-trusted sources to sigstore-js verifiers, and should require bundles to include signed inclusionPromise/set entries rather than accepting inclusionProof-only entries where feasible. Note that restricting accepted bundle formats may break compatibility with bundles generated by older tooling, so testing in staging environments is advised before enforcing this control.