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.
The virtual store linker constructs package installation directories using path.join(modules, pkgName) where pkgName is extracted from lockfile packages keys via dp.parse(depPath).name without validation. A crafted pnpm-lock.yaml with traversal sequences in depPath keys (e.g., ../../../tmp/pwned@1.0.0) causes package content to be written to arbitrary filesystem paths during pnpm install. This is an incomplete fix of GHSA-fr4h-3cph-29xv — the safeJoinModulesDir containment helper was applied to the hoisted linker and symlinkDependency but NOT to the virtual store linker's lockfileToDepGraph.ts:233. Details Root Cause dp.parse() at pnpm11/deps/path/src/index.ts:135 extracts the package name as: This is a raw substring operation with zero validation that name is a valid npm package name. A depPath of ../../../tmp/pwned@1.0.0 yields name = '../../../tmp/pwned'. Vulnerable Code Path 1. pnpm-lock.yaml → lockfile.packages['../../../../../../../tmp/pwned@1.0.0'] (attacker-controlled…
Recommended action: Upgrade to 11.11.0 or 10.34.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When resolving a package, pnpm uses the resolved manifest name as a raw path segment for the isolated-linker import target. A tarball dependency whose package.json name is a scoped path traversal (@x/../../…/<abs path) is therefore extracted outside nodemodules, to an attacker-chosen absolute path, and can overwrite existing files there. Attacker controls the destination, filenames, and contents → arbitrary file write → code execution (e.g. ~/.zshrc, .git/hooks/pre-commit, another package's code). Occurs during pnpm install even with --ignore-scripts (no lifecycle scripts run), defeating that safety. Same class as the just-patched GHSA-hwx4 (transitive-dependency alias traversal) and GHSA-v23m (stage download manifest name/version traversal), in a sink their fixes did not cover: the isolated-linker import target keyed by the resolved name. Root cause - The isolated-linker import target is built with a raw path.join(modules, <resolved name) in…
Recommended action: Upgrade to 11.11.0 or 10.34.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm expands ${VAR} environment placeholders in the httpProxy / httpsProxy / noProxy settings read from a project's pnpm-workspace.yaml. Because a project manifest is repository-controlled, a malicious repository that a victim merely clones and runs pnpm install in can route all install traffic through an attacker proxy whose hostname or userinfo embeds — and thereby exfiltrates — an environment secret such as NPMTOKEN or GITHUBTOKEN. This bypasses a trust boundary pnpm deliberately enforces: env-placeholder expansion of request-destination settings is already suppressed for registry, pnprServer, registries and namedRegistries when they come from an untrusted project manifest, and the sibling .npmrc reader already classifies the proxy keys as request destinations. The manifest-side guard set simply omitted them. Impact An attacker who controls only the contents of a repository's pnpm-workspace.yaml — a public repo, a fork, or a supply-chain pull request — can read many values…
Recommended action: Upgrade to 11.11.0 or 10.34.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A crafted lockfile alias could reach several install-time filesystem joins. With --trust-lockfile or a frozen lockfile, traversal segments could create links outside the intended project or nodemodules boundary. This patch validates dependency names and every virtual-store slot before creating directories, links, bins, or hoisted entries. Security boundary - A shared safe-join helper rejects traversal, absolute, platform-specific, and reserved dependency names before filesystem materialization. - Direct and transitive dependency links, package links, bin destinations, and public/private hoist destinations use the same containment rule. - Global virtual-store slots validate the complete slot path, including version-derived components, before directory creation. - Snapshot slots and package names are checked before store initialization and before the current-lockfile fast path, closing the warm-install bypass. - Rejections preserve ERRPNPMINVALIDDEPENDENCYNAME. Exploit replay…
Recommended action: Upgrade to 12.0.0-alpha.5 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm accepts package names from the env lockfile configDependencies section and uses those names directly when creating config dependency symlinks under nodemodules/.pnpm-config. A malicious repository can commit a crafted pnpm-lock.yaml whose env-lockfile document contains a traversal-shaped config dependency name such as ../../PWNEDCFGDEP. During pnpm install, pnpm installs the config dependency and creates a symlink at a path derived from that name. In local testing against pnpm v11.5.1, this caused pnpm to create a symlink outside the intended config dependency directory: This works with --ignore-scripts, so it does not rely on lifecycle script execution. Vulnerable behavior The vulnerable behavior appears to be that configDependencies keys from the env lockfile are trusted as package names and used in filesystem paths without rejecting traversal components. The relevant pattern is: If pkgName is attacker-controlled and contains .., then path.join(configModulesDir,…
Recommended action: Upgrade to 11.8.0 or 10.34.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The patch-remove deletion-scope issue tracked as GHSA-72r4-9c5j-mj57 / CAND-PNPM-030 has been addressed in pnpm. A crafted patch entry could resolve outside the configured patches directory and cause pnpm patch-remove to delete an arbitrary reachable file. This patch validates the configured directory and every resolved target before unlinking anything, then deletes the final directory entry without following it. Security boundary - Traversal and absolute paths that resolve outside the configured patches directory are rejected before deletion. - Parent directories are canonicalized before deletion, including the case where a nested symlink points outside and the final outside entry is itself dangling. - The complete batch is validated before any file is removed. - Component-aware predicates accept valid names beginning with .. while still rejecting parent traversal, Windows drive escapes, and UNC escapes. - Valid files and symlinked patch directories whose canonical targets…
Recommended action: Upgrade to 11.7.0 or 10.34.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The hoisted dependency alias issue tracked as GHSA-fr4h-3cph-29xv / CAND-PNPM-059 has been addressed in both pnpm and pacquet. A crafted lockfile alias could be joined directly under a hoisted nodemodules directory. Traversal aliases could escape that directory, while reserved aliases such as .bin or .pnpm could overwrite pnpm-owned layout. This patch validates package-name semantics and path containment before graph insertion or filesystem work. Security boundary - The TypeScript hoisted graph uses the shared safe join helper at the actual dep.name sink. - The helper rejects traversal, absolute, platform-specific, and reserved package names. - Pacquet validates the hoister's dep.0.name before adding the graph node or recursing. - Both implementations return ERRPNPMINVALIDDEPENDENCYNAME. - Pacquet uses the same dependency-name containment rule at its hoisted graph sink as it uses for direct dependency aliases. Exploit replay Before the patch, a traversal alias in a hoisted…
Recommended action: Upgrade to 11.7.0 or 10.34.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The staged-tarball filename traversal reported as GHSA-v23m-ccfg-pq9h / CAND-PNPM-038 is fixed on main by pnpm/pnpm#12303, merged as 65443f4bdf1f0db9c8c7dc58fee25252607e9234. Before the fix, pnpm stage download 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. The merged fix validates both fields, derives one safe filename, and verifies the final destination before writing. Security boundary - Package names and semantic versions are validated before they can influence a local filename. - POSIX and Windows path separators are rejected by basename checks. - Stage download and tarball summary paths use the same filename helper. - The resolved output path must remain an immediate child of the selected download directory. - The stage identifier is already constrained to a UUID. Exploit replay Before 65443f4bdf, a traversal-bearing manifest version…
Recommended action: Upgrade to 11.5.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<details <summaryMaintainer Action Plan</summary Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. - Advisory: CAND-PNPM-085 / GHSA-4gxm-v5v7-fqc4 - Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-4gxm-v5v7-fqc4 - Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 - Shared patch branch: security/ghsa-batch-2026-06-09 - Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22 - Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec - Maintainer priority: appendix - Component: pnpm global add/remove bin cleanup - Patch area: bin name/path segment validation - Affected packages: npm:pnpm - CWE IDs: CWE-22, CWE-73 - Conservative CVSS: 6.5 / CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H - Next action: review the shared patch branch for this component, set the final…
Recommended action: Upgrade to 11.5.3 or 10.34.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<!-- maintainer-action:start -- Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. - Advisory: CAND-PNPM-063 / GHSA-w466-c33r-3gjp - Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-w466-c33r-3gjp - Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 - Shared patch branch: security/ghsa-batch-2026-06-09 - Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22 - Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec - Maintainer priority: start-here - Component: pnpm packageManager env lockfile - Patch area: package-manager env lockfile is re-resolved through trusted registries before execution - Affected packages: npm:pnpm, npm:@pnpm/installing.env-installer - CWE IDs: CWE-829, CWE-494, CWE-345 - Conservative CVSS: 8.8 /…
Recommended action: Upgrade to 11.5.3 or 10.34.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<!-- maintainer-action:start -- Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. - Advisory: CAND-PNPM-097 / GHSA-gj8w-mvpf-x27x - Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-gj8w-mvpf-x27x - Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 - Shared patch branch: security/ghsa-batch-2026-06-09 - Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22 - Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec - Maintainer priority: start-here - Component: pnpm configDependencies / pacquet delegation - Patch area: pacquet/configDependency lifecycle execution is not used as install engine without trust - Affected packages: npm:pnpm, npm:@pnpm/config.reader, npm:@pnpm/installing.commands - CWE IDs: CWE-829, CWE-78, CWE-494 - Conservative CVSS: 7.5 /…
Recommended action: Upgrade to 11.5.3 or 10.34.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Keep build approval for opaque dependency sources byte-exact for GHSA-5wx6-mg75-v57r / CAND-PNPM-123. Merged upstream commit bf1b731ee6 fixed the original name-only approval bypass by making build policy consume the resolved dependency identity. One collision remained: the generic peer-suffix normalizer also stripped parenthesized text from git, URL, tarball, file, and other opaque locators. Approval for one source string could therefore authorize a different attacker-controlled source whose locator normalized to the same value. Security boundary - Registry dependency identities still normalize legitimate peer suffixes and retain patch hashes. - Git, URL, tarball, file, directory, and otherwise opaque identities must match the complete resolved locator byte for byte. - Explicit denials use the same normalization as approvals. - Ignored-build output preserves the exact opaque identity, so the key pnpm asks a user to approve is the key policy later checks. - TypeScript pnpm and…
Recommended action: Upgrade to 11.5.3 or 10.34.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
<!-- maintainer-action:start -- Maintainer Action Plan This report is ready to review with the shared patch branch. Start with the PR and the expected fixed behavior, then use the detailed exploit narrative below only if you want to replay the original path. - Advisory: CAND-PNPM-122 / GHSA-3qhv-2rgh-x77r - Advisory URL: https://github.com/pnpm/pnpm/security/advisories/GHSA-3qhv-2rgh-x77r - Shared patch PR: https://github.com/pnpm/pnpm-ghsa-j2hc-m6cf-6jm8/pull/1 - Shared patch branch: security/ghsa-batch-2026-06-09 - Patch commit: a93449314f398cf4bdf2e28d033c02d37395ad22 - Base commit: origin/main 55a4035abf1ae3fe7208ba1f5ef43c5eff58ccec - Maintainer priority: start-here - Component: pnpm config/env replacement and registry auth - Patch area: project .npmrc env placeholders are not expanded into registry/auth destinations - Affected packages: npm:pnpm, npm:@pnpm/config.reader, rust:pacquet - CWE IDs: CWE-201, CWE-200, CWE-522 - Conservative CVSS: 6.5 /…
Recommended action: Upgrade to 11.5.3 or 10.34.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm's patch application pipeline (@pnpm/patch-package) performs no path validation on file paths extracted from .patch files. An attacker who contributes a malicious patch file via a pull request can write attacker-controlled content to or delete arbitrary files on the filesystem during pnpm install, as the user running the install. The diff --git header paths containing ../../ sequences traverse out of the package directory, and the traversal is difficult to catch in code review because patch file diff headers are opaque to most reviewers. Vulnerability Details During pnpm install, when a patchedDependencies entry is present in pnpm-workspace.yaml, pnpm reads the referenced .patch file and applies it via the embedded @pnpm/patch-package library. The applyPatchToDir function at patching/apply-patch/src/index.ts:12-13 calls process.chdir(opts.patchedDir), setting the working directory to the installed package location deep inside nodemodules/.pnpm/. The patch parser at…
Recommended action: Upgrade to 11.4.0 or 10.34.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm can send user-level unscoped npm authentication credentials to a registry chosen by a repository-local .npmrc file. In the reproduced case, the user's npm config contains a default registry and an unscoped authToken. The repository does not provide a token-bearing auth line. It only sets registry= to a different registry URL. During normal pnpm metadata/install workflows, pnpm binds the user-origin unscoped credential to the repository-selected registry and sends it as an Authorization header. This was reproduced with fake credentials and loopback registries only. No third-party registry or real token was used. Affected Behavior Observed Observed affected: - pnpm 10.33.2: pnpm install --ignore-scripts sends the user-level unscoped authToken to the repository-selected registry. - pnpm 11.1.3: pnpm install --ignore-scripts sends the user-level unscoped authToken to the repository-selected registry. - pnpm 11.2.1 (next-11 dist tag at testing time): pnpm install…
Recommended action: Upgrade to 11.4.0 or 10.34.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 - nodemodules/.bin or undeclared nodemodules/<name paths used by later command or module resolution Targets that are regular files can also be replaced with symlinks to a package…
Recommended action: Upgrade to 11.4.0 or 10.34.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm passes the lockfile-controlled git resolution.commit value to git fetch without a -- separator or commit-format validation. For git dependencies fetched through the shallow-fetch path, a malicious lockfile can replace the expected 40-character commit hash with a Git option such as --upload-pack=<command. For SSH and local transports, --upload-pack can execute the supplied command. HTTPS transports ignore --upload-pack, so the practical attack surface is primarily SSH or local git dependencies. Vulnerability Details The vulnerable path is in fetching/git-fetcher/src/index.ts. When a git dependency host is configured for shallow fetching, pnpm calls: Because resolution.commit is appended before a -- separator, Git can parse a commit value beginning with - as an option. The same file later passes the value to git checkout without a separator: resolution.commit comes from the lockfile and is typed as a plain string; pnpm does not validate it as a 40-character hexadecimal…
Recommended action: Upgrade to 11.4.0 or 10.34.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
pnpm's tarball extraction worker skips integrity verification when the integrity field is absent from the lockfile resolution. If an attacker can both modify pnpm-lock.yaml to remove the integrity: field and cause the referenced registry URL to serve altered package content, pnpm install --frozen-lockfile can install the altered package without an integrity error. npm's npm ci enforces integrity by default; pnpm's behavior of silently skipping verification is a pnpm-specific fail-open gap. Vulnerability Details The addTarballToStore function in worker/src/start.ts (lines 189-204) checks if (integrity) before verifying the tarball hash. The TarballResolution type declares integrity as optional (integrity?: string). When the lockfile omits the integrity field, the guard evaluates to false, skipping hash verification entirely. The worker then computes a new hash from the unverified content and stores it as legitimate. Proof of Concept Impact Supply chain compromise in…
Recommended action: Upgrade to 11.4.0 or 10.34.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
While it is unclear whether this should be classified as a vulnerability, it is being reported through this channel because the current behavior may represent an unsafe default. Summary pnpm install in non-frozen mode can accept new remote package content after detecting that the downloaded tarball does not match the integrity recorded in pnpm-lock.yaml. When a package is already locked with an integrity value, and the registry later serves different metadata and tarball content for the same package name and version, pnpm initially reports an integrity mismatch. However, plain pnpm install then performs a resolution repair, accepts the registry's new integrity, updates the lockfile, installs the new content, and exits successfully. This means the lockfile integrity check does not act as a hard stop by default. Reproduction Scenario 1. Run a local npm-compatible registry. 2. Publish or serve example-package@1.0.0 with tarball content v1. 3. Install it with pnpm: 4. Confirm…
Recommended action: Upgrade to 11.4.0 or 10.34.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A malicious codeload.github.com server can serve whatever tarball it wants and pnpm will install it regardless of the lockfile. Details The lockfile does not store the hash of the dependencies from https://codeload.github.com This means that if this server was compromised or a person's machine configuration was compromised, pnpm would download and install these dependencies. PoC Given the following package.json: This produces a lockfile like so: Notice that there is no hash. The b3eeb9b is not sufficient because I can configure my machine to resolve a compromised tarball from that url (I tested it out and pnpm just installs it). Impact Anyone relying on github git dependencies.
Recommended action: Upgrade to 11.0.7 or 10.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.
When pnpm processes a package's directories.bin field, it uses path.join() without validating the result stays within the package root. A malicious npm package can specify "directories": {"bin": "../../../../tmp"} to escape the package directory, causing pnpm to chmod 755 files at arbitrary locations. Note: Only affects Unix/Linux/macOS. Windows is not affected (fixBin gated by EXECUTABLESHEBANGSUPPORTED). Details Vulnerable code in pkg-manager/package-bins/src/index.ts:15-21: The bin field IS protected with isSubdir() at line 53, but directories.bin lacks this check. PoC Impact - Supply-chain attack via npm packages - File permissions changed from 600 to 755 (world-readable) - Affects non-dotfiles in predictable paths (dotfiles excluded by tinyglobby default) Suggested Fix Add isSubdir validation for directories.bin paths in pkg-manager/package-bins/src/index.ts, matching the existing validation in commandsFromBin():
Recommended action: Upgrade to 10.28.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability in pnpm's binary fetcher allows malicious packages to write files outside the intended extraction directory. The vulnerability has two attack vectors: (1) Malicious ZIP entries containing ../ or absolute paths that escape the extraction root via AdmZip's extractAllTo, and (2) The BinaryResolution.prefix field is concatenated into the extraction path without validation, allowing a crafted prefix like ../../evil to redirect extracted files outside targetDir. Details The vulnerability exists in the binary fetching and extraction logic: 1. Unvalidated ZIP Entry Extraction (fetching/binary-fetcher/src/index.ts) AdmZip's extractAllTo does not validate entry paths for path traversal: A ZIP entry with path ../../../.npmrc will be written outside nodeDir. 2. Unvalidated Prefix in BinaryResolution (resolving/resolver-base/src/index.ts) The basename variable comes from BinaryResolution.prefix and is used directly in path construction: PoC Attack Vector 1:…
Recommended action: Upgrade to 10.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability in pnpm's tarball extraction allows malicious packages to write files outside the package directory on Windows. The path normalization only checks for ./ but not .\. On Windows, backslashes are directory separators, enabling path traversal. This vulnerability is Windows-only. Details 1. Incomplete Path Normalization (store/cafs/src/parseTarball.ts:107-110) A path like foo\..\..\.npmrc does NOT contain ./ and bypasses this check. 2. Platform-Dependent Behavior (fs/indexed-pkg-importer/src/importIndexedDir.ts:97-98) - On Unix: Backslashes are literal filename characters (safe) - On Windows: Backslashes are directory separators (exploitable) PoC 1. Create a malicious tarball with entry package/foo\..\..\.npmrc 2. Host it or use as a tarball URL dependency 3. On Windows: pnpm install 4. Observe .npmrc written outside package directory Impact - Windows pnpm users - Windows CI/CD pipelines (GitHub Actions Windows runners, Azure DevOps) - Can overwrite…
Recommended action: Upgrade to 10.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A path traversal vulnerability in pnpm's bin linking allows malicious npm packages to create executable shims or symlinks outside of nodemodules/.bin. Bin names starting with @ bypass validation, and after scope normalization, path traversal sequences like ../../ remain intact. Details The vulnerability exists in the bin name validation and normalization logic: 1. Validation Bypass (pkg-manager/package-bins/src/index.ts) The filter allows any bin name starting with @ to pass through without validation: 2. Incomplete Normalization (pkg-manager/package-bins/src/index.ts) 3. Exploitation (pkg-manager/link-bins/src/index.ts:288) The normalized name is used directly in path.join() without validation. PoC 1. Create a malicious package: 2. Install the package: 3. Observe .npmrc created in project root (outside nodemodules/.bin). Impact - All pnpm users who install npm packages - CI/CD pipelines using pnpm - Can overwrite config files, scripts, or other sensitive files Verified on…
Recommended action: Upgrade to 10.28.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When pnpm installs a file: (directory) or git: dependency, it follows symlinks and reads their target contents without constraining them to the package root. A malicious package containing a symlink to an absolute path (e.g., /etc/passwd, ~/.ssh/idrsa) causes pnpm to copy that file's contents into nodemodules, leaking local data. Preconditions: Only affects file: and git: dependencies. Registry packages (npm) have symlinks stripped during publish and are NOT affected. Details The vulnerability exists in store/cafs/src/addFilesFromDir.ts. The code uses fs.statSync() and readFileSync() which follow symlinks by default: There is no check that absolutePath resolves to a location inside the package directory. PoC Impact - Developers installing local/file dependencies - CI/CD pipelines installing git dependencies - Credential theft via symlinks to ~/.aws/credentials, ~/.npmrc, ~/.ssh/idrsa Suggested Fix Use lstatSync to detect symlinks and reject those pointing outside the package…
Recommended action: Upgrade to 10.28.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.