pnpm CVE-2026-82393: a malicious tarball writes outside node_modules

Today’s CVE-2026-82393 describes a pnpm flaw that allowed a malicious tarball dependency to write and overwrite files outside node_modules. The path originated in the package’s package.json name rather than the archive filename. A crafted scoped name passed validation and reached raw path.join operations. Installation could consequently replace a shell startup file, Git hook or another dependency’s code, leading to execution in a developer or CI runner context.

The issue occurred even with pnpm install --ignore-scripts. That is the advisory’s central lesson: disabling lifecycle scripts removes one risk class, but a package manager still extracts and moves files. When untrusted metadata controls the destination, no postinstall hook is necessary to compromise the system.

Affected releases are older than 10.34.5 and the 11.x line from 11.0.0 through 11.10.x. Fixes are in 10.34.5 and 11.11.0. pnpm published its advisory on 2 August, while NVD registered the CVE at 22:17 UTC on 31 August—1 September in Warsaw. Today’s event is therefore the record entering vulnerability-management feeds, not the initial creation of the patch.

How a package name became a write path

An npm manifest contains a name field. A legitimate scoped package uses the form @scope/package. pnpm rejected slash characters in unscoped names, but the same gate did not close the possibility after a scope prefix. Parent-directory components could therefore survive package resolution.

The isolated linker later built an import target from the resolved name. The advisory identifies three code paths: resolvePeers.ts, the main dependency resolver and lockfileToDepGraph.ts. They joined the modules directory with the name directly. If the latter is not a plain path segment, normalisation can move the result outside the virtual store and project.

Safe path joining requires more than a trusted first argument. Code must treat the second part as hostile, canonicalise the result and prove that it remains under the allowed root. pnpm already had a safeJoinModulesDir helper in other paths, but the vulnerable sinks did not apply equivalent containment.

A tarball controller could choose not only the directory but also file names and contents. Creating a file violates integrity. Overwriting one raises the impact because it can capture a mechanism the victim already expects to run.

Why —ignore-scripts did not stop it

--ignore-scripts prevents lifecycle entries such as preinstall, install and postinstall from running. It is a useful CI and analysis control. It does not make installation read-only. pnpm must retrieve the artefact, inspect metadata, extract files, construct its store and link dependencies.

CVE-2026-82393 is in that phase. The malicious package did not ask pnpm to execute an explicit hook. It caused a legitimate copy operation to use an illegitimate destination. A .git/hooks/pre-commit target may run during a later commit; a shell profile runs in a new session; overwritten dependency code executes during a subsequent test, build or application start.

The delay complicates investigation. Installation logs may contain no conventional postinstall, while execution appears in another process and at another time. A team may blame Git, the shell or a test runner even though package installation introduced the change.

The realistic threat model

The CVSS 3.1 score is 7.5 (High), with user interaction and high attack complexity. A victim must install a dependency from a controlled tarball or process a hostile manifest or lockfile change pointing the resolver at it. This is not a direct HTTP attack on every application built with pnpm.

Plausible entry points include:

a pull request modifying package.json, workspace configuration or the lockfile;
a URL, private-registry or build-artefact dependency;
a compromised maintainer publishing modified metadata;
an automated dependency-update proposal merged without metadata review;
a pipeline installing packages with broad access to the workspace and home directory.

A lockfile provides reproducibility but is not inherently trusted. It is an instruction set for the package manager, containing locations, identifiers and the dependency graph. Review, commit provenance and change policy matter alongside tarball integrity hashes.

Who is affected and how to verify versions

Check pnpm used on developer machines, development images, CI runners and through Corepack. The packageManager field may pin a release different from the global pnpm binary. Container layers and tool caches can preserve an older build after a declaration changes.

Versions safe from this CVE are 10.34.5 or later 10.x and 11.11.0 or later 11.x. Organisations on an earlier major line should review vendor support and migrate to a maintained release rather than interpret absence from the listed range as assurance.

After upgrading, discard only caches whose provenance cannot be established, following the organisation’s change process. A cache does not trigger the flaw by itself, but rebuilding from an approved lockfile and verified artefacts provides stronger evidence than reusing unknown state from the exposure period.

Priority defensive actions

Pin and deploy pnpm 10.34.5, 11.11.0 or a later compatible release to every runner.
Review manifest and lockfile changes since the last known-good build, focusing on tarball or URL dependencies and unusual scoped names.
Build in an ephemeral container without write access to the host home, Docker socket or production credentials.
Retain --ignore-scripts where appropriate, but treat it as one layer rather than a sandbox.
Restrict runner egress to approved registries and verify downloaded artefact integrity.
Promote a signed output between stages instead of reinstalling dependencies in production.

In a monorepo, perform one controlled build after upgrading and compare files changed beyond working directories. EDR or auditd can reveal pnpm or Node writes to .git/hooks, shell profiles, neighbouring repositories or system temporary areas.

Detection and response

Search CI history for URL dependencies and scoped-name changes. In process telemetry, find writes made by Node or pnpm outside the workspace and configured store. Compare hashes of Git hooks, shell startup files, tool wrappers and installed package code with a trusted baseline.

If a suspect build could access secrets, account for later execution of overwritten code. Recreate the runner from a clean image, revoke tokens available to the job and inspect outputs produced after the event. Pipeline compromise can propagate through images, packages and release files even when the original runner was ephemeral.

A safe regression test

Do not test against a developer’s real home. In an isolated temporary directory, create a workspace and a neighbouring canary file, then use a harmless local tarball carrying an invalid package name. A corrected release should reject it before any write, leaving the canary unchanged. Run the case with --ignore-scripts and each linker used by the organisation.

Verify the effect, not only the exit code. An installation that fails after already changing a file is not fail-safe. Filesystem monitoring should confirm that there was no attempted write outside the designated root.

Source facts and Breachroad conclusions

Affected ranges, manifest-name traversal, unsafe joins, behaviour under --ignore-scripts and fixed versions come from the pnpm advisory, commits and NVD. The CI threat model, hunting plan and isolation guidance are Breachroad’s defensive conclusions. The sources do not report active exploitation in named organisations.

Primary sources

A secure supply chain requires understanding what an installer does before scripts run. Our cybersecurity training teaches teams to analyse CI/CD boundaries and artefact trust. A controlled web and API penetration test can be extended with a review of build workflows, runners and release paths.