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

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

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

pnpm package manager versions below 10.34.0 and 11.0.0-11.4.0 contain a lockfile integrity bypass enabling threat actors with registry access to inject malicious code into production builds while…. A patch is available.

How to fix or mitigate CVE-2026-50573?

Within 24 hours: Audit all development and CI/CD environments to identify deployed pnpm versions (< 10.34.0 or 11.0.0-11.4.0). Within 7 days: Upgrade pnpm to version 10.34.0 or later (10.x line) or 11.5.0 or later (11.x line) across all development machines, build agents, and container images. Within 30 days: Enforce registry authentication and HTTPS-only policies; implement lockfile review procedures in code review workflows; audit project dependencies for unauthorized modifications since affected versions were deployed.

pnpm CVE-2026-50573

EUVD-2026-39489 HIGH

Insufficient Verification of Data Authenticity (CWE-345)

2026-06-25 GitHub_M

GHSA-54hh-g5mx-jqcp

Information Disclosure Red Hat Pnpm

8.1

CVSS 3.1 · NVD

Severity by source

Vendor (GitHub_M) PRIMARY

MEDIUM

qualitative

NVD

8.1 HIGH

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

vuln.today AI

5.3 MEDIUM

AC:H because the attacker must first control registry content for an already-pinned version; UI:R as a victim must run a non-frozen install; C:H/I:H from installing attacker-chosen code, A:N as availability is not the impact.

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

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

Red Hat

6.8 MEDIUM

qualitative

Primary rating from Vendor (GitHub_M).

CVSS VectorNVD

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jun 29, 2026 - 21:29 vuln.today

Analysis Updated

Jun 29, 2026 - 21:29 vuln.today

v3 (cvss_changed)

Analysis Updated

Jun 29, 2026 - 21:29 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:22 vuln.today

DescriptionNVD

pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm install in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. This vulnerability is fixed in 10.34.0 and 11.4.0.

AnalysisAI

Lockfile integrity bypass in the pnpm package manager (versions below 10.34.0, and 11.0.0 through 11.4.0) lets a malicious or compromised registry override a package version's previously recorded hash. On a plain pnpm install in non-frozen mode, pnpm detects the tarball-vs-lockfile integrity mismatch, warns, then silently performs a 'resolution repair' that accepts the registry's new integrity, rewrites pnpm-lock.yaml, and installs the substituted content while exiting 0. Publicly available exploit code exists (a full reproduction scenario is published in the GitHub advisory), but there is no public exploit identified as used in active attacks; EPSS is low at 0.11%.

Technical ContextAI

pnpm-lock.yaml records a Subresource-Integrity-style hash (sha512) for every resolved package as a Trust-On-First-Use anchor: subsequent installs are supposed to fail closed if the fetched tarball does not match. The root cause is CWE-345 (Insufficient Verification of Data Authenticity): the integrity check is treated as advisory rather than authoritative when the install is not run with --frozen-lockfile. When a hash mismatch occurs, pnpm's 'resolution repair' path conflates two distinct situations - a legitimately stale lockfile that needs regeneration, versus a registry serving altered content for an already-pinned (name, version) pair - and resolves both by trusting the live registry. The affected component is the pnpm CLI itself (cpe:2.3:a:pnpm:pnpm), not a transitive library, so any project using pnpm without frozen installs inherits the weak default.

RemediationAI

Vendor-released patch: upgrade to pnpm 10.34.0 (for the 10.x/older line) or pnpm 11.4.0 (for the 11.x line), per advisory GHSA-54hh-g5mx-jqcp (https://github.com/pnpm/pnpm/security/advisories/GHSA-54hh-g5mx-jqcp). As an immediate compensating control that does not require upgrading, run installs with pnpm install --frozen-lockfile everywhere a committed lockfile exists (set CI to fail rather than repair), which makes a hash mismatch a hard stop; the trade-off is that legitimate lockfile drift must now be resolved deliberately with an explicit pnpm install/update rather than silently. Additionally, require HTTPS registries and pin/verify your registry or mirror to remove the MITM/altered-content path, and restrict who can publish/overwrite package versions on internal registries (disable version overwrite/republish). Frozen-lockfile is the default in CI for many setups already, so enforcing it closes the practical exposure pending the upgrade.