CVE-2026-55697 in pnpm
Summary
by MITRE • 06/25/2026
pnpm is a package manager. Prior to 10.34.2 and 11.5.3, pnpm can install configDependencies declared in pnpm-workspace.yaml before command dispatch. Before the patch, a repository could declare pacquet or @pnpm/pacquet as a config dependency and pnpm treated that repository-controlled dependency as an install-engine opt-in. During install, pnpm resolved a platform-specific @pacquet/-/pacquet binary from node_modules/.pnpm-config/ and spawned it as the developer or CI user. This vulnerability is fixed in 10.34.2 and 11.5.3.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 06/25/2026
This vulnerability in pnpm represents a critical supply chain attack vector that allows malicious actors to execute arbitrary code during package installation processes. The flaw existed in versions prior to 10.34.2 and 11.5.3 where the package manager would process configDependencies declared in pnpm-workspace.yaml files before dispatching commands. This design oversight created an opportunity for attackers to manipulate the installation flow by declaring specific dependencies including pacquet or @pnpm/pacquet as configuration dependencies. The vulnerability stems from improper trust boundaries within the package manager's dependency resolution mechanism, allowing repository-controlled dependencies to be treated as install-engine opt-ins rather than standard configuration elements.
The technical implementation of this vulnerability involves the manipulation of the pnpm-workspace.yaml configuration file to include malicious package declarations that would then be processed through the normal installation pipeline. When pnpm encountered these configDependencies, it would resolve platform-specific binary distributions from the node_modules/.pnpm-config/ directory structure and subsequently spawn these binaries as the executing user context, whether developer or CI environment. This execution model creates a direct code execution pathway where arbitrary commands could be executed with the privileges of the user running pnpm, effectively bypassing normal security boundaries that should separate configuration processing from actual installation execution.
The operational impact of this vulnerability extends beyond simple privilege escalation to encompass complete system compromise potential within environments where pnpm is used for package management. Attackers could leverage this flaw in continuous integration pipelines, developer workstations, or any environment where pnpm processes untrusted workspace configurations. The vulnerability affects both local development environments and automated build systems, making it particularly dangerous for organizations that rely on pnpm for their dependency management workflows. According to CWE classification, this maps to CWE-434 Unrestricted Upload of File with Dangerous Type, as the system accepts potentially malicious package declarations without proper validation or sandboxing.
From an attacker perspective, this vulnerability aligns with ATT&CK technique T1505.003 Application Deployment Software, where adversaries compromise legitimate software update mechanisms to gain persistent access to systems. The exploitation process requires minimal privileges and can be automated through repository manipulation, making it particularly attractive for supply chain attacks targeting organizations using pnpm. The fix implemented in versions 10.34.2 and 11.5.3 addresses the core issue by establishing proper isolation between configuration dependency resolution and installation execution phases. This mitigation prevents configDependencies from being elevated to install-engine status while maintaining backward compatibility for legitimate use cases.
Organizations should immediately upgrade to pnpm versions 10.34.2 or 11.5.3 to address this vulnerability, as the patch enforces stricter validation of dependency declarations and separates the configuration processing phase from the installation execution phase. Security teams should also conduct audits of existing pnpm-workspace.yaml files to ensure no malicious dependencies have been introduced into their repositories. The vulnerability demonstrates the importance of proper input validation and privilege separation in package managers, particularly when dealing with repository-controlled configuration files that may be modified by untrusted parties. This incident underscores the need for comprehensive security testing of dependency resolution mechanisms and highlights the critical nature of maintaining secure software supply chain practices within modern development environments.