CVE-2026-50014

What it actually does

CVE-2026-50014 is a command injection issue in pnpm’s handling of git dependencies during shallow fetch operations. A lockfile-controlled git resolution.commit value is passed to git fetch without a -- argument separator and without validating that the value is a legitimate 40-character commit hash. If an attacker can influence the pnpm lockfile, they can replace the expected commit hash with a Git command-line option such as --upload-pack=<command>. For SSH and local git transports, Git may execute the supplied upload-pack command, allowing attacker-controlled command execution in the context of the user or automation process running pnpm. HTTPS transports generally ignore --upload-pack, so practical exploitation is mainly limited to SSH-based or local git dependencies.

Why it matters to the business

Successful exploitation can compromise developer workstations, CI/CD runners, build systems, or release pipelines that install dependencies from a malicious or tampered pnpm lockfile. This can lead to theft of source code, credentials, package registry tokens, SSH keys, cloud credentials, or signing materials, and may enable supply-chain compromise of downstream software artifacts. The CVSS score is moderate, EPSS is currently low, it is not listed in CISA KEV, and no mature exploitation is reported, but the impact is significant where pnpm lockfiles are accepted from untrusted branches, pull requests, forks, or third-party code contributions.

How an attack unfolds

An attacker first needs a way to introduce or modify a pnpm lockfile that will be processed by a victim, developer workstation, CI job, or automated build. They craft a git dependency entry that uses the shallow-fetch path and replaces the expected resolution.commit hash with a Git option such as --upload-pack=<command>. When a vulnerable pnpm version processes the lockfile and invokes git fetch for an SSH or local git dependency, the unvalidated commit value is interpreted as a Git option rather than as a commit identifier. For affected transports, Git can run the attacker-supplied upload-pack command, resulting in command execution under the privileges of the pnpm process. The attacker may then exfiltrate secrets from the build environment, alter build outputs, install persistence on a developer machine, or use stolen credentials to move further into source control, package registry, or cloud environments.

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. Ensure the upgraded pnpm version is used consistently across developer workstations, CI/CD images, build containers, package manager bootstrap tooling, and repository automation. As mitigations, treat pnpm-lock.yaml changes as security-sensitive, require review for lockfile modifications, avoid running dependency installation from untrusted pull requests with access to secrets, and restrict or disable SSH/local git dependencies where practical. Prefer HTTPS git dependencies when possible, since the described --upload-pack vector is not practically effective over HTTPS. Pin CI jobs to known-good pnpm versions and rebuild base images that may contain vulnerable pnpm releases.

How to confirm the fix worked

Confirm that all relevant environments report pnpm version 10.34.0 or later, or 11.4.0 or later, using pnpm --version. Review CI/CD runner images, developer environment setup scripts, container images, and package-manager bootstrap commands to ensure they do not install vulnerable pnpm versions. Search repositories for git dependencies in pnpm-lock.yaml, especially entries using SSH-style URLs, file/local paths, or other local git transports. Validate that resolution.commit values in pnpm-lock.yaml are 40-character hexadecimal commit hashes and not command-line options or strings beginning with a hyphen. Run dependency installation in a controlled test environment after upgrading and verify that malicious or malformed commit values are rejected or not interpreted as Git options.

Typical attack path

1. Identify a project or build workflow using vulnerable pnpm versions prior to 10.34.0 or 11.4.0.
2. Gain an opportunity to submit or alter a pnpm lockfile, such as through a pull request, fork, compromised dependency source, or tampered repository content.
3. Add or modify a git dependency that is fetched through pnpm’s shallow-fetch path using an SSH or local git transport.
4. Replace the expected 40-character resolution.commit value with a malicious Git option such as --upload-pack=<command>.
5. Wait for a developer, CI runner, or build automation process to run pnpm install or another pnpm command that resolves dependencies from the lockfile.
6. Abuse Git’s handling of --upload-pack for SSH or local transports to execute the supplied command in the pnpm process context.
7. Use the execution opportunity to steal secrets, modify build artifacts, establish persistence, or pivot to adjacent development and release systems.

How to detect it

Investigate whether pnpm install or related pnpm commands processed untrusted or recently modified pnpm-lock.yaml files before pnpm was upgraded. Review source control history for pnpm-lock.yaml changes that alter git dependency resolution.commit fields, especially values beginning with -- or containing --upload-pack. Examine CI/CD logs, build logs, shell history, EDR process telemetry, and command-line auditing for git fetch invocations containing --upload-pack or unexpected commands launched as child processes of pnpm, node, git, ssh, or shell interpreters. Focus on builds triggered by pull requests, forks, external contributors, dependency update bots, and recent lockfile-only changes. Look for post-exploitation activity such as access to environment variables, credential files, SSH keys, package registry tokens, cloud metadata services, unexpected outbound network connections from build runners, modified build artifacts, or unusual package publishing activity following dependency installation.

• --upload-pack=
• git fetch --upload-pack
• resolution.commit: --
• resolution.commit "--
• pnpm-lock.yaml
• pnpm install
• pnpm i
• pnpm --version
• git+ssh://
• ssh://git@
• git@github.com:
• git@gitlab.com:
• git@bitbucket.org:
• file:
• ../
• .git
• id_rsa
• id_ed25519
• known_hosts
• NPM_TOKEN
• NODE_AUTH_TOKEN
• GITHUB_TOKEN
• GIT_SSH_COMMAND
• SSH_AUTH_SOCK

What your security team should do

• Upgrade pnpm everywhere to 10.34.0 or later, or 11.4.0 or later, prioritizing CI/CD runners and build systems that have access to secrets or publishing credentials.
• Inventory repositories using pnpm and identify those with git dependencies, especially SSH or local git dependencies in pnpm-lock.yaml.
• Add automated checks to block pnpm-lock.yaml resolution.commit values that are not 40-character hexadecimal hashes or that begin with a hyphen.
• Treat lockfile changes from forks, external contributors, or untrusted branches as high-risk and require maintainer review before running privileged CI jobs.
• Prevent pull-request CI from exposing secrets, SSH keys, package publishing tokens, cloud credentials, or signing keys to dependency installation steps.
• Add detection logic for suspicious git fetch arguments involving --upload-pack in build logs, shell history, EDR telemetry, and process command-line logs.
• Rebuild CI images and developer bootstrap tooling to remove vulnerable pnpm versions rather than relying only on local upgrades.
• Where feasible, migrate SSH/local git dependencies to HTTPS or package-registry dependencies to reduce exposure to this vector.