What is the CVSS score of CVE-2026-50021?

CVE-2026-50021 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.1%.

Which versions of pnpm are affected by CVE-2026-50021?

pnpm package manager versions prior to 10.34.0/10.34.1 and 11.4.0 contain an integrity verification bypass that allows malicious packages to install when lockfiles lack integrity fields; publicly…. A patch is available.

Is there a public PoC exploit available for CVE-2026-50021?

Yes, a public proof-of-concept exploit is available for CVE-2026-50021. Prioritise patching immediately. EPSS: 0.1%.

How to fix or mitigate CVE-2026-50021?

24 hours: Identify all pnpm installations and current versions across development and CI/CD environments. 7 days: Test and validate upgrades to pnpm 10.34.1 or later (10.x line) or 11.4.0 or later (11.x line) in non-production environments and verify dependency resolution. 30 days: Deploy patched pnpm versions across all development machines, CI/CD systems, and containers; audit recent pnpm-lock.yaml changes in version control for unauthorized modifications.

pnpm CVE-2026-50021

EUVD-2026-39488 HIGH

Improper Validation of Integrity Check Value (CWE-354)

2026-06-25 GitHub_M

GHSA-q6j5-fjx5-2mc3

Node.js Information Disclosure Pnpm Red Hat

8.1

CVSS 3.1 · NVD

Severity by source

Vendor (GitHub_M) PRIMARY

MEDIUM

qualitative

NVD

8.1 HIGH

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

vuln.today AI

6.8 MEDIUM

AC:H because exploitation needs both lockfile modification and control of registry-served content; PR:L for the repository/lockfile write access required; I:H/C:H from arbitrary tampered-package execution, A:N as availability is not the direct impact.

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

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

Red Hat

7.5 HIGH

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 29, 2026 - 21:31 vuln.today

Analysis Updated

Jun 29, 2026 - 21:31 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 29, 2026 - 21:31 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jun 29, 2026 - 21:22 vuln.today

cvss_changed

Severity Changed

Jun 29, 2026 - 21:22 NVD

MEDIUM HIGH

CVSS changed

Jun 29, 2026 - 21:22 NVD

6.8 (MEDIUM) 8.1 (HIGH)

Patch available

Jun 25, 2026 - 19:17 EUVD

Analysis Generated

Jun 25, 2026 - 18:21 vuln.today

DescriptionNVD

pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap. This vulnerability is fixed in 10.34.0 and 11.4.0.

AnalysisAI

Integrity-check bypass in the pnpm package manager (versions before 10.34.0/10.34.1 and 11.0.0-11.3.x) lets tampered packages install silently because the tarball extraction worker skips hash verification whenever the lockfile resolution has no integrity field. An attacker who can both edit pnpm-lock.yaml to drop the integrity: line and cause the referenced registry URL to serve altered content can push a malicious package through pnpm install --frozen-lockfile without any integrity error - a fail-open gap that npm's npm ci does not share. Publicly available exploit code exists; EPSS is low (0.12%, 2nd percentile) and the issue is not in CISA KEV.

Technical ContextAI

pnpm is one of the three major JavaScript/Node.js package managers and relies on Subresource-Integrity-style hashes recorded in pnpm-lock.yaml to guarantee that downloaded tarballs match what was originally resolved. The flaw is a classic CWE-354 (Improper Validation of Integrity Check Value): in addTarballToStore within worker/src/start.ts (lines 189-204) the hash comparison is gated behind if (integrity), and because the TarballResolution type declares integrity?: string as optional, an undefined value makes the guard evaluate false and skips verification entirely. The worker then computes a fresh hash from the unverified bytes and stores it as if legitimate, so even --frozen-lockfile - intended to be the strict, reproducible install mode - fails open rather than rejecting the entry. The affected CPE is cpe:2.3:a:pnpm:pnpm.

RemediationAI

Vendor-released patch: upgrade to pnpm 10.34.1 (10.x line; advisory also lists 10.34.0 as the fix) or 11.4.0 (11.x line), per GHSA-q6j5-fjx5-2mc3 (https://github.com/pnpm/pnpm/security/advisories/GHSA-q6j5-fjx5-2mc3). Until you upgrade, the most effective compensating control is to enforce that every remote tarball resolution in pnpm-lock.yaml carries an integrity: value: add a CI lint/pre-merge check that fails the build if any non-local lockfile entry is missing its integrity field (trade-off: requires custom tooling and may flag legitimately hand-edited lockfiles). Lock down who can modify pnpm-lock.yaml via branch protection and mandatory code review so a stripped integrity field cannot land unnoticed (trade-off: process overhead), and pin installs to a trusted internal registry / proxy with TLS and immutable package versions to remove the attacker's ability to serve altered content at a given URL (trade-off: requires registry infrastructure). These controls address both halves of the attack precondition; none fully substitutes for the patch.