GHSA-FR4H-3CPH-29XV: Path Traversal and Directory Hijacking in pnpm and pacquet Dependency Resolution

The fast Node.js package manager, pnpm, and its Rust port, pacquet, are designed to optimize disk space and speed up dependency installation through content-addressable storage. In a typical default installation, pnpm uses a hard-link strategy alongside a virtual store to prevent duplicate modules on the file system. However, when users configure the manager to run with the hoisted node-linker topology (nodeLinker: hoisted), pnpm alters its default isolated behavior and falls back to a flattened layout similar to classic npm. This topology aims to maximize compatibility with legacy Node.js projects by positioning dependencies directly inside the top-level node_modules directory.

This specific configuration exposes an attack surface during the resolution of dependencies defined within the package's lockfile (pnpm-lock.yaml). When an installation command is executed in a headless context (such as clean developer setups or automated CI/CD jobs), the package manager builds a hoisted graph using dependency keys straight from the untrusted lockfile. Under this threat model, an attacker who can modify or submit a malicious lockfile can control dependency alias keys, paving the way for directory traversal attacks and structural filesystem modifications.

This security vulnerability, tracked under GitHub Security Advisory GHSA-FR4H-3CPH-29XV (internal tracking ID CAND-PNPM-059), belongs to the CWE-22 (Improper Limitation of a Pathname to a Restricted Directory) and CWE-73 (External Control of File Name or Path) weakness classes. If exploited, an unauthenticated attacker can execute arbitrary file writes outside the project directory or hijack execution paths of build tools within the node_modules workspace. The vulnerability has been confirmed to affect pnpm versions prior to 10.34.4 and versions 11.x prior to 11.7.0, along with the pacquet Rust port.

To analyze the root cause of this vulnerability, we must examine how pnpm constructs its dependency resolution mappings. When parsing the dependency graph in hoisted mode, the engine reads the alias mapping defined under each dependency block in the lockfile. In vulnerable versions, the resolver processes these alias strings without validating them against standard package-naming rules, immediately performing path-joining operations to designate where each symbolic link or directory structure must be materialized on disk.

The bug resides within the hoisted graph building logic, where the system calls the native path.join API with the base node_modules path and the unvalidated dependency alias retrieved from the lockfile snapshot. Because the native path.join algorithm automatically parses and resolves relative path indicators like .., any input containing directory traversal elements will propagate upward through the filesystem tree. Consequently, an alias defined as ../../../escape is resolved relative to the target node_modules folder, causing the destination pointer to escape the confinement boundary completely.

Furthermore, the system historically relied on an insufficient path containment check that compared the starts of resolved paths. This legacy check was easily bypassed by targeting pnpm's internal directories, such as node_modules/.bin/, which are located inside the top-level directory and therefore share the identical prefix. This allowed attackers to point their malicious aliases to internal binary shims, effectively overwriting legitimate executable paths while remaining within the technical boundaries of the original validation check.

The security vulnerability has been remediated in commit 352ae489f1b14ffdc19d2c6eacb1b06b098c2ddc. This patch replaces the insecure path concatenation routine with a strict input validation check leveraging validate-npm-package-name and robust path containment boundaries.

// Insecure pattern in vulnerable versions (lockfileToHoistedDepGraph.ts):
// The engine directly joined the target folder using unvalidated keys.
const dir = path.join(modules, dep.name)
const depLocation = path.relative(opts.lockfileDir, dir)

// Patched logic (lockfileToHoistedDepGraph.ts):
// The code now invokes safeJoinModulesDir to sanitize and check boundaries.
import { safeJoinModulesDir } from '@pnpm/symlink-dependency'
 
const dir = safeJoinModulesDir(modules, dep.name)
const depLocation = path.relative(opts.lockfileDir, dir)

The implementation of safeJoinModulesDir acts as a crucial defensive barrier. It imports validate-npm-package-name to verify that the alias is structural and adheres to standard npm constraints, which naturally prohibits relative traversals and special system directories.

// Implementation in safeJoinModulesDir.ts:
export function safeJoinModulesDir (modulesDir: string, alias: string): string {
  // 1. Strict name check to prevent reserved or traversal inputs
  if (!validateNpmPackageName(alias).validForOldPackages) {
    throw invalidDependencyNameError(modulesDir, alias)
  }
  const link = path.join(modulesDir, alias)
  const resolvedDir = path.resolve(modulesDir)
  const resolvedLink = path.resolve(link)
  // 2. Defensive prefix check ensures files reside within the directory
  if (resolvedLink === resolvedDir || !resolvedLink.startsWith(resolvedDir + path.sep)) {
    throw invalidDependencyNameError(modulesDir, alias, resolvedLink)
  }
  return link
}

This multi-tiered defense is highly effective. The validation phase rejects names with leading dots, uppercase characters outside allowed parameters, and reserved phrases, which immediately stops exploitation attempts using traversal payloads or targeting sensitive directories like .bin. By adding validate-npm-package-name, the patch prevents any exploitation paths through malformed aliases, while the secondary prefix check remains as a fallback mechanism.

An exploitation attempt against this vulnerability requires an attacker to inject a crafted lockfile into a repository. Because development workflows often accept modifications to pnpm-lock.yaml during standard pull requests, this file represents a low-complexity vector for supply chain attacks. The attacker alters the importers block in the lockfile to define a dependency with a relative path as the key, pointing to a remote registry or a localized workspace definition.

# Example payload in pnpm-lock.yaml
lockfileVersion: '9.0'
importers:
  .:
    dependencies:
      '../../../.ssh/authorized_keys': '1.0.0'
packages:
  '../../../.ssh/authorized_keys@1.0.0':
    resolution: { integrity: 'sha512-...' }

When a victim clones the repository and runs pnpm install, the installer reads the dependency tree and processes the malicious entry. Under hoisted mode, the client attempts to link the fetched directory contents using the calculated path, causing the system to write files directly into the victim's SSH directory. Alternatively, targeting .bin/tsc will write an executable script into the build tools directory, causing arbitrary script execution when the compilation process is triggered.

This attack vector requires no special privileges on the target system and relies purely on standard user interaction. The execution phase leverages existing shell access, meaning that any pipeline executing the build stage of a compromised repository will execute the payload under the privileges of the active installer.

The impact of this path traversal vulnerability is severe and directly affects system integrity. In a localized development environment, arbitrary file write permissions can escalate to remote code execution. For example, overwriting system profiles, shell rc files, or application-specific compilers can allow attackers to establish persistent backdoors that execute automatically upon system startup or when developers run basic commands.

In continuous integration and delivery (CI/CD) environments, the vulnerability is similarly severe. Because build agents typically possess credentials, API keys, and deployment certificates, compromising the runner during the initial pnpm install step allows immediate access to those secrets. An attacker who hijacks build tools like the TypeScript compiler can inject backdoors into production code artifacts before they are compiled and packaged.

The CVSS score is rated at 7.1 (High) with a vector of CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L. While confidentiality is not directly impacted during the initial write, the direct progression to execution hijacking makes this a priority for defensive teams.

The recommended and complete fix for this vulnerability is upgrading the package manager to a patched version. Development teams must immediately audit global installations and ensure local lockfiles require secure engines. For teams using the 10.x release cycle, pnpm must be updated to version 10.34.4 or above. For organizations using the latest 11.x releases, version 11.7.0 is the minimum safe release.

# Upgrade to the latest secure version globally
npm install -g pnpm@latest
# Alternatively, update using Corepack
corepack prepare pnpm@latest --activate

If upgrading the utility is not an immediate option, several workarounds can reduce the attack surface. Disabling the hoisted mode by removing nodeLinker: hoisted from .npmrc forces the package manager to use its default isolated symlink structure. Since isolated installations use a different code path that does not perform flat hoisting, the vulnerability is not exposed in this mode. Additionally, workflows in CI/CD environments must employ the --frozen-lockfile command to ensure that any unexpected modifications to lockfile schemas halt the process automatically.

Finally, development teams should implement automated check stages that parse lockfiles for relative paths or atypical character structures before execution. Incorporating automated security pipelines that flag keys with path traversal indicators ensures security even if developers are running older, unpatched package manager versions.