CVE-2026-50573 in pnpm
Summary
by MITRE • 06/25/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/26/2026
This vulnerability in pnpm represents a critical security flaw that undermines the integrity verification mechanisms designed to protect against supply chain attacks. The issue affects versions prior to 10.34.0 and 11.4.0 where the package manager's lockfile validation system fails to enforce strict integrity checks during installation. When pnpm encounters a mismatch between the expected integrity hash recorded in the pnpm-lock.yaml file and the actual content downloaded from the registry, it should ideally halt the installation process to prevent potentially malicious code execution. However, in affected versions, the system instead proceeds with a resolution repair mechanism that accepts the new registry-provided content and updates the lockfile to reflect the changed integrity values.
The technical flaw stems from pnpm's handling of integrity validation in non-frozen mode installations where the system prioritizes convenience over security by automatically repairing mismatches rather than rejecting them outright. This behavior creates a window of opportunity for attackers who have compromised package registries or gained access to the distribution infrastructure to serve modified content while maintaining the appearance of legitimate package delivery. The vulnerability allows for what is essentially a "lockfile poisoning" attack where an attacker can replace legitimate package content with malicious code that gets silently accepted by the package manager due to the automatic repair functionality.
The operational impact of this vulnerability extends beyond simple integrity validation failure and represents a significant risk to software supply chain security. Organizations relying on pnpm for dependency management may unknowingly install compromised packages that have been modified after the initial lockfile was created. This creates a false sense of security since the system appears to function normally while silently accepting potentially malicious code. The vulnerability is particularly concerning in enterprise environments where strict dependency control and audit trails are essential for maintaining software integrity and compliance with security policies.
This issue aligns with CWE-1032 which describes "Insufficient Verification of Data Authenticity" and represents a failure in the integrity verification process that should prevent unauthorized modifications to package content. From an ATT&CK perspective, this vulnerability enables techniques such as T1574.006 (Modify Authentication Token) and T1583.001 (Compromise Infrastructure) by allowing attackers to modify package contents without detection. The fix implemented in versions 10.34.0 and 11.4.0 addresses this by strengthening the lockfile validation process to ensure that integrity mismatches trigger hard failures rather than automatic repairs, thereby restoring the intended security controls for dependency management.
Security practitioners should immediately upgrade to affected versions or implement additional verification mechanisms such as manual integrity checks, registry monitoring, and implementation of frozen lockfile modes in production environments. The vulnerability demonstrates the critical importance of maintaining strict integrity controls in package managers and highlights the need for robust validation processes that cannot be bypassed through automatic repair mechanisms. Organizations should also consider implementing additional security measures including package signature verification, continuous monitoring of dependency changes, and regular security audits of their package management infrastructure to prevent similar vulnerabilities from compromising software supply chain integrity.