CVE-2026-50573 is a medium-severity security vulnerability in pnpm (npm), affecting versions < 10.34.0. It is fixed in 10.34.0, 11.4.0.
While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default. Summary 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. Reproduction Scenario Run a local npm-compatible registry. Publish or serve [email protected] with tarball content v1. Install it with pnpm: Confirm pnpm-lock.yaml contains the v1 integrity: Change the registry metadata and tarball for the same [email protected] to content v2. On a clean store/cache, run: Observed Behavior pnpm detects the checksum mismatch: However, the install still succeeds: The lockfile is then rewritten to trust the new remote integrity: Expected Behavior If a downloaded tarball does not match the integrity recorded in pnpm-lock.yaml, the install should fail by default. The lockfile integrity should be treated as authoritative unless the user explicitly requests lockfile repair or dependency update behavior. Security Impact This behavior weakens the protection normally expected from a committed lockfile. If a registry is compromised and an attacker overwrites the metadata and tarball for an existing package version, a new environment without the old pnpm store/cache may install the attacker's replacement package even though the project already has a lockfile with the original integrity. Examples of affected new or clean environments include: an engineer setting up the project on a new machine a new team member onboarding to the project In this situation, pnpm first detects that the downloaded tarball does not match the integrity stored in pnpm-lock.yaml. However, instead of failing by default, plain pnpm install performs a resolution repair, trusts the current remote registry metadata, updates the lockfile to the new integrity, and installs the new registry content. In other words, when the lockfile and registry disagree, the default non-frozen behavior can end up trusting the remote registry over the content previously recorded in the lockfile. This is especially relevant for: private registries that allow overwriting or republishing the same version registry mirrors or proxies that can serve changed metadata and tarballs compromised public or private registries compromised registry proxy infrastructure The behavior is also surprising because the command reports an integrity error but still exits successfully after resolution repair. This issue does not occur when --frozen-lockfile is enabled. In frozen mode, the same integrity mismatch fails the install and does not install the changed package content. However, since the lockfile already records an integrity value, the integrity for the same package version should normally not change. If it does change, one likely explanation is that the server or registry has been compromised or is serving mutated package content. Under normal package publishing workflows, changed package content should be published as a new version instead of replacing an existing version. For that reason, it may be safer for pnpm's default behavior to be closer to frozen mode for this specific case. At minimum, pnpm should not automatically repair the lockfile and trust the registry after an integrity mismatch. It should fail and let the user explicitly decide whether to discard the locked integrity, re-resolve the package from the remote registry, and update the lockfile. Comparison In the same scenario, npm install with an existing package-lock.json fails with EINTEGRITY and does not install the changed tarball. pnpm install --frozen-lockfile also fails as expected: The issue is specific to the default non-frozen behavior of plain pnpm install in non-CI environment.
CVE-2026-50573 has a CVSS score of 6.8 (Medium). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.
A fixed version is available (10.34.0, 11.4.0). Upgrading removes the vulnerable code path.
npm
pnpm (< 10.34.0)pnpm (>= 11.0.0, < 11.4.0)pnpm → 10.34.0 (npm)pnpm → 11.4.0 (npm)Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.
Kodem's runtime-powered SCA identifies whether CVE-2026-50573 is reachable in your applications. Explore open-source security for your team.
See if CVE-2026-50573 is reachable in your applications. Get a demo
Already deployed Kodem? See CVE-2026-50573 in your environment →Upgrade the following packages to resolve this vulnerability:
pnpm to 10.34.0 or laterpnpm to 11.4.0 or laterKodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
CVE-2026-50573 is a medium-severity security vulnerability in pnpm (npm), affecting versions < 10.34.0. It is fixed in 10.34.0, 11.4.0.
CVE-2026-50573 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
pnpm (npm) versions < 10.34.0 is affected.
Yes. CVE-2026-50573 is fixed in 10.34.0, 11.4.0. Upgrade to this version or later.
Whether CVE-2026-50573 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
pnpm to 10.34.0 or laterpnpm to 11.4.0 or later