What is the CVSS score of CVE-2025-69263?

CVE-2025-69263 has a CVSS 3.1 base score of 8.8 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of pnpm are affected by CVE-2025-69263?

pnpm package manager versions 10.26.2 and earlier contain a supply-chain vulnerability enabling malicious actors to inject different code during package installation, bypassing lockfile integrity…. A patch is available.

Is there a public PoC exploit available for CVE-2025-69263?

Yes, a public proof-of-concept exploit is available for CVE-2025-69263. Prioritise patching immediately. EPSS: 0.0%.

How to fix or mitigate CVE-2025-69263?

24 hours: Inventory all systems and projects using pnpm and their current versions. 7 days: Upgrade to pnpm 10.26.0 or later across all development environments, CI/CD systems, and build infrastructure (per GHSA-7vhp-vf5g-r2fw). 30 days: Conduct supply-chain risk audit focused on HTTP/git-based tarball dependencies and implement enhanced verification controls for external packages.

pnpm CVE-2025-69263

HIGH

Download of Code Without Integrity Check (CWE-494)

2026-01-07 security-advisories@github.com

GHSA-7vhp-vf5g-r2fw

Pnpm Information Disclosure

8.8

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

8.8 HIGH

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

vuln.today AI

7.5 HIGH

Network-delivered via package install (AV:N), UI:R for the install action, PR:N as no victim credentials needed, AC:H because attacker must control a package in the victim's tree; full CIA impact via arbitrary code execution.

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

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

SUSE

7.5 HIGH

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

Red Hat

7.5 HIGH

qualitative

Primary rating from NVD.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Jun 22, 2026 - 14:59 vuln.today

v3 (cvss_changed)

Source Code Evidence Fetched

Jun 22, 2026 - 14:59 vuln.today

Analysis Updated

Jun 22, 2026 - 14:59 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 22, 2026 - 14:52 vuln.today

cvss_changed

CVSS changed

Jun 22, 2026 - 14:52 NVD

7.5 (HIGH) 8.8 (HIGH)

Analysis Generated

Mar 12, 2026 - 21:54 vuln.today

PoC Detected

Jan 12, 2026 - 21:52 vuln.today

Public exploit code

Patch released

Jan 12, 2026 - 21:52 nvd

Patch available

CVE Published

Jan 07, 2026 - 22:15 nvd

HIGH 7.5

DescriptionNVD

pnpm is a package manager. Versions 10.26.2 and below store HTTP tarball dependencies (and git-hosted tarballs) in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed. An attacker who publishes a package with an HTTP tarball dependency can serve different code to different users or CI/CD environments. The attack requires the victim to install a package that has an HTTP/git tarball in its dependency tree. The victim's lockfile provides no protection. This issue is fixed in version 10.26.0.

AnalysisAI

Supply-chain integrity bypass in pnpm package manager (versions ≤10.26.2, per description; GHSA states <10.26.0) allows malicious package authors to serve different tarball content on each install because HTTP/HTTPS tarball and git-hosted tarball dependencies are recorded in the lockfile without integrity hashes. Publicly available exploit code exists in the GHSA-7vhp-vf5g-r2fw advisory PoC, though EPSS remains low at 0.01% and the issue is not on CISA KEV. Any project transitively depending on a package that uses an HTTP/git tarball is exposed, and a committed lockfile offers no protection.

Technical ContextAI

pnpm is a Node.js package manager that, like npm and Yarn, uses a lockfile to pin transitive dependency versions and integrity hashes for reproducible installs (CPE cpe:2.3:a:pnpm:pnpm:*:*:*:*:*:*:node.js:*). The root cause is CWE-494 (Download of Code Without Integrity Check): the tarball resolver in resolving/tarball-resolver/src/index.ts returns only the resolved URL and omits the integrity field for HTTP(S) tarball URLs, git shorthand (github:user/repo), and git+https URLs. Without an integrity hash, pnpm cannot detect that a remote server has returned different bytes for the same URL on a subsequent install, defeating the core reproducibility guarantee of the lockfile. Packages fetched from the npm registry are unaffected because the registry metadata supplies integrity hashes that pnpm does record.

RemediationAI

Upgrade pnpm to version 10.26.0 or later, which is the upstream fix referenced by GHSA-7vhp-vf5g-r2fw and commit https://github.com/pnpm/pnpm/commit/0958027f88a99ccefe7e9676cdebba393dfbdc85; CI/CD images, developer workstations, and Docker base images that pin pnpm must all be updated. Until upgrade is complete, audit dependency trees for HTTP(S) tarball URLs and git/github: specifiers (e.g., grep package.json and pnpm-lock.yaml for 'http', 'github:', and 'git+') and replace them with npm-registry-published versions or git+ssh references pinned to a commit SHA, accepting the side effect that this may require republishing internal packages or vendoring sources. As a network-layer mitigation, restrict outbound install traffic to a trusted internal registry/proxy so installs cannot reach arbitrary tarball hosts, noting the trade-off that legitimate github: dependencies will break. Avoid simply re-running 'pnpm install' against the same lockfile expecting protection - the lockfile itself is the weak link.