Severity by source
AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
Attacker controls a distributed lockfile (PR:N) but needs victim to run install (UI:R) and a non-default SSH/local transport (AC:H); injected command execution yields full C/I/A:H.
Primary rating from Vendor (GitHub_M).
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
Lifecycle Timeline
8DescriptionNVD
pnpm is a package manager. Prior to 10.34.0 and 11.4.0, pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command>. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. This vulnerability is fixed in 10.34.0 and 11.4.0.
AnalysisAI
Arbitrary command execution in pnpm before 10.34.0 and 11.4.0 allows a malicious lockfile to run code on a developer's machine during pnpm install. Because pnpm passes the lockfile-controlled resolution.commit to git fetch/git checkout without a -- separator or 40-hex-character validation, an attacker can substitute the expected commit hash with a Git option such as --upload-pack=<command>, which Git executes for SSH and local (file://) transports. Publicly available exploit code exists (POC), but there is no public exploit identified as actively exploited; EPSS is low (0.17%, 7th percentile), consistent with a developer-targeted supply-chain vector rather than mass internet scanning.
Technical ContextAI
The flaw is a classic argument injection (CWE-88) in pnpm's git dependency fetcher (fetching/git-fetcher/src/index.ts). When a git host is configured for shallow fetching, pnpm builds the command git fetch --depth 1 origin <resolution.commit> and later git checkout <resolution.commit>, appending the lockfile value as a positional argument with no -- end-of-options marker. Git treats any token beginning with - as an option, so a value like --upload-pack=touch /tmp/pwned is interpreted as the --upload-pack flag. Git's --upload-pack specifies the program run on the remote end; for SSH and local transports Git invokes that string as a shell command on the local/origin side, yielding code execution. HTTPS transport does not honor --upload-pack, so it is not exploitable. The root cause is that resolution.commit is typed as a plain string and is never validated against /^[0-9a-f]{40}$/i. The single CPE provided (cpe:2.3:a:pnpm:pnpm:*) confirms the affected component is the pnpm package manager itself.
RemediationAI
Upgrade pnpm to a fixed release: Vendor-released patch: 10.34.0 (for the 10.x line) or 11.4.0 (for the 11.x line), per advisory https://github.com/pnpm/pnpm/security/advisories/GHSA-p4xf-rf54-rj3x. The fix adds a -- separator before lockfile-controlled revision values and validates resolution.commit against a 40-character hex pattern. Until you can upgrade, reduce exposure with these specific controls: treat any change to pnpm-lock.yaml as security-sensitive and require code review of lockfile diffs before merging or before running install in CI (side effect: added review friction on legitimate dependency bumps); prefer HTTPS git transport for any git: dependencies and avoid SSH or local file:// git dependencies, since HTTPS ignores --upload-pack and is not exploitable (side effect: may require credential/token reconfiguration for private repos); and run pnpm install for untrusted repositories inside an isolated/ephemeral sandbox or container so injected command execution cannot reach developer credentials or the host (side effect: slower local onboarding). Audit existing lockfiles for any resolution.commit value that is not a 40-character hexadecimal hash.
Arbitrary code execution in the pnpm package manager (versions 10.0.0 through 10.25) lets a git-hosted dependency run co
pnpm is a package manager. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentica
Path traversal in pnpm before 10.34.0 and 11.4.0 lets a malicious registry package smuggle '../' segments inside a trans
Arbitrary code execution in the pnpm package manager (versions prior to 10.34.2 and 11.5.3) lets a malicious repository
Arbitrary command execution in pnpm before 10.34.2 and 11.5.3 allows a malicious repository to run attacker-chosen nativ
Supply-chain integrity bypass in pnpm package manager (versions ≤10.26.2, per description; GHSA states <10.26.0) allows
PNPM v6.15.1 and below was discovered to contain an untrusted search path which causes the application to behave in unex
Integrity-check bypass in the pnpm package manager (versions before 10.34.0/10.34.1 and 11.0.0-11.3.x) lets tampered pac
Command injection in pnpm versions 6.25.0 through 10.26.2 allows attackers controlling environment variables to execute
Arbitrary file write and deletion in pnpm package manager (versions prior to 10.34.0 and 11.4.0) lets a malicious contri
Path traversal in pnpm's `pnpm stage download` command (versions 11.3.0 through 11.5.2) lets a malicious or compromised
Path traversal in pnpm's global package management flows allows deletion of the global bin directory or its parent when
Same technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39490
GHSA-p4xf-rf54-rj3x