CVE-2026-55699

What it actually does

The flaw is a path traversal / unsafe path construction issue in pnpm global package handling. Before pnpm 10.34.2 and 11.5.3, malformed package manifests could define dangerous bin object keys such as an empty string, ".", or "..". Those names could bypass pnpm's bin-name validation during installation and later be re-derived from the installed manifest during global remove, update, or add-replacement operations. pnpm would then call path-joining logic against the global binary directory using the unsafe bin name. A bin name of "." could target the global binary directory itself, while ".." could target its parent directory. The primary impact is availability: deletion or disruption of globally installed command shims or related directories used by developer tooling and automation.

Why it matters to the business

An attacker who convinces a user or automation workflow to globally install a malicious pnpm package can cause later pnpm maintenance actions to remove or damage global tool directories. This can break developer workstations, CI/CD runners, build agents, release automation, and systems that rely on globally installed command-line tools. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing and no known public exploit maturity reported, but the issue is still operationally relevant because package-manager behavior is often embedded in build pipelines and developer workflows.

How an attack unfolds

An attacker publishes or supplies a malicious npm package whose package.json manifest contains a crafted bin object key such as ".", "..", or an empty string. A victim must install that package globally using an affected pnpm version. The initial global install places the package metadata where pnpm can later read it. The destructive behavior is triggered during a subsequent global package-management operation, such as removing the malicious package, updating it, or replacing it through a global add flow. During that later operation, affected pnpm versions re-read the manifest, derive the unsafe bin name, and pass it into path construction for bin removal. Instead of targeting only the expected executable shim, the operation can target the global bin directory or its parent, causing removal or disruption of globally installed tools. Exploitation requires user interaction or a build/automation process that installs the malicious package globally; there is no indication from the supplied data that this is actively exploited in the wild.

How to fix it

Upgrade pnpm to a fixed release: 10.34.2 or later for the 10.x line, or 11.5.3 or later for the 11.x line. Ensure the upgraded pnpm version is used consistently across developer workstations, CI/CD images, build containers, release runners, and base images. Avoid globally installing untrusted packages, especially packages added temporarily for build or troubleshooting tasks. Where possible, prefer project-local devDependencies, pinned versions, lockfiles, and ephemeral build environments over persistent global tool installations. Restrict package installation in automation to approved registries or vetted packages, and review package manifests for suspicious bin keys before allowing global installation. If immediate upgrade is not possible, block or alert on package manifests containing bin entries with keys equal to an empty string, ".", or "..", and avoid global remove/update/add-replacement operations involving untrusted packages until patched.

How to confirm the fix worked

Confirm the active pnpm version with `pnpm --version` in every environment where pnpm is used, including local shells, CI images, containers, and build runners. Versions should report 10.34.2 or later on the 10.x track, or 11.5.3 or later on the 11.x track. Validate that package-manager base images and runner images have been rebuilt after the pnpm upgrade rather than only updated in source configuration. Review global pnpm package inventories for packages with suspicious manifest bin keys. Inspect installed package.json files under global pnpm package locations and project caches for bin object keys equal to `""`, `"."`, or `".."`. A safe validation test can also confirm that pnpm rejects or safely handles packages with these invalid bin names and that global remove/update operations no longer target the global binary directory or its parent.

Typical attack path

1. Attacker creates or modifies an npm package manifest with a malicious bin key such as an empty string, ".", or "..".
2. Attacker gets a developer, administrator, CI job, or build script to install the package globally using a vulnerable pnpm version.
3. The malicious package metadata is stored in the global pnpm installation context.
4. A later global pnpm operation occurs, such as remove, update, or add-based replacement of the package.
5. Vulnerable pnpm re-derives the unsafe bin name from the installed manifest.
6. pnpm constructs a path using the global binary directory and the unsafe bin name.
7. The resulting operation targets the global bin directory or its parent rather than a single expected executable shim.
8. Globally installed command-line tools or related directories are removed or disrupted, causing build or operational failures.

How to detect it

To determine whether this was already exploited, review endpoint, CI/CD, and package-manager telemetry for global pnpm installs of unusual or unapproved packages followed by global pnpm remove, update, or add operations. Key log sources include shell history, CI job logs, build runner logs, endpoint process creation telemetry, file deletion telemetry, package registry/proxy logs, and filesystem snapshots of global pnpm locations. Look for package.json manifests containing bin object keys of an empty string, ".", or "..". Correlate suspicious pnpm commands with deletion or disappearance of global binary directories, broken command shims, failed builds reporting missing globally installed tools, or file deletion events under pnpm global bin locations. If centralized package-registry logs are available, identify tarballs downloaded shortly before the disruption and inspect their package.json manifests. There are no supplied named threat actors or known exploited-in-the-wild campaigns for this CVE, so detection should focus on behavioral evidence, malicious manifest structure, and unexpected global directory deletion rather than actor-specific infrastructure.

• "bin":{".":
• "bin": {".":
• "bin":{"..":
• "bin": {"..":
• "bin":{"":
• "bin": {"":
• pnpm add -g
• pnpm install -g
• pnpm remove -g
• pnpm update -g
• pnpm rm -g
• pnpm uninstall -g
• package.json
• "bin"
• "."
• ".."

What your security team should do

• Prioritize upgrading pnpm to 10.34.2 or later, or 11.5.3 or later, across CI/CD systems, build images, developer toolchains, and automation runners.
• Inventory all places where pnpm is installed separately, including Node.js base images, developer bootstrap scripts, GitHub/GitLab/Bitbucket runners, container images, and release tooling.
• Search package manifests in source repositories, dependency caches, artifact stores, and global pnpm package directories for bin keys equal to an empty string, ".", or "..".
• Restrict global installation of packages from public registries unless the package is approved, pinned, and reviewed.
• Add dependency-security controls that flag suspicious package.json bin definitions before packages are used in build or developer environments.
• Monitor build and endpoint telemetry for unexpected pnpm global remove, update, or add operations followed by missing global tools or directory deletion events.
• If suspicious packages are found, preserve the package tarball, package.json, pnpm logs, shell history, and CI job logs before cleanup.
• Because this issue is not currently listed in KEV and has low EPSS, treat it as a hardening and supply-chain hygiene priority unless global pnpm installs are common in critical build systems, in which case prioritize sooner.