CVE-2026-50573

What it actually does

This flaw weakens pnpm lockfile integrity enforcement during non-frozen installs. If a dependency is already recorded in pnpm-lock.yaml with an integrity hash, but the package registry later returns different metadata and tarball content for the same package name and version, vulnerable pnpm versions first detect the mismatch but then perform a resolution repair, update the lockfile with the new integrity value, install the changed content, and exit successfully. The result is a supply-chain integrity bypass: package content can change without an intentional dependency version change, allowing unauthorized code to enter a build or developer workstation when `pnpm install` is run in non-frozen mode.

Why it matters to the business

An attacker who can influence package registry responses, a registry mirror, or package content for an already-locked dependency may be able to introduce malicious code into applications without changing dependency names or versions. This can lead to source or build compromise, credential theft from developer or CI environments, poisoned releases, and downstream compromise of users of the affected software. The current EPSS is low and the issue is not in CISA KEV, but the impact is significant for organizations that rely on pnpm lockfiles as a supply-chain control, especially in automated build pipelines or environments using private registries, proxies, or mirrors.

How an attack unfolds

An attacker first gains the ability to serve altered metadata and tarball content for an existing package name and version, such as through a compromised registry account, malicious or compromised private registry, poisoned mirror/cache, or network path that can influence package downloads. The target project already has that package locked in `pnpm-lock.yaml` with an integrity value. A developer or CI job then runs vulnerable pnpm in non-frozen mode using a command such as `pnpm install`. pnpm downloads the tarball, detects that the downloaded content does not match the integrity recorded in the lockfile, but instead of failing closed, it repairs resolution state, accepts the newly served integrity value, updates `pnpm-lock.yaml`, installs the altered package content, and exits successfully. If the altered package contains malicious install scripts or runtime code, it may execute during installation, build, tests, or application runtime, enabling credential theft, build tampering, or persistent supply-chain compromise.

How to fix it

Upgrade pnpm to a fixed version: 10.34.0 or later for the 10.x line, or 11.4.0 or later for the 11.x line. Enforce frozen lockfile behavior in CI and release builds by using `pnpm install --frozen-lockfile` and failing builds when `pnpm-lock.yaml` would be modified. Treat unexpected lockfile integrity changes as security-relevant and require code review for any lockfile update. Pin and verify the pnpm version used in CI, developer bootstrap scripts, container images, and build runners. Where possible, use trusted registries, restrict write access to private registries and mirrors, enable registry authentication, and monitor for package metadata or tarball changes for already-published versions. If immediate upgrade is not possible, block non-frozen installs in sensitive workflows and require clean, reviewed lockfile updates generated only in controlled environments.

How to confirm the fix worked

Confirm the pnpm version in all developer, CI, build, and container environments with `pnpm --version`; vulnerable versions are earlier than 10.34.0 on the 10.x line and earlier than 11.4.0 on the 11.x line. Review CI configuration to verify that install steps use `pnpm install --frozen-lockfile` or equivalent frozen-lockfile enforcement and fail if the lockfile changes. Run a controlled test by attempting an install where `pnpm-lock.yaml` would be modified; fixed or properly configured environments should fail rather than silently accepting new integrity values in protected workflows. Inspect recent commits and build artifacts for lockfile integrity changes that occurred without dependency version changes. Validate that base images, build runner templates, package-manager activation tools, and developer setup documentation all reference fixed pnpm versions.

Typical attack path

1. Identify an organization or project that uses pnpm versions prior to 10.34.0 or 11.4.0 and runs `pnpm install` without frozen lockfile enforcement.
2. Gain influence over package content returned for an already-locked dependency name and version, such as through a compromised registry, private registry, proxy, mirror, cache, or package publishing path.
3. Serve modified package metadata and tarball content while keeping the package name and version unchanged.
4. Wait for a developer workstation or CI pipeline to run vulnerable `pnpm install` in non-frozen mode.
5. Rely on pnpm to detect the integrity mismatch but then repair the lockfile and accept the new integrity value.
6. Execute malicious package install scripts or plant malicious code that runs during build, test, deployment, or application runtime.
7. Use access from the build or developer environment to steal credentials, alter build artifacts, or move further into the software supply chain.

How to detect it

To determine whether this was already exploited, review source-control history, CI logs, package manager logs, and build artifacts for evidence that `pnpm-lock.yaml` integrity values changed without corresponding dependency version changes. Prioritize repositories where vulnerable pnpm versions ran `pnpm install` without `--frozen-lockfile`. In version control, compare lockfile diffs for changes to `integrity:` fields where the package name and version stayed the same. In CI logs, look for pnpm integrity mismatch errors or warnings followed by successful installation, lockfile updates, package script execution, or artifact publication. Review registry, proxy, and mirror logs for repeated downloads of the same package name and version returning different tarball hashes, sizes, ETags, or upstream sources. If suspicious changes are found, inspect the installed package contents, lifecycle scripts, generated build artifacts, and outbound network activity from build jobs for credential exfiltration or unauthorized code execution. Because no public exploitation or named threat actors are indicated in the provided data, treat findings as suspicious supply-chain anomalies rather than confirmed compromise until correlated with malicious package content or execution evidence.

• ERR_PNPM_TARBALL_INTEGRITY
• Got unexpected checksum
• pnpm-lock.yaml
• integrity: sha512-
• pnpm install --no-frozen-lockfile
• pnpm install
• --frozen-lockfile
• lockfile integrity
• resolution repair
• Running postinstall script
• Running preinstall script
• Running install script

What your security team should do

• Inventory all repositories, CI pipelines, container images, and developer bootstrap workflows that use pnpm.
• Upgrade pnpm everywhere to 10.34.0 or later, or 11.4.0 or later, depending on the deployed major version.
• Make `pnpm install --frozen-lockfile` mandatory for CI, release, and production build workflows.
• Create repository controls that flag or require approval for `pnpm-lock.yaml` integrity changes when dependency names and versions did not change.
• Review recent lockfile changes for unexpected integrity updates, especially those produced by automated builds or routine install commands.
• Restrict and monitor access to private registries, package mirrors, and caching proxies that can influence dependency tarballs.
• Search CI and developer logs for pnpm integrity mismatch messages followed by successful installs or lockfile modifications.
• Rebuild sensitive artifacts from a clean environment after upgrading pnpm if suspicious lockfile integrity changes are found.