Summary
The virtual store linker constructs package installation directories using path.join(modules, pkgName) where pkgName is extracted from lockfile packages keys via dp.parse(depPath).name without validation. A crafted pnpm-lock.yaml with traversal sequences in depPath keys (e.g., ../../../tmp/pwned@1.0.0) causes package content to be written to arbitrary filesystem paths during pnpm install.
This is an incomplete fix of GHSA-fr4h-3cph-29xv — the safeJoinModulesDir containment helper was applied to the hoisted linker and symlinkDependency but NOT to the virtual store linker's lockfileToDepGraph.ts:233.
Details
Root Cause
dp.parse() at pnpm11/deps/path/src/index.ts:135 extracts the package name as:
const name = dependencyPath.substring(0, sepIndex)
This is a raw substring operation with zero validation that name is a valid npm package name. A depPath of ../../../tmp/pwned@1.0.0 yields name = '../../../tmp/pwned'.
Vulnerable Code Path
pnpm-lock.yaml → lockfile.packages['../../../../../../../tmp/pwned@1.0.0'] (attacker-controlled lockfile key)nameVerFromPkgSnapshot(depPath, pkgSnapshot) at lockfile/utils/src/nameVerFromPkgSnapshot.ts:16 → calls dp.parse(depPath) → returns { name: '../../../../../../../tmp/pwned' }lockfileToDepGraph.ts:232 → modules = path.join(dirInVirtualStore, 'node_modules')lockfileToDepGraph.ts:233 → dir = path.join(modules, pkgName) → resolves to /tmp/pwned (ESCAPES virtual store)storeController.importPackage(depNode.dir, ...) → writes package content to the traversed path
Why Existing Defenses Don't Catch It
depPathToFilename() — replaces / with + for the dirInVirtualStore path, but pkgName comes SEPARATELY from dp.parse() and is NOT passed through this functionverifyLockfileResolutions() — validates dependency map keys (aliases) via isValidDependencyAlias(), but never validates the depPath keys themselves- Lockfile parser —
yaml.load(lockfileRawContent) with no schema validation on packages keys
importPackage() — accepts targetDir and passes it directly to cafsStore.importPackage(targetDir, ...) with zero containment check- Integrity verification — requires a real fetchable package but does not validate the destination path
Escalation to RCE (non-default config)
When dangerouslyAllowAllBuilds: true is configured (or the traversal package name is in the explicit allowBuilds list), the same traversed path is used in the rebuild phase at after-install/src/index.ts:402,470. The attacker's postinstall script then executes with the victim's shell access. Under default config, allowBuild returns false for unknown packages, limiting impact to arbitrary file write.
Also Affected (PnP linker)
When nodeLinker: pnp is configured, lockfileToPackageRegistry() at lockfile/to-pnp/src/index.ts:105-110 uses the same unvalidated dp.parse().name in packageLocation construction, allowing the .pnp.cjs resolver map to point outside the virtual store. This is a lower-impact variant (PnP is not the default linker).
Impact
An attacker who can commit a crafted pnpm-lock.yaml to a repository (or supply one via a malicious package) can cause arbitrary file writes on the machine of any user who runs pnpm install. Written content is the actual package files from a real npm package (attacker controls which package and which destination).
Targets for arbitrary file write include:
.git/hooks/pre-commit — code execution on next git operation~/.local/bin/ — binary hijacking- Project source files — supply chain injection
Reproduction
Craft a pnpm-lock.yaml:
lockfileVersion: '9.0'
packages:
../../../../../../../tmp/pwned@1.0.0:
resolution: {integrity: sha512-<real-package-integrity>}
engines: {node: '>=14'}
snapshots:
../../../../../../../tmp/pwned@1.0.0: {}
importers:
.:
dependencies:
legitimate-name:
specifier: ^1.0.0
version: ../../../../../../../tmp/pwned@1.0.0Run pnpm install — package content is written to /tmp/pwned/ instead of the virtual store.
Recommended Fix
Apply safeJoinModulesDir (or equivalent validation) at:
lockfileToDepGraph.ts:233 — path.join(modules, pkgName)after-install/src/index.ts:402 — path.join(pkgModulesDir(depPath), pkgInfo.name)lockfile/to-pnp/src/index.ts:105-110 — PnP packageLocation
Alternatively, validate depPath keys during lockfile parsing to reject any that don't produce valid npm package names via dp.parse().
GHSA-fr4h-3cph-29xv fixed the hoisted linker path (lockfileToHoistedDepGraph.ts:222) by adding safeJoinModulesDir. The same fix was NOT applied to the virtual store linker, which uses the identical dp.parse().name → path.join() pattern at lockfileToDepGraph.ts:233.
References
manus-use Reporter
Summary
The virtual store linker constructs package installation directories using
path.join(modules, pkgName)wherepkgNameis extracted from lockfilepackageskeys viadp.parse(depPath).namewithout validation. A craftedpnpm-lock.yamlwith traversal sequences in depPath keys (e.g.,../../../tmp/pwned@1.0.0) causes package content to be written to arbitrary filesystem paths duringpnpm install.This is an incomplete fix of GHSA-fr4h-3cph-29xv — the
safeJoinModulesDircontainment helper was applied to the hoisted linker andsymlinkDependencybut NOT to the virtual store linker'slockfileToDepGraph.ts:233.Details
Root Cause
dp.parse()atpnpm11/deps/path/src/index.ts:135extracts the package name as:This is a raw substring operation with zero validation that
nameis a valid npm package name. A depPath of../../../tmp/pwned@1.0.0yieldsname = '../../../tmp/pwned'.Vulnerable Code Path
pnpm-lock.yaml→lockfile.packages['../../../../../../../tmp/pwned@1.0.0'](attacker-controlled lockfile key)nameVerFromPkgSnapshot(depPath, pkgSnapshot)atlockfile/utils/src/nameVerFromPkgSnapshot.ts:16→ callsdp.parse(depPath)→ returns{ name: '../../../../../../../tmp/pwned' }lockfileToDepGraph.ts:232→modules = path.join(dirInVirtualStore, 'node_modules')lockfileToDepGraph.ts:233→dir = path.join(modules, pkgName)→ resolves to/tmp/pwned(ESCAPES virtual store)storeController.importPackage(depNode.dir, ...)→ writes package content to the traversed pathWhy Existing Defenses Don't Catch It
depPathToFilename()— replaces/with+for thedirInVirtualStorepath, butpkgNamecomes SEPARATELY fromdp.parse()and is NOT passed through this functionverifyLockfileResolutions()— validates dependency map keys (aliases) viaisValidDependencyAlias(), but never validates the depPath keys themselvesyaml.load(lockfileRawContent)with no schema validation onpackageskeysimportPackage()— acceptstargetDirand passes it directly tocafsStore.importPackage(targetDir, ...)with zero containment checkEscalation to RCE (non-default config)
When
dangerouslyAllowAllBuilds: trueis configured (or the traversal package name is in the explicitallowBuildslist), the same traversed path is used in the rebuild phase atafter-install/src/index.ts:402,470. The attacker'spostinstallscript then executes with the victim's shell access. Under default config,allowBuildreturns false for unknown packages, limiting impact to arbitrary file write.Also Affected (PnP linker)
When
nodeLinker: pnpis configured,lockfileToPackageRegistry()atlockfile/to-pnp/src/index.ts:105-110uses the same unvalidateddp.parse().nameinpackageLocationconstruction, allowing the.pnp.cjsresolver map to point outside the virtual store. This is a lower-impact variant (PnP is not the default linker).Impact
An attacker who can commit a crafted
pnpm-lock.yamlto a repository (or supply one via a malicious package) can cause arbitrary file writes on the machine of any user who runspnpm install. Written content is the actual package files from a real npm package (attacker controls which package and which destination).Targets for arbitrary file write include:
.git/hooks/pre-commit— code execution on next git operation~/.local/bin/— binary hijackingReproduction
Craft a
pnpm-lock.yaml:Run
pnpm install— package content is written to/tmp/pwned/instead of the virtual store.Recommended Fix
Apply
safeJoinModulesDir(or equivalent validation) at:lockfileToDepGraph.ts:233—path.join(modules, pkgName)after-install/src/index.ts:402—path.join(pkgModulesDir(depPath), pkgInfo.name)lockfile/to-pnp/src/index.ts:105-110— PnPpackageLocationAlternatively, validate depPath keys during lockfile parsing to reject any that don't produce valid npm package names via
dp.parse().Relationship to GHSA-fr4h-3cph-29xv
GHSA-fr4h-3cph-29xv fixed the hoisted linker path (
lockfileToHoistedDepGraph.ts:222) by addingsafeJoinModulesDir. The same fix was NOT applied to the virtual store linker, which uses the identicaldp.parse().name → path.join()pattern atlockfileToDepGraph.ts:233.References