pnpm: The Path to Hell is Paved with Scoped Bins

We all love pnpm. It is fast, efficient, and saves our disk space by using hard links. It is the darling of the Node.js ecosystem. But like any complex piece of software that handles untrusted input (read: package.json files from the internet), it makes assumptions. One of those assumptions is that package manifests play by the rules.

When you install a package that comes with a command-line tool (like eslint or prettier), pnpm creates a 'shim'—a small executable script—inside node_modules/.bin. This allows you to run eslint directly in your scripts without typing the full path.

But what determines the name of that shim? The bin field in the package's manifest. And what happens if that name contains characters it shouldn't, like ../? Usually, a package manager should slap that down immediately. But in CVE-2026-23890, pnpm had a specific blind spot: it assumed that if a name looked like a 'scoped' package (starting with @), it was special. And by special, they meant 'exempt from security checks'.

The vulnerability lies in pkg-manager/package-bins/src/index.ts. The developers implemented a validation filter to ensure binary names were safe. They wanted to block weird characters to prevent exactly this kind of nonsense. However, they carved out an exception.

Take a look at the logic. They explicitly allowed any command name starting with @ to bypass the URL-safety check. The intention was likely to support namespacing logic or handle scoped internal mappings, but the implementation was catastrophic.

Once the validation was skipped, the code proceeded to 'normalize' the name. For scoped packages, the convention is @scope/pkg. The normalizer simply looked for the first slash / and took everything after it. Do you see the problem yet? If I name my binary @hack/../../evil, the validator sees the @, waves it through, and then the normalizer strips @hack/, leaving ../../evil. That string is then joined to the target directory path, and boom—you have escaped the jail.

Let's dissect the smoking gun. This is the vulnerable code in commandsFromBin inside pkg-manager/package-bins/src/index.ts:

// The Vulnerable Logic
.filter((commandName) =>
  encodeURIComponent(commandName) === commandName ||
  commandName === '' ||
  commandName[0] === '@'  // <--- THE BUG. Absolute trust in '@'.
)

This filter is saying: "If it is URL-safe, OR it is empty, OR it starts with @, it is fine." The developer assumed @ implies a valid scope format like @org/tool. They did not account for @org/../../tool.

After this filter, the code normalized the name:

function normalizeBinName (name: string): string {
  // If it starts with @, take everything after the first slash.
  return name[0] === '@' ? name.slice(name.indexOf('/') + 1) : name
}

Because the validation happened before normalization, the traversal payload survived. The fix, introduced in commit 8afbb159, flips the script: normalize first, then validate the result.

// The Fix (simplified)
const binName = commandName[0] === '@'
  ? commandName.slice(commandName.indexOf('/') + 1)
  : commandName
 
// Check strict equality to URL-encoded version (bans slashes and dots)
if (binName !== encodeURIComponent(binName)) {
  continue
}

By moving the check after the normalization, ../../evil is correctly flagged as invalid because it contains characters that would be escaped by encodeURIComponent.

To exploit this, we don't need complex memory corruption. We just need to publish a package to the npm registry (or a local registry) with a malicious package.json. Let's assume we want to overwrite the user's .npmrc file to steal their authentication tokens during the next install.

Here is the attack manifest:

{
  "name": "pwn-pm",
  "version": "1.0.0",
  "bin": {
    "@fake/../../.npmrc": "./payload.js"
  }
}

When a victim runs pnpm add pwn-pm, the following happens:

1. pnpm downloads the package.
2. It parses the bin field.
3. It sees @fake/../../.npmrc. It checks: does it start with @? Yes. Validation passed.
4. It normalizes it: removes @fake/, leaving ../../.npmrc.
5. It constructs the path: node_modules/.bin + ../../.npmrc.
6. It resolves to <ProjectRoot>/.npmrc.
7. It writes a shim script pointing to payload.js into .npmrc.

Now, the user's configuration file is garbage, or worse, if we targeted a script they execute frequently (like a git hook or a local utility script), we have achieved Code Execution.

The remediation is simple: stop trusting prefixes. The pnpm team patched this in version 10.28.1. They removed the explicit bypass for @ characters and reorganized the pipeline to normalize the name before validating it.

Furthermore, they added logic to verify that the target file actually resides inside the package directory using a isSubdir check. This prevents the link from pointing to arbitrary system files even if the name validation fails.

As a user, your job is easy: Upgrade. If you are on an older version of pnpm, you are relying on the goodwill of every package maintainer in your dependency tree not to overwrite your files.