CVE-2026-50016

What it actually does

pnpm versions before 10.34.0 and 11.4.0 fail to safely validate transitive dependency aliases supplied through package registry metadata. A malicious package can publish dependency metadata where an alias contains path traversal sequences such as ../. During dependency linking, pnpm later treats that alias as a filesystem path and may create symlinks outside the intended dependency tree. This can replace files or directories in the current project with symlinks to attacker-controlled package contents, even when installation is run with --ignore-scripts. The result is project file tampering, dependency graph poisoning, and potential compromise of build or runtime behavior without relying on lifecycle script execution.

Why it matters to the business

Organizations using vulnerable pnpm versions can have application source trees, build inputs, or configuration files silently altered during dependency installation. In practice, this can lead to compromised builds, malicious code being shipped, loss of integrity in software artifacts, credential exposure through tampered tooling or configuration, and CI/CD disruption. Although this issue is not currently listed in CISA KEV, has low EPSS at the time provided, and has no reported exploit maturity, the CVSS severity is high because successful exploitation can affect confidentiality, integrity, and availability once a developer or build system installs a malicious dependency.

How an attack unfolds

An attacker publishes or compromises a package in a registry and crafts its package metadata so that a transitive dependency alias contains path traversal segments. A victim project then adds, updates, or resolves a dependency path that causes pnpm to fetch that malicious package metadata. When a vulnerable pnpm version performs installation, including installations that use --ignore-scripts as a hardening control, pnpm processes the malicious alias and later uses it as a filesystem path while linking dependency nodes. Instead of keeping links confined to the expected node_modules structure, pnpm can create symlinks that traverse into the project directory and replace existing project paths with links to attacker-controlled dependency package directories. Subsequent build, test, packaging, or runtime commands may consume the attacker-controlled files as though they were legitimate project files.

How to fix it

Upgrade pnpm to a fixed release: 10.34.0 or later on the 10.x line, or 11.4.0 or later on the 11.x line. Enforce the fixed pnpm version in developer workstations and CI images, including container base images, build runners, and package-manager bootstrap tooling such as Corepack. After upgrading, delete node_modules and reinstall dependencies from a trusted lockfile so any malicious symlinks created by a vulnerable install are removed. Review recent dependency additions and updates, especially transitive dependency changes from untrusted, newly published, typosquatted, or registry-substituted packages. Treat --ignore-scripts as insufficient mitigation for this issue; the vulnerable behavior occurs during dependency linking rather than lifecycle script execution. If immediate upgrade is not possible, restrict installs to trusted registries, require lockfile-only/frozen installs, block packages whose metadata contains dependency aliases with path traversal or path separators, and run installs in disposable, least-privileged build environments.

How to confirm the fix worked

Confirm the active pnpm version with pnpm --version in every build image, CI runner, developer environment, and automation path that performs installs. The reported version should be 10.34.0 or later for pnpm 10, or 11.4.0 or later for pnpm 11. Rebuild CI images and rerun jobs to ensure cached package-manager binaries are not still being used. Validate that installs from clean workspaces produce no unexpected symlinks in the project root or source tree, especially symlinks that point into node_modules/.pnpm package directories. Inspect pnpm-lock.yaml and resolved registry metadata for dependency aliases containing ../, ..\, URL-encoded traversal, or path separator characters where package aliases are expected. Run a clean install after removing node_modules and compare the resulting filesystem tree against a known-good baseline.

Typical attack path

1. Attacker identifies projects or ecosystems likely to use pnpm versions earlier than 10.34.0 or 11.4.0.
2. Attacker publishes a malicious registry package, compromises an existing package, or abuses dependency confusion/typosquatting to get a malicious package selected.
3. The malicious package metadata includes a transitive dependency alias containing path traversal sequences.
4. A developer workstation or CI job runs pnpm install, pnpm update, or an equivalent install workflow that resolves the malicious package.
5. Vulnerable pnpm accepts the alias and uses it during dependency linking.
6. pnpm creates symlinks outside the intended dependency node location, replacing project paths with symlinks to attacker-controlled package directories.
7. Later development, test, build, package, or deployment steps read the attacker-controlled files, enabling source tampering, build poisoning, or operational disruption.

How to detect it

Investigate whether vulnerable pnpm versions performed installs after dependency additions or updates. Useful sources include CI job logs, build runner filesystem snapshots, package registry or artifact proxy logs, source-control lockfile diffs, endpoint telemetry from developer workstations, and file integrity monitoring on build workspaces. Look for pnpm install or update activity using versions below 10.34.0 or 11.4.0, especially with --ignore-scripts where teams may have assumed installs were safe. Review pnpm-lock.yaml changes for dependency aliases containing traversal sequences, backslashes, forward slashes, encoded dots, or encoded slashes. Inspect workspaces for unexpected symlinks outside node_modules or symlinks in project source/configuration paths that point into node_modules/.pnpm or a package cache. Correlate suspicious symlink creation with recently introduced packages, registry downloads, lockfile rewrites, and unexpected changes in build outputs, package contents, test behavior, or configuration files. If suspicious artifacts are found, preserve the workspace, lockfile, pnpm store metadata, CI logs, registry responses, and the resolved package tarballs for forensic review.

• pnpm install --ignore-scripts
• pnpm-lock.yaml
• ../
• ..\
• %2e%2e%2f
• %2e%2e/
• ..%2f
• ..%5c
• node_modules/.pnpm/
• link:../
• file:../
• dependencies:
• optionalDependencies:
• devDependencies:

What your security team should do

• Prioritize upgrading pnpm across CI/CD, build containers, developer laptops, and automation to 10.34.0 or later, or 11.4.0 or later.
• Remove and regenerate node_modules in repositories that performed installs with vulnerable pnpm versions after dependency changes.
• Search recent dependency changes and lockfile diffs for suspicious aliases containing path traversal, path separators, or URL-encoded traversal sequences.
• Add CI guardrails that fail builds when dependency alias names contain ../, ..\, encoded traversal, or absolute-path-like values.
• Prefer frozen lockfile installs from trusted registries and require review for dependency additions, lockfile rewrites, or registry source changes.
• Harden build jobs by running installs in ephemeral, least-privileged workspaces with no access to production credentials or signing keys unless strictly required.
• Monitor package registry, proxy, and CI logs for new or unusual packages introduced shortly before unexpected file changes or build behavior.
• Do not rely on --ignore-scripts as the sole protection for dependency installation risk in pnpm workflows.