CVE-2026-82393

What it actually does

A path-traversal flaw in pnpm allows a crafted scoped package name inside a tarball manifest to bypass slash validation (which applied only to unscoped names). During install, that unvalidated name is joined into filesystem paths used for extraction and graph construction, so archive contents can be written outside node_modules and overwrite arbitrary files. Integrity of the workspace, Git hooks, shell startup files, and already-installed package code can be violated even when lifecycle scripts are disabled (--ignore-scripts). Confidentiality, integrity, and availability of the host and subsequent builds can all be affected once overwritten files are later executed.

Why it matters to the business

Development workstations and CI/CD pipelines that run pnpm install against untrusted or compromised dependencies can have critical files silently replaced, leading to poisoned builds, stolen credentials, supply-chain backdoors, and persistent access on engineer laptops and build agents. The issue is publicly known for about a month, is not listed in CISA KEV, and has no reported in-the-wild exploitation or ransomware use, but the impact of a successful overwrite is high and pnpm is a common install path for JavaScript/TypeScript software delivery. Treat upgrade as a near-term hygiene item for all teams that install packages with pnpm 10.x before 10.34.5 or 11.x before 11.11.0.

How an attack unfolds

An attacker publishes or otherwise supplies a tarball whose package.json uses a scoped name containing path separators that pnpm failed to reject. A developer or CI job then installs that package (directly or as a transitive dependency). pnpm trusts the manifest name, joins it into extraction and lockfile-to-graph paths, and writes attacker-controlled files outside node_modules. Overwritten shell rc files, Git hooks, or package entry points execute later under the victim’s identity, achieving code execution without relying on install scripts. Success requires the victim to install the malicious artifact (user interaction) and some care in packaging, which matches high attack complexity; no named threat actors or campaigns are associated with this issue.

How to fix it

Upgrade pnpm to 10.34.5 or later on the 10.x line, or to 11.11.0 or later on the 11.x line, everywhere install runs (developer machines, Docker images, CI runners, and lockfile-generating jobs). Pin the package manager version in project configuration (for example packageManager in package.json / Corepack) so installs cannot silently use a vulnerable binary. After upgrading, reinstall dependencies in a clean tree, rotate credentials that may have been present on affected hosts, and review Git hooks and shell startup files for unexpected changes. Do not treat --ignore-scripts as a mitigation; it does not stop the overwrite. Avoid installing untrusted tarballs or registry packages until the patched pnpm is in use.

How to confirm the fix worked

Confirm `pnpm --version` is 10.34.5+ or 11.11.0+ on every install path, including CI images and Corepack-managed binaries. Search lockfiles and vendor caches for scoped package names containing extra path separators or `..` segments. After a clean reinstall with a patched pnpm, verify that extracted packages land only under the expected node_modules layout and that Git hooks, shell rc files, and other paths outside node_modules were not modified during install. In CI, fail the build if the pnpm version is below the fixed releases.

Typical attack path

1. Attacker prepares a tarball whose scoped manifest name includes path separators that bypass unscoped-only slash checks
2. Attacker publishes the package to a registry or plants it as a direct/transitive dependency (typosquat, compromised maintainer, or internal mirror)
3. Victim or CI runs pnpm install (scripts may be ignored)
4. pnpm joins the unvalidated name into extraction and dependency-graph paths and writes files outside node_modules
5. Attacker-chosen files overwrite shell startup files, Git hooks, or installed package code
6. Later interactive shells, Git operations, or application startup execute the overwritten content and give the attacker code execution

How to detect it

There is no public exploit activity or named actor reporting for this issue, so detections should focus on artifacts of a successful overwrite during or after pnpm install rather than on a known campaign. Review package-manager and CI logs around `pnpm install` for extraction or link paths that leave node_modules. On developer workstations and build agents, look for file-integrity or audit events that modify shell startup files, Git hooks, or files outside node_modules in the same window as a pnpm install. Diff lockfiles and package manifests for scoped names containing `/` sequences beyond the normal `@scope/name` form or `..` path segments. Compare filesystem snapshots before and after install; unexpected new or replaced files at repo root, user home, or `.git/hooks` are high-signal. Process telemetry showing a later shell, git, or node process loading those overwritten files supports post-exploitation confirmation.

• pnpm install
• pnpm-lock.yaml
• package.json
• node_modules
• --ignore-scripts
• @*/..
• ../
• .git/hooks
• pre-commit
• post-commit
• .bashrc
• .zshrc
• .profile
• .git/hooks/pre-commit
• .git/hooks/post-checkout

What your security team should do

• Inventory all repos, images, and CI jobs that invoke pnpm and enforce 10.34.5+ or 11.11.0+ immediately
• Pin the package-manager version (Corepack/packageManager) so vulnerable pnpm cannot be reintroduced
• Treat --ignore-scripts as insufficient; do not delay upgrades on that basis
• Hunt lockfiles and recent installs for scoped names with path separators or parent-directory segments
• After patching, inspect Git hooks, shell startup files, and unexpected writes outside node_modules on hosts that installed packages with vulnerable pnpm
• Block or quarantine untrusted registries and tarball installs until patched pnpm is deployed
• Rotate developer and CI credentials if overwrite of startup files or hooks cannot be ruled out