CVE-2026-50015

What it actually does

CVE-2026-50015 is a path traversal flaw in pnpm's patch application pipeline, specifically @pnpm/patch-package. Before pnpm 10.34.0 and 11.4.0, paths parsed from .patch files are not validated before being applied. A malicious patch can place ../ sequences in diff headers such as diff --git a/../../target b/../../target, causing pnpm install to write attacker-controlled content outside the intended package directory or delete arbitrary files accessible to the user running the install. The impact is primarily integrity and availability: source files, configuration files, scripts, build artifacts, or user-writable system files can be overwritten or removed during dependency installation.

Why it matters to the business

An attacker who can get a malicious patch file accepted into a repository, dependency update, or development workflow can tamper with files during installation. In practice, this can break builds, alter application behavior, corrupt source or configuration files, introduce backdoors into build outputs, or disrupt CI/CD pipelines. The issue is not currently listed in CISA KEV and has low EPSS at the time of analysis, but the attack is simple once a malicious patch reaches a developer or build process, and the opaque nature of patch headers makes it easy to miss during review.

How an attack unfolds

An attacker first needs a way to contribute or influence a patch file consumed by pnpm, commonly through a pull request, dependency maintenance change, compromised contributor account, or malicious repository update. The attacker crafts a .patch file whose diff --git header contains traversal sequences such as ../../ so that the target path escapes the intended package directory. When a developer, CI job, or build system runs pnpm install with a vulnerable pnpm version, @pnpm/patch-package processes the patch without properly normalizing and rejecting the path. The patch operation then writes attacker-controlled content to, or deletes, files reachable by the account running pnpm. Depending on what is modified, the attacker may cause build failure, change application code, alter scripts executed later in the pipeline, or persist malicious content in the workspace.

How to fix it

Upgrade pnpm to a fixed release: use pnpm 10.34.0 or later on the 10.x line, or pnpm 11.4.0 or later on the 11.x line. Ensure CI/CD images, developer workstations, container build images, package manager bootstrap scripts, and pinned toolchain definitions all use a fixed pnpm version. Audit existing .patch files before running installs, especially recently added or modified patches, and reject any patch whose diff headers or file paths contain traversal sequences or absolute paths. As a temporary mitigation, restrict who can add or modify patch files, require additional review for .patch changes, run pnpm install in isolated containers with minimal filesystem access, and avoid running installs with privileged accounts.

How to confirm the fix worked

Confirm the active pnpm version in all build and developer contexts with pnpm --version and verify it is 10.34.0 or later for pnpm 10.x, or 11.4.0 or later for pnpm 11.x. Search repositories for .patch files containing suspicious paths, especially diff --git lines with ../, absolute paths, URL-encoded traversal, or paths that normalize outside the expected package patch directory. Re-run builds in a clean environment after upgrading and confirm patch application succeeds without writing outside the workspace. Where possible, use filesystem monitoring or sandboxing during pnpm install to verify that patch application does not modify files outside expected project directories.

Typical attack path

1. Identify a project that uses pnpm patches or accepts patch files through code review or dependency maintenance workflows.
2. Submit or introduce a malicious .patch file containing path traversal sequences in diff --git header paths.
3. Rely on reviewers overlooking the malicious traversal because patch headers are not commonly scrutinized in detail.
4. Wait for a developer workstation, CI runner, or build process to execute pnpm install using pnpm prior to 10.34.0 or 11.4.0.
5. The vulnerable patch application pipeline writes or deletes files outside the intended package directory with the privileges of the pnpm process.
6. Use the modified files to disrupt builds, alter application behavior, tamper with scripts, or prepare a follow-on compromise.

How to detect it

To determine whether exploitation already occurred, review source repositories, pull requests, and commit history for added or modified .patch files, especially those introduced by new, unusual, or compromised contributors. Search patch contents for diff headers containing ../ or paths that normalize outside the intended package directory. Review CI/CD logs for pnpm install runs that occurred while using pnpm versions earlier than 10.34.0 or 11.4.0 and correlate them with patch file changes. Inspect filesystem audit logs, endpoint telemetry, and build runner artifacts for unexpected file writes or deletions during pnpm install, particularly modifications to scripts, package metadata, application source files, shell profiles, CI configuration, or build outputs. If available, compare known-good repository state against post-install workspaces to identify files changed by the install process rather than by source control. Because exploitation may not produce a unique network indicator, prioritize repository forensics, build log review, and filesystem event correlation around pnpm install execution.

• diff --git a/../
• diff --git b/../
• diff --git a/../../
• diff --git b/../../
• diff --git a/../../../
• diff --git b/../../../
• diff --git a//
• diff --git b//
• diff --git a/%2e%2e/
• diff --git b/%2e%2e/
• diff --git a/..\\
• diff --git b/..\\
• pnpm install
• @pnpm/patch-package
• .patch

What your security team should do

• Prioritize upgrading pnpm across CI/CD runners, build containers, developer base images, and repository toolchain pins to 10.34.0 or 11.4.0 or later.
• Create repository scanning rules that flag .patch files containing traversal sequences in diff headers or file paths.
• Require mandatory review from trusted maintainers for any pull request that adds or modifies .patch files, package manager configuration, or dependency patch settings.
• Run pnpm install in isolated, least-privilege build environments with no access to sensitive host paths, credentials, or shared writable directories.
• Review recent pull requests and commits that introduced or changed .patch files, especially within the 47 days since publication.
• Add CI checks that fail builds if patch files contain ../, absolute paths, or paths that normalize outside the repository or package directory.
• Monitor build logs and filesystem events for unexpected file creation, modification, or deletion during pnpm install.
• If suspicious patch activity is found, treat the affected workspace or CI runner as potentially tampered with and rebuild from a clean image after rotating any exposed credentials.