pnpm dependency alias path traversal: an indirect dependency can swap project folders for symlinks at install time, even with --ignore-scripts

Who is affected

The damage happens at install time when both of these hold:

At that point project paths have already been swapped for symlinks, so the project’s files can no longer be trusted. If the swapped target is an ordinary file, the maintainer advisory says the result is usually denial of service (that file stops working).

What happens later depends on whether something uses the swapped path. If git hooks, test or build scripts, CI steps or publishing later read or run those paths, the problem can escalate to running malicious code or to poisoned published artifacts (for example a swapped dist/ folder being packed and published).

Using --ignore-scripts makes no difference. The sources don’t say whether installing from an existing lockfile (the file recording the exact version of every dependency) with --frozen-lockfile also triggers it.

How it works

pnpm supports “aliases”, which let a project install a package under a different name. The problem: pnpm accepted the alias a package declared in its registry metadata even when it contained .. (go up one folder), then joined that alias onto node_modules to decide where to create a symlink (a filesystem shortcut) during install. It didn’t reject .., and it didn’t check that the final path was still inside node_modules.

The result: a malicious package deep in the dependency tree can make pnpm install replace a path in your project with a symlink to its own folder. The advisory lists possible targets including .git/hooks, .husky, .githooks, scripts/, tools/, bin/, tests/, .github/actions/<name>, dist/ before publishing, and node_modules/.bin. This kind of weakness is called relative path traversal (CWE-23).

Mind the timing: the install step only changes files. It does not mean code runs at install time. The attacker’s content can only run later, when a person or CI job uses the swapped path, for example git commit firing a git hook, pnpm test, pnpm run build, a CI step, or pnpm publish.

Why --ignore-scripts doesn’t help. According to pnpm’s docs, this option stops pnpm running scripts defined in the package.json of the project and its dependencies (such as postinstall). It controls whether packages get to run code. Here, pnpm itself creates the harmful symlink during its normal linking step, and no script is needed at all. --ignore-scripts is still worth using, but it doesn’t cover “the package manager writing files where it shouldn’t”, and it doesn’t cover code that fires later through git hooks, builds or CI.

The flawed approach (conceptual illustration, not pnpm’s source code):

// aliasName comes from the package's registry metadata and is untrusted
const target = path.join(nodeModulesDir, aliasName)
createSymlink(packageDir, target)   // never checks target is still inside node_modules

The fixed approach:

if (hasTraversalSegment(aliasName)) throw new Error('invalid alias')
const target = path.resolve(nodeModulesDir, aliasName)
if (!isInside(nodeModulesDir, target)) throw new Error('invalid alias')
createSymlink(packageDir, target)

According to the release notes, the fixed versions reject aliases with path traversal both when reading package manifests and when creating symlinks.

Timeline

Further reading

• Affected-version data disagrees: the CVE record’s structured data (CNA: GitHub) and NVD’s page summary say < 10.33.4, but the same CVE’s description text, NVD’s own CPE configuration and the maintainer advisory all say < 10.34.0. The 10.33.4 release notes list only a git tarball integrity fix, not this alias fix, which first appears in 10.34.0. This page follows the maintainer advisory and treats 10.33.4 as still vulnerable.
• Scoring: the only score is GitHub’s (CNA) CVSS 3.1 8.8, which NVD lists as secondary; NVD has published no score of its own, and there is no CVSS 4.0 score. CISA’s SSVC assessment is “proof of concept available, not automatable, total technical impact”. A proof of concept is not the same as attacks in the wild.
• Exploitation: no source reports exploitation in the wild. Our 2026-09-24 snapshot of the CISA KEV catalog does not list this CVE; not being listed does not mean it has not been exploited.
• Fix commit: neither the advisory nor the release notes link a specific commit or PR.
• Related but separate issue: pnpm 11.11–11.14 (blog dated 2026-07-18) added further hardening that stops a crafted pnpm-lock.yaml from writing outside the virtual store; that post does not mention this CVE.
• Some GitHub release pages were rendered with the year 2024, but the GitHub API and pnpm’s blog both give 2026-05-27.
• Related weakness type: CWE-23 (relative path traversal).