pnpm Hit by 2 Serious Flaws Letting Malicious Code Hijack Developer Machines (CVE-2026-55698)

Two high-severity flaws have been found in pnpm, a widely used tool for managing software packages. With either one, simply pulling in a malicious code component or project can let an attacker take over a developer's machine and run code of their choosing.

Both score 8.8 out of 10 on the CVSS severity scale, and both were added to the U.S. National Vulnerability Database (NVD) on June 25, 2026, as CVE-2026-55698 and CVE-2026-50016. A CVE is the globally shared tracking number assigned to a vulnerability.

Fixed versions are already out. If you use pnpm, update soon: 10.34.2 or later on the 10.x line, 11.5.3 or later on the 11.x line. The troubling part is that the safeguard developers have long relied on does not stop these attacks. Here is what is going on.

What pnpm is

pnpm is a tool that gathers and installs external code components (packages) for JavaScript, the language used most for building websites and apps. It is a sibling of npm and yarn, and its low disk usage and speed have made it increasingly popular at large companies.

Modern software is assembled more from other people's components than from code you write yourself. A single app routinely depends on hundreds or thousands of components, and pnpm is the gateway that fetches them all. So when the gateway itself has a flaw, every project and package a developer pulls in becomes a way to attack the machine at once. Abusing this flow of components is known as a supply chain attack.

The two flaws at a glance

Here are the two entries added to the NVD. Neither needs special privileges, and both work over the network. They do require the victim to pull in a malicious package or project, but that is exactly what developers do every day.

To close both, you need 10.34.2 or later on the 10.x line or 11.5.3 or later on 11.x. Note that pnpm shipped several supply-chain fixes in June, of which these two are part. As explained below, moving to the latest release is the safer bet.

Who would exploit this, and why

The people who can use these flaws are attackers who can plant a trap in a public package registry or in source code anyone can browse. Publishing a single component, or putting up one fake or tampered copy of a popular project, is enough to set the trap. No advanced skills or insider access are required.

What they are after is quietly running their own code on the machine of any developer who pulls that component in, or on the build server (CI) that compiles the project automatically. Once inside, they can steal source code and credentials, or slip a back door into a product before it ships, and the damage spreads quickly downstream.

The reach goes beyond the individual developer. Apps and services built from a poisoned environment carry the danger on to the ordinary users who run them. Widely used components have been hijacked and have hit the companies that pulled them in more than once over the past year, from the fake "axios" package incident to "GlassWorm," which hides invisible code. What makes this case weightier is that the hole is in the gateway tool itself.

CVE-2026-55698: pnpm itself gets swapped for a fake

This is the eerier of the two. It was reported by pnpm's own author, Zoltan Kochan (zkochan), and published as an official advisory.

It stems from a convenience feature called automatic version switching. A project can declare "run this project with this version of pnpm," and even if a developer is on an older pnpm, it fetches and switches to the required version automatically, so a whole team works in the same environment.

The problem is that the basis for that switch was read from the project's lockfile (pnpm-lock.yaml, the ledger that records the exact versions of the components in use). If an attacker tampers with the "bootstrap metadata" inside that ledger, pnpm trusts the pnpm binary the ledger points to without verifying it properly. As a result, what you run thinking it is the real pnpm is in fact a fake pnpm the attacker swapped in. The moment a user casually runs a pnpm command inside a malicious project, the attacker's code starts executing.

The fix verifies that the binary fetched during switching carries a valid signature and refuses to run it if the signature does not match. Affected versions are those before 10.34.2 and from 11.0.0 up to but not including 11.5.3.

CVE-2026-50016: a malicious package hijacks git's hooks

The other flaw needs only the install of a single malicious component. It was reported by aszx87410, a researcher known for web security work, and is likewise published as an official advisory.

Here is how it works. A package can declare another package under an "alias." An attacker stuffs that alias with a string full of climb-up sequences (../), such as @x/../../../../../.git/hooks. pnpm uses that alias directly as the name of the folder where the component should go, so it escapes the intended folder and can rewrite any location inside the project. This is a classic trick known as path traversal (crossing directory boundaries).

The spot the attacker rewrites is git's "hooks." A hook is a small program that runs automatically on actions like commit or push. Replace that with a shortcut (symlink) to attacker-controlled content, and the next time the developer runs a git operation, the attacker's code executes. Affected versions are those before 10.34.0 and from 11.0.0 up to but not including 11.4.0.

"I disabled scripts, so I'm safe" no longer holds

npm-family tools have long faced attacks where a malicious component plants a program that runs automatically at install time (a lifecycle script) and executes code on the spot. The common defense is the --ignore-scripts setting that stops that auto-run. pnpm went further, disabling auto-run by default in version 11, and npm itself is moving to off-by-default as well.

Yet both of these flaws bypass that "stop the scripts" defense. The official write-up for CVE-2026-50016 states explicitly that the attack works even with the auto-run-blocking setting (--ignore-scripts) on, because rewriting files across folder boundaries and swapping the tool binary happen through a different path than script auto-run. "I have the safeguard on, so I'm fine" simply does not apply here, which is why a settings review is not enough and the binary itself must be updated.

Are you affected, and what to do

First, check your pnpm version. Running pnpm --version in a terminal shows it. Use the table below to see whether your version falls in the affected range.

How you update depends on your setup. Reinstall with npm install -g pnpm@latest, or if you manage it through Node.js's Corepack, use corepack prepare pnpm@latest --activate. If you pin the project's pnpm version via the packageManager field in package.json, raise that value to match.

Keep in mind that these two are only part of a wave of security fixes pnpm shipped in June. The official advisory list shows other fixes lined up, including more cross-boundary file rewrites and install-process weaknesses. Some were addressed in still later versions (10.34.4 and 11.7.0 onward), so rather than stopping at these two, move to the latest release if you can. To check whether the components your project pulls in are clean, you can also use a scanner that flags vulnerabilities from a pasted dependency file.

Worth keeping straight

The gateway that gathers your components is the target

Both flaws build on the everyday act of pulling in a malicious package or project, and because they slip past the auto-run defense that used to work, reviewing settings alone will not stop them. The fix comes down to updating the binary: 10.34.2 or later on 10.x, 11.5.3 or later on 11.x, ideally the newest release. That alone closes both.

In an era where inspecting every single component by hand is no longer realistic, whether the "gateway" tool that fetches them all is safe ties directly to the safety of the whole shop. pnpm aside, package managers including npm and yarn will remain the first place attackers look. Keeping the tool in your hands up to date is the surest defense.

Sources

• ▸ NVD - CVE-2026-55698 detail
• ▸ NVD - CVE-2026-50016 detail
• ▸ pnpm official advisory - GHSA-w466-c33r-3gjp (CVE-2026-55698)
• ▸ pnpm official advisory - GHSA-hwx4-2j3j-g496 (CVE-2026-50016)
• ▸ pnpm - Published security advisories
• ▸ pnpm - Mitigating supply chain attacks
• ▸ Socket - pnpm 11 Adds New Supply Chain Protection Defaults