Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
32 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
pnpm v10+ Git Dependency Script Execution Bypass Summary A security bypass vulnerability in pnpm v10+ allows git-hosted dependencies to execute arbitrary code during pnpm install, circumventing the v10 security feature "Dependency lifecycle scripts execution disabled by default". While pnpm v10 blocks postinstall scripts via the onlyBuiltDependencies mechanism, git dependencies can still execute prepare, prepublish, and prepack scripts during the fetch phase, enabling remote code execution without user consent or approval. Details pnpm v10 introduced a security feature to disable dependency lifecycle scripts by default (PR #8897). This is implemented by setting onlyBuiltDependencies = [] when no build policy is configured: File: pkg-manager/core/src/install/extendInstallOptions.ts (lines 290-291) This creates an allowlist that blocks all packages from running scripts during the BUILD phase in exec/build-modules/src/index.ts. However, git-hosted dependencies are processed differently.…
Recommended action: Upgrade to 10.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
HTTP tarball dependencies (and git-hosted tarballs) are stored in the lockfile without integrity hashes. This allows the remote server to serve different content on each install, even when a lockfile is committed. Details When a package depends on an HTTP tarball URL, pnpm's tarball resolver returns only the URL without computing an integrity hash: resolving/tarball-resolver/src/index.ts: The resulting lockfile entry has no integrity to verify: Since there is no integrity hash, pnpm cannot detect when the server returns different content. This affects: - HTTP/HTTPS tarball URLs ("pkg": "https://example.com/pkg.tgz") - Git shorthand dependencies ("pkg": "github:user/repo") - Git URLs ("pkg": "git+https://github.com/user/repo") npm registry packages are not affected as they include integrity hashes from the registry metadata. PoC See attached pnpm-bypass-integrity-poc.zip The POC includes: - A server that returns different tarball content on each request - A malicious-package…
Recommended action: Upgrade to 10.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A command injection vulnerability exists in pnpm when using environment variable substitution in .npmrc configuration files with tokenHelper settings. An attacker who can control environment variables during pnpm operations could achieve remote code execution (RCE) in build environments. Affected Components - Package: pnpm - Versions: All versions using @pnpm/config.env-replace and loadToken functionality - File: pnpm/network/auth-header/src/getAuthHeadersFromConfig.ts - loadToken() function - File: pnpm/config/config/src/readLocalConfig.ts - .npmrc environment variable substitution Technical Details Vulnerability Chain 1. Environment Variable Substitution - .npmrc supports ${VAR} syntax - Substitution occurs in readLocalConfig() 2. loadToken Execution - Uses spawnSync(helperPath, { shell: true }) - Only validates absolute path existence 3. Attack Flow Code Evidence pnpm/config/config/src/readLocalConfig.ts:17-18 pnpm/network/auth-header/src/getAuthHeadersFromConfig.ts:60-71…
Recommended action: Upgrade to 10.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The path shortening function is used in pnpm： However, it uses the md5 function as a path shortening compression function, and if a collision occurs, it will result in the same storage path for two different libraries. Although the real names are under the package name /nodemodoules/, there are no version numbers for the libraries they refer to. In the diagram, we assume that two packages are called packageA and packageB, and that the first 90 digits of their package names must be the same, and that the hash value of the package names with versions must be the same. Then C is the package that they both reference, but with a different version number. (npm allows package names up to 214 bytes, so constructing such a collision package name is obvious.) Then hash(packageA@1.2.3)=hash(packageB@3.4.5). This results in the same path for the installation, and thus under the same directory. Although the package names under nodemodoules are the full paths again, they are shared with C. What is…
Recommended action: Upgrade to 10.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm seems to mishandle overrides and global cache: 1. Overrides from one workspace leak into npm metadata saved in global cache 2. npm metadata from global cache affects other workspaces 3. installs by default don't revalidate the data (including on first lockfile generation) This can make workspace A (even running with ignore-scripts=true) posion global cache and execute scripts in workspace B Users generally expect ignore-scripts to be sufficient to prevent immediate code execution on install (e.g. when the tree is just repacked/bundled without executing it). Here, that expectation is broken Details See PoC. In it, overrides from a single run of A get leaked into e.g. ~/Library/Caches/pnpm/metadata/registry.npmjs.org/rimraf.json and persistently affect all other projects using the cache PoC Postinstall code used in PoC is benign and can be inspected in <https://www.npmjs.com/package/ponyhooves?activeTab=code, it's just a console.log 1. Remove store and cache On mac: rm -rf…
Recommended action: Upgrade to 9.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to construct a tarball that, when installed via npm or parsed by the registry is safe, but when installed via pnpm is malicious, due to how pnpm parses tar archives. Details The TAR format is an append-only archive format, and as such, the specification for how to update a file is to add a new record to the end with the updated version of the file. This means that it is completely valid for an archive to contain multiple copies of, say, package.json, and the expected behavior when extracting is that all versions other than the last get ignored. This is further complicated by that during tarball extraction, all package managers are configured to drop the first path component, so collisions can be created simply by using multiple root folders in the archive, even without performing updates. When pnpm extracts a tar archive via tar-stream, it appears to extract only the first file of a given name and discards all subsequent files with the same name. PoC Create a…
Recommended action: Upgrade to 8.6.8 or 7.33.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
PNPM prior to v6.15.1 was discovered to contain an untrusted search path which causes the application to behave in unexpected ways when users execute PNPM commands in a directory containing malicious content. This vulnerability occurs when the application is ran on Windows OS.
Recommended action: Upgrade to 6.15.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.