pnpm CVE-2026-82392

Exploitation requires a victim to run pnpm install (UI:R per CVSS) against a project whose pnpm-lock.yaml contains attacker-controlled package path keys with directory traversal sequences such as ../../path/to/target@1.0.0 or scoped equivalents like @scope/../../../target. The file-write primitive triggers in all affected versions regardless of script configuration - the PR diff explicitly states the traversal write occurs even with --ignore-scripts, meaning this flag does not serve as a reliable compensating control. Escalation to arbitrary code execution as the victim user additionally requires that the pnpm configuration have dangerouslyAllowAllBuilds=true or a matching allowBuilds entry that permits the traversal-escaped package to run lifecycle scripts; this is a non-default but operationally common setting in monorepos that build native addons. The attacker does not require any privileges on the victim system and does not need access to a legitimate npm registry - only the ability to place a crafted lockfile in a location the victim will run pnpm install against (shared repository, fork, pull request branch, or direct file delivery).

The CVSS 3.1 score of 7.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:L) accurately reflects the core risk profile: high-integrity arbitrary file write requiring only that a victim run pnpm install against a crafted lockfile, with no authentication required of the attacker. The AV:N rating is well-grounded because the malicious lockfile can be distributed through a poisoned source repository, shared project workspace, or social engineering, with no need for the attacker to have any foothold on the victim's machine. EPSS data is absent from the provided input, so exploitation probability cannot be quantified; KEV status is not listed, and no public exploit has been identified. Real-world risk is meaningfully tiered by deployment pattern: any JavaScript development shop or CI/CD pipeline running automated pnpm install against shared or third-party repositories faces the file-write primitive regardless of script settings, and even a mid-sized municipal IT team in olsztyn relying on pnpm monorepos for internal tooling would be exposed. The secondary code-execution impact is conditional on dangerouslyAllowAllBuilds or allowBuilds being configured, which is non-default but commonly enabled in monorepo environments that build native modules. The CVSS I:H rating is fully justified; the S:U scope-unchanged designation is consistent with the exploitation requiring the victim user context rather than escaping to a privileged scope independently.

An attacker contributes a crafted pnpm-lock.yaml to a shared project repository, embedding a packages key such as ../../etc/cron.d/backdoor@1.0.0 paired with a malicious package payload containing a postinstall script. A developer or CI runner clones the repository and executes pnpm install; pnpm parses the unvalidated package name and writes the extracted package contents to /etc/cron.d/backdoor. If the project's pnpm configuration includes dangerouslyAllowAllBuilds=true, the postinstall script runs immediately with the invoking user's privileges, completing remote code execution without any further interaction.