CVE-2024-47829

The package manager pnpm prior to version 9.15.0 mishandles overrides and global cache. Overrides from one workspace leak into npm metadata saved in global cache, potentially leading to unauthorized code execution in other workspaces.

pnpm before versions 10.34.5 and 11.11.0 accepts a scoped path traversal in the package name in a tarball dependency's package.json manifest. During installation, this can lead to package extraction outside node_modules and overwriting arbitrary filesystem paths, even when --ignore-scripts is used.

pnpm before versions 10.34.5 and from 11.0.0 until 11.11.0 parses package names from attacker-controlled pnpm-lock.yaml keys without validation, which can lead to package contents being written outside node_modules during installation. If lifecycle scripts are allowed, this can enable code execution.

In the pnpm package manager prior to versions 10.34.4 and 11.7.0, a crafted lockfile alias could be placed directly under a hoisted node_modules directory. Traversal aliases could escape that directory, while reserved aliases such as .bin or .pnpm could overwrite pnpm-owned layout.

pnpm before versions 10.34.4 and 11.8.0 accepts package names from the configDependencies section of pnpm-lock.yaml and uses them directly when creating config dependency symlinks under node_modules/.pnpm-config. A malicious repository can supply a crafted lock file containing a traversal-shaped config dependency name, leading to symlink creation outside the intended directory.

In pnpm prior to versions 10.34.4 and 11.7.0, a crafted patch entry could resolve outside the configured patches directory, allowing arbitrary file deletion via the pnpm patch-remove command.

The pnpm package manager from version 11.3.0 to 11.5.3 has a vulnerability where the `pnpm stage download` command derived a local filename from registry-controlled package name and version fields. A crafted manifest could escape the selected download directory and overwrite another reachable file.

In pnpm prior to versions 10.34.2 and 11.5.3, a vulnerability was discovered where manifest bin object keys such as "", ".", and ".." passed pnpm's bin-name guard. When a malicious package was installed globally, later global remove, update, or add-replacement flows could re-derive those names from the installed manifest and pass path.join(globalBinDir, binName) to removeBin. For "." this targets the global bin directory; for ".." this targets its parent.

pnpm package manager prior to versions 10.34.2 and 11.5.3 persists bootstrap metadata in the first YAML document of pnpm-lock.yaml. A malicious repository can bypass fresh package-manager resolution and cause pnpm to install and execute arbitrary code during automatic version switching.

pnpm prior to versions 10.34.2 and 11.5.3 allows installation of configDependencies declared in pnpm-workspace.yaml before command dispatch. A repository can declare pacquet or @pnpm/pacquet as a config dependency, and pnpm treats this repository-controlled dependency as an install-engine opt-in. During installation, pnpm resolves a platform-specific @pacquet/<platform>-<arch>/pacquet binary from node_modules/.pnpm-config/<packageName> and spawns it as the developer or CI user.