CVE-2026-55487: pnpm Package Source Normalization Bypass (v10.34.2, v11.5.3)

Technical summary

The vulnerability resides in pnpm's peer-suffix normalization logic. This function is responsible for transforming various locator formats (git repositories, URLs, tarballs, file paths) into a canonical form for comparison against approval lists or integrity checks. Prior to the fix, the normalizer incorrectly removed parenthesized content from opaque locators—those that don't follow standard URL syntax. An attacker can craft a malicious package source whose normalized form collides with an already-approved source, bypassing allowlist enforcement. The CWEs involved (CWE-346: Origin Validation Error, CWE-693: Protection Mechanism Failure, CWE-829: Inclusion of Functionality from Untrusted Control Sphere) reflect issues around source verification and supply-chain integrity.

Business impact

Successful exploitation could result in installation of attacker-controlled dependencies into projects using affected pnpm versions. This could lead to code injection, credential theft, or lateral movement within development environments or CI/CD pipelines. Organizations relying on pnpm for dependency management—particularly those with strict approval policies for package sources—face the risk that malicious packages bypass their controls. The impact scales with the breadth of use: teams managing many projects or monorepos could see widespread compromise if an attacker exploits this to inject persistent backdoors into shared dependencies.

Affected systems

pnpm versions prior to 10.34.2 (for the 10.x series) and prior to 11.5.3 (for the 11.x series) are affected. Any project using these versions to install or manage dependencies is at risk, particularly those that rely on git, tarball, or file-based locators for dependencies. Organizations using pnpm in automated build and deployment workflows should prioritize assessment of their current versions.

Exploitability

The vulnerability has a CVSS score of 7.5 (HIGH) with a network-accessible attack vector, but requires user interaction (UI:R) to trigger—typically someone running a package install or update command. The attack complexity is rated as high (AC:H), suggesting the attacker must craft a specific collision between their malicious locator and an approved one. While not trivial, this is achievable with knowledge of the normalization algorithm and target approval policies. The vulnerability is not yet listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, but the attack surface spans any development environment or CI/CD pipeline using pnpm.

Remediation

Upgrade to pnpm 10.34.2 or later for the 10.x branch, or to 11.5.3 or later for the 11.x branch. Review any pinned or locked dependency versions in your projects and ensure updates are applied across all development machines, build servers, and deployment pipelines. After patching, consider auditing installed dependencies to confirm no malicious packages were introduced during the vulnerability window.

Patch guidance

Verify your current pnpm version using 'pnpm --version'. If you are on version 10.x, upgrade to 10.34.2 or higher. If you are on version 11.x, upgrade to 11.5.3 or higher. Check your package management configuration (pnpm-workspace.yaml, .npmrc, or package.json pnpm field) to ensure no hardcoded version constraints prevent automatic updates. Test upgrades in a non-production environment first, particularly if you have custom package resolution logic or private registry configurations. Monitor release notes for any breaking changes in the patch versions.

Detection guidance

Audit your pnpm version across all machines, containers, and CI/CD configurations to identify which systems remain vulnerable. Review package-lock.yaml (or pnpm-lock.yaml) files for any suspicious or unexpected source URLs, particularly those with unusual parenthetical content or obfuscated paths. Monitor installation logs for warnings or errors related to source verification. If you maintain internal package approvals or allowlists, cross-reference them against recent installations to detect any unauthorized sources that may have bypassed normalization checks.

Why prioritize this

This vulnerability affects the integrity of the software supply chain and can lead to widespread code injection if exploited. Because it requires user action rather than being remotely exploitable without interaction, and because the KEV program has not yet flagged active exploitation, organizations should treat this as a high-priority but not emergency patch. However, any team using pnpm in automated CI/CD pipelines or managing monorepos should deprioritize this upward, as the potential blast radius is significant.

Risk score, explained

The CVSS 7.5 rating reflects the high confidentiality, integrity, and availability impact (C:H/I:H/A:H) if successful, combined with a network-accessible attack surface. However, the requirement for user interaction (UI:R) and high attack complexity (AC:H) prevent a critical rating. The real-world risk depends on whether attackers have mapped your approval policies and can craft targeted collisions. Organizations with restrictive package source policies or those using pnpm in air-gapped or tightly controlled environments face lower practical risk; those with broad source allowlists or less stringent controls face higher risk.

Frequently asked questions