CVE-2026-50021

What it actually does

This vulnerability is a fail-open integrity-check weakness in pnpm tarball extraction. In affected pnpm versions prior to 10.34.0 and 11.4.0, if a package entry in pnpm-lock.yaml does not contain an integrity field, pnpm install --frozen-lockfile can proceed without verifying the downloaded package tarball against a cryptographic digest. An attacker who can modify the lockfile and also influence the package tarball served from the referenced registry URL can cause pnpm to install altered package contents without triggering the expected integrity error. The practical technical impact is supply-chain code injection during dependency installation, potentially affecting build systems, developer workstations, or CI/CD pipelines that rely on pnpm lockfiles for reproducible installs.

Why it matters to the business

Successful exploitation can allow malicious code to enter software builds through a trusted dependency installation workflow. This may lead to compromised application releases, theft of build secrets, backdoored packages, source-code exposure, or downstream compromise of customers and users. The CVSS score is moderate-to-high, but exploitation requires multiple conditions: the attacker must be able to alter pnpm-lock.yaml and control or tamper with the referenced package content. EPSS is currently low and the issue is not listed in CISA KEV, so broad active exploitation is not indicated, but the potential business impact is significant for organizations with automated builds, private registries, or weak change controls around dependency lockfiles.

How an attack unfolds

An attacker first gains the ability to modify a project dependency lockfile, such as through a malicious pull request, compromised developer account, compromised source repository, or insider access. They then remove the integrity field from a targeted package resolution in pnpm-lock.yaml while leaving the dependency reference otherwise plausible. Next, the attacker causes the package tarball URL referenced by the lockfile to serve modified content, for example by compromising a private registry, poisoning an internal mirror, changing lockfile registry references to attacker-controlled infrastructure, or otherwise intercepting the package source. When a vulnerable pnpm version runs pnpm install --frozen-lockfile, the absence of the integrity value causes pnpm to skip cryptographic verification instead of failing closed. The modified tarball is extracted and installed, allowing attacker-controlled package code to enter node_modules and potentially execute during lifecycle scripts, test/build steps, or at application runtime.

How to fix it

Upgrade pnpm to a fixed version: 10.34.0 or later on the 10.x line, or 11.4.0 or later on the 11.x line. Regenerate or audit pnpm-lock.yaml files to ensure package resolution entries include integrity metadata where expected. Treat lockfile changes as security-sensitive and require code review for any removal of integrity fields, changes to tarball URLs, or changes to registry domains. Use trusted package registries and enforce HTTPS. Restrict write access to source repositories, dependency update automation, package mirrors, and private registries. Where possible, block installation from untrusted or unexpected registry hosts. As a compensating control until all systems are upgraded, reject builds when pnpm-lock.yaml contains package entries without integrity fields or when lockfile tarball URLs point to unauthorized registries.

How to confirm the fix worked

Confirm that all developer workstations, CI images, build agents, and release pipelines use pnpm 10.34.0 or later, or 11.4.0 or later. Run pnpm --version in each build environment, not only on local developer machines. Review recent and current pnpm-lock.yaml files for removed integrity fields, unexpected tarball URL changes, or registry host changes. Re-run dependency installation with the upgraded pnpm version and verify that malformed or integrity-less lockfile entries fail or are corrected according to the fixed behavior. Validate CI/CD images are rebuilt and not pinning older pnpm versions through Corepack, npm global installs, base images, or cached toolchains. Confirm branch protection, code review, and dependency update policies cover lockfile modifications.

Typical attack path

1. Identify a project or build pipeline that uses pnpm prior to 10.34.0 or 11.4.0.
2. Obtain a path to modify pnpm-lock.yaml, such as a malicious pull request, compromised repository credentials, or compromised dependency update workflow.
3. Remove the integrity field from one or more package resolution entries in pnpm-lock.yaml.
4. Ensure the referenced package tarball URL serves altered content, either through registry compromise, malicious mirror configuration, URL manipulation, or network/package-source tampering.
5. Wait for a developer workstation or CI/CD job to run pnpm install --frozen-lockfile using the vulnerable pnpm version.
6. Rely on pnpm skipping integrity verification for the affected entry and installing the altered tarball without an integrity mismatch error.
7. Use malicious package contents or lifecycle scripts to steal secrets, alter builds, implant backdoors, or persist in the software supply chain.

How to detect it

To determine whether this was already exploited, review source-control history, CI/CD logs, package registry logs, and build artifacts. In version control, look for commits or pull requests that remove integrity fields from pnpm-lock.yaml, change tarball URLs, or switch registry hosts. In CI logs, identify builds that used pnpm versions earlier than 10.34.0 or 11.4.0 and ran pnpm install --frozen-lockfile after suspicious lockfile changes. In registry or proxy logs, look for package tarball requests to unexpected domains, internal mirrors serving package content that differs from upstream, package overwrites, or downloads of targeted packages immediately following lockfile changes. On build hosts, inspect installed node_modules contents, package lifecycle script execution, unexpected outbound network connections during install, and unexpected files created during dependency installation. Because the vulnerability itself may not emit a distinctive runtime error, detection should correlate three signals: vulnerable pnpm version, missing integrity metadata in pnpm-lock.yaml, and package tarball retrieval from a modified or untrusted source.

• pnpm install --frozen-lockfile
• pnpm-lock.yaml
• integrity:
• resolution:
• tarball:
• registry.npmjs.org
• node_modules/.pnpm
• node_modules/.pnpm/*/node_modules/*/package.json
• preinstall
• postinstall
• prepare
• pnpm --version
• packageManager: pnpm@
• corepack prepare pnpm@
• ERR_PNPM_TARBALL_INTEGRITY
• ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY

What your security team should do

• Prioritize upgrading pnpm to 10.34.0 or later, or 11.4.0 or later, across CI/CD pipelines, release builders, developer containers, and standard workstation images.
• Search source repositories for pnpm-lock.yaml entries missing integrity fields and investigate recent commits that removed integrity metadata.
• Add CI policy checks that fail builds when pnpm-lock.yaml removes integrity fields or references unapproved registry domains.
• Review pull requests and commits touching pnpm-lock.yaml, especially those that only remove integrity fields or alter tarball URLs without corresponding dependency justification.
• Audit private registry, package mirror, and artifact proxy logs for unexpected package overwrites, unusual tarball downloads, or requests from build agents to unfamiliar package hosts.
• Restrict who can modify dependency lockfiles, package registry configuration, CI definitions, and private registry content.
• Pin and verify build tooling versions in CI images so vulnerable pnpm versions are not reintroduced through cached images or Corepack configuration.
• If suspicious lockfile changes are found, rebuild affected artifacts from a clean environment after upgrading pnpm and rotating any secrets exposed to build-time package scripts.