GHSA-72R4-9C5J-MJ57: Arbitrary File Deletion via Path Traversal in pnpm patch-remove

The pnpm package manager is an alternative to npm and yarn designed for performance and efficient disk utilization through hard links and a content-addressable store. To support custom dependency modification, pnpm offers a native patching framework. This subsystem exposes an attack surface when processing localized configuration assets such as package.json files or workspace lockfiles.

Historically, the 'patch-remove' command enabled developers to reverse local dependency patches and clean up corresponding patch files. However, the mechanism lacked security boundaries between the local project folder and the host filesystem. This design flaw introduced a path-traversal vulnerability that allows arbitrary file deletion.

Classified under CWE-22 (Improper Limitation of a Pathname to a Restricted Directory), the underlying issue stems from a lack of boundary validation during path resolution. An attacker who can influence configuration inputs can force the tool to clean up assets outside the designated directory structure, compromising filesystem integrity and causing denial-of-service conditions on vulnerable workstations and build runners.

The vulnerability is located in the core execution logic of the 'pnpm patch-remove' command. This utility is responsible for cleaning up local overrides configured within the 'patchedDependencies' block of the configuration. When executed, the command parses the workspace metadata to locate the patch files to delete. Prior to remediation, the application trusted the path strings provided in the configuration map directly without sanitization.

A typical 'patchedDependencies' configuration maps a target package to its localized patch file. Because the resolution routine accepted arbitrary string values, it did not verify that the resolved path remained inside the boundaries of the workspace's designated 'patches' folder. An attacker could introduce relative traversal sequences or absolute paths to target sensitive resources.

The system then executed a highly privilege-insensitive deletion routine using Node's 'fs.rm' with recursive and force options enabled. This API call resolved the user-controlled path relative to the workspace directory and deleted the target asset. Because no validation occurred, the utility deleted any host-accessible file or directory, bypassing structural folder boundaries.

The original vulnerable implementation resolved the target path and immediately invoked destructive file operations. To mitigate this, a subdirectory containment validation utility named 'isSubdirectory' was introduced to verify parent-child directory structures.

export function isSubdirectory (parentDir: string, childPath: string, pathUtils: PathUtils = path): boolean {
  const relativePath = pathUtils.relative(parentDir, childPath)
 
  return relativePath === '' || (
    relativePath !== '..' &&
    !relativePath.startsWith(`..${pathUtils.sep}`) &&
    !pathUtils.isAbsolute(relativePath)
  )
}

The utility uses relative path calculations to guarantee that the child path resides within the parent directory. The 'patch-remove' routine was also updated to validate the target's physical location against symbolic link attacks. By utilizing 'fs.realpath' to canonicalize paths, the system ensures that symbolic links cannot be abused to point outside the workspace.

const targetPath = path.resolve(ctx.lockfileDir, patchFile)
if (
  targetPath === ctx.patchesDir ||
  !isSubdirectory(ctx.patchesDir, targetPath)
) {
  throw new PnpmError('PATCH_FILE_OUTSIDE_PATCHES_DIR', `Patch file "${patchFile}" is outside the configured patches directory`)
}

Additionally, the recursive file deletion API was replaced with 'fs.unlink'. This prevents directory erasure if a target resolves to a folder structure, limiting the tool to deleting individual files and symbolic links.

Exploitation requires the manipulation of the workspace configuration. This is typically achieved by submitting a malicious pull request to a public repository or distributing a compromised configuration inside an open-source archive. The attacker injects a path traversal sequence into the 'patchedDependencies' structure within 'package.json'.

{
  "pnpm": {
    "patchedDependencies": {
      "target-package": "../../../../etc/passwd"
    }
  }
}

When a developer or an automated CI/CD pipeline runs the 'pnpm patch-remove target-package' command, the execution flow proceeds as follows:

1. The command parses 'package.json' and reads the entry for 'target-package'.
2. The system resolves the path '../../../../etc/passwd' relative to the workspace directory.
3. The cleanup routine executes the file deletion against the resolved target.
4. The target file is deleted, resulting in system modification or configuration destruction.

In automation environments, this primitive can be used to destroy credentials, configurations, or critical software dependencies to disrupt operations.

The primary impact of this vulnerability is arbitrary file deletion on the system hosting the pnpm process. The severity depends on the privileges of the user executing the 'pnpm' command. On local development workstations, this can lead to the loss of source code, configuration files, and authentication keys.

In continuous integration and continuous deployment (CI/CD) environments, the impact is significant. Automated pipelines often run with elevated permissions. If an attacker can trigger the vulnerability inside a build runner, they can destroy pipeline configurations, build assets, or deployment credentials. This results in pipeline denial of service or configuration tampering.

Because the vulnerability does not directly expose read capabilities, it represents a threat to data integrity and availability rather than confidentiality. However, deleting critical security controls can weaken a system's overall security posture.

To address the vulnerability, users must update pnpm to a version containing the path verification patch. The fix was integrated into the main branch and backported to the version 10 release line.

For environments where immediate patching is not possible, the following defense-in-depth measures are recommended:

1. Review all pull requests that modify configuration files, including 'package.json' and 'pnpm-lock.yaml', before running command-line utilities.
2. Execute build tasks within isolated containers that restrict filesystem access, limiting the scope of any potential file deletion.
3. Run development and CI/CD tools with the minimum necessary filesystem permissions to prevent access to sensitive directories.