CVE-2026-55487

What it actually does

pnpm versions before 10.34.2 and 11.5.3 incorrectly normalized dependency locators by stripping parenthesized text not only from peer-dependency suffixes, but also from opaque sources such as git, URL, tarball, and file locators. Because pnpm’s approval decision could be made against the normalized value, two different source strings could collapse to the same normalized identifier. An attacker who can influence a dependency declaration, lockfile, package metadata, or install source may craft a malicious locator that normalizes to an already-approved locator, causing pnpm to treat an unapproved attacker-controlled source as trusted. The practical impact is supply-chain integrity failure: installation or build approval controls can be bypassed, potentially allowing malicious package code or lifecycle scripts to run during dependency installation.

Why it matters to the business

This flaw can undermine dependency approval workflows used to prevent untrusted package code from entering developer workstations, CI/CD pipelines, and build systems. If exploited, an attacker could introduce malicious dependency content that appears to match a previously approved source, potentially leading to credential theft, poisoned builds, compromised artifacts, or downstream software supply-chain exposure. The CVSS score is high, but exploitation requires user interaction or an install/build workflow that processes the crafted dependency. EPSS is currently low and there is no known KEV listing or ransomware association, so remediation should be prioritized for environments that use pnpm with dependency approval controls, consume git/URL/tarball/file-based dependencies, or run installs in privileged CI contexts.

How an attack unfolds

An attacker first identifies a project or package workflow that uses affected pnpm versions and relies on pnpm’s dependency approval behavior. The attacker then creates or supplies a dependency locator using an opaque source type such as git, URL, tarball, or file, with parenthesized content arranged so that pnpm’s vulnerable normalizer strips meaningful parts of the locator. The malicious locator is crafted to normalize to the same value as a legitimate, previously approved source string. When a developer or CI job runs pnpm install or a related command, pnpm compares the normalized locator against the approval state and incorrectly treats the attacker-controlled source as approved. If the dependency includes malicious package contents or lifecycle scripts, that code may execute during install or build, enabling theft of tokens, modification of build outputs, persistence in generated artifacts, or further compromise of the build environment.

How to fix it

Upgrade pnpm to a fixed version: 10.34.2 or later on the 10.x line, or 11.5.3 or later on the 11.x line. Ensure the upgraded pnpm version is enforced consistently across developer workstations, CI images, build containers, and package-manager bootstrap tooling such as Corepack. Regenerate or revalidate lockfiles after upgrade, especially for projects using git, URL, tarball, file, link, or other non-registry dependency sources. Review dependency approval configuration and remove approvals that are overly broad or no longer needed. Where immediate upgrade is not possible, avoid accepting lockfile or dependency-source changes from untrusted contributors, disable or tightly restrict install-time scripts in CI where feasible, require review for non-registry dependency locators, and run package installs in isolated environments with minimal secrets and no write access to release artifacts until validation completes.

How to confirm the fix worked

Confirm that all active environments report pnpm version 10.34.2 or later, or 11.5.3 or later, using `pnpm --version`. Check CI job logs, build images, Dockerfiles, developer tooling configuration, and Corepack pinning to ensure older pnpm versions are not being invoked indirectly. Inspect `package.json`, workspace manifests, and `pnpm-lock.yaml` for git, URL, tarball, file, or other opaque locators containing parentheses, then verify those sources are expected and resolve to trusted locations. Re-run dependency installation from a clean checkout with the fixed pnpm version and compare the resulting lockfile and resolved sources against the expected dependency graph. Validate that install-time scripts are either explicitly approved after review or blocked where not required.

Typical attack path

1. Attacker gains influence over a dependency declaration, transitive package reference, lockfile entry, pull request, or package source used by a pnpm-managed project.
2. Attacker crafts a git, URL, tarball, file, or other opaque locator containing parenthesized text that is significant to the true source but stripped by vulnerable pnpm normalization.
3. The crafted malicious locator normalizes to the same value as a source that has already been approved by the project or install workflow.
4. A developer, automation job, or CI/CD pipeline runs pnpm install, pnpm update, or another pnpm operation using a vulnerable pnpm version before 10.34.2 or 11.5.3.
5. pnpm incorrectly treats the malicious source as approved because the normalized locator collides with the approved locator.
6. The attacker-controlled dependency is fetched and may execute lifecycle scripts or contribute malicious files to the dependency tree or build output.
7. The attacker uses the execution context to steal credentials, alter build artifacts, exfiltrate source code, or establish further access in the software delivery pipeline.

How to detect it

To determine whether this was already exploited, focus on source-control history, dependency manifests, lockfiles, package install logs, and CI/CD execution artifacts. Review commits and pull requests that changed `package.json`, workspace package manifests, or `pnpm-lock.yaml`, especially changes involving git, URL, tarball, file, link, or other non-registry dependency sources with parenthesized text. Compare the exact dependency locators before and after suspicious changes and check whether two distinct locators would become identical if parenthesized substrings were removed. Review pnpm install logs for unexpected package fetches, lifecycle script execution, or dependency sources that do not match approved repositories or registries. In CI, examine job logs and network telemetry for unexpected outbound requests during `pnpm install`, `pnpm update`, or build steps, and inspect whether secrets were present in those jobs. On build hosts, look for unexpected modifications under `node_modules/.pnpm`, unexpected postinstall/preinstall/install scripts, newly created files in workspace directories, and anomalous child processes spawned from package lifecycle scripts. Because no public exploit-specific payload or actor-specific indicators are known from the provided intelligence, detection should be behavior- and artifact-based rather than relying only on fixed IOCs.

• pnpm-lock.yaml
• package.json
• node_modules/.pnpm
• .pnpm-store
• pnpm install
• pnpm update
• pnpm approve-builds
• onlyBuiltDependencies
• ignoredBuiltDependencies
• preinstall
• install
• postinstall
• prepare
• git+
• git+ssh://
• git+https://
• github:
• gitlab:
• bitbucket:
• file:
• link:
• tarball:
• http://
• https://
• \(.*\)

What your security team should do

• Prioritize upgrading pnpm to 10.34.2+ or 11.5.3+ in CI/CD runners, build containers, release pipelines, and developer base images.
• Inventory repositories using pnpm and identify those with git, URL, tarball, file, link, or other non-registry dependency locators, especially where locators contain parentheses.
• Search recent pull requests and lockfile changes for dependency source modifications that could normalize to an approved source under vulnerable pnpm behavior.
• Rebuild critical artifacts from a clean environment using a fixed pnpm version and compare dependency resolution and build outputs where supply-chain integrity is important.
• Restrict secrets available during package installation and lifecycle-script execution in CI, especially package publishing tokens, cloud credentials, and source-control tokens.
• Require security review for changes to `pnpm-lock.yaml`, dependency approval configuration, and non-registry dependency references.
• Monitor for unusual outbound network connections, credential access, or unexpected scripts during pnpm install/build jobs after suspicious dependency changes.