pnpm is a package manager

pnpm's patch application pipeline (@pnpm/patch-package) parses .patch files referenced from patchedDependencies in package.json and applies them during pnpm install. The parser pulls target paths straight out of diff --git a/... b/... headers with no normalization, so an attacker who can land a crafted .patch file in a repo gets arbitrary file write/delete as the user running install — overwriting ~/.ssh/authorized_keys, ~/.bashrc, CI runner config, or anything else under that UID. Affected: pnpm < 10.34.0 and 11.0.0 ≤ pnpm < 11.4.0. Fixed in 10.34.0 and 11.4.0 (GHSA-rxhj-4m44-96r4).

Vendor pegged this HIGH (7.3) with PR:L/UI:R, which is fair on paper but slightly overstated for a typical enterprise dev fleet. The vuln requires an attacker to land a malicious patch file *and* a maintainer to run pnpm install against the poisoned branch — UI:R is doing real work here. The CVSS does not capture that the realistic victim population is open-source repos that auto-install untrusted PR branches in CI, not closed corporate monorepos where every patch file goes through code review. We land at MEDIUM for the enterprise patching audience.

Why this verdict

• Attacker-position prerequisite: requires the attacker to either be a PR contributor or already own a branch the victim checks out — this is post-social-engineering or post-supply-chain access, not unauthenticated remote.
• User interaction gate: UI:R is real — the victim must explicitly run pnpm install against the poisoned branch. CI that doesn't auto-install untrusted PR branches is unaffected.
• Blast radius cap: writes execute as the install user. No SYSTEM/root escalation, no kernel impact, no fleet-wide pivot from a single host unless secrets harvested from ~/.npmrc chain into the registry.
• Role multiplier — developer workstation: chain succeeds and yields workstation-local code exec on next shell. Blast radius: one developer host, recoverable.
• Role multiplier — shared CI runner (self-hosted Jenkins, GitHub Actions self-hosted): chain succeeds and can write the runner workspace / steal long-lived registry tokens. Blast radius: the build pipeline. This is the worst plausible outcome and pushes us above LOW but does not reach the canonical supply-chain-registry floor — pnpm itself is not the registry, just the consumer.
• Friction stack: narrow patchedDependencies user base + needs untrusted PR ingestion + UI:R + EPSS 0.0025 + no KEV + no observed exploitation = downgrade from vendor HIGH to MEDIUM.

Why not higher?

Not HIGH because the prerequisite chain (attacker-contributed patch file + victim-initiated install + writable HOME) is unmet in the typical closed-source enterprise repo. There is no unauthenticated remote vector, no automatic exploitation, EPSS is 0.0025, and KEV has not picked it up. A floor to HIGH would require canonical deployment in a high-value role — pnpm is a dev-time tool, not an identity/PKI/hypervisor component.

Why not lower?

Not LOW because the impact when the chain DOES succeed is real arbitrary file write at user UID — including ~/.ssh/authorized_keys, ~/.npmrc (npm token theft → potential downstream registry pivot), and CI runner workspace files. Open-source maintainers and shops that auto-install untrusted PR branches in CI face a genuine, non-trivial risk that warrants tracked remediation.

1. Pin pnpm to 10.34.0 / 11.4.0 or later via Corepack/packageManager field — Single-line fix — set "packageManager": "[email protected]" (or 11.4.0+) in every package.json and enable Corepack on CI. With MEDIUM verdict and no mitigation SLA, fold this into the next sprint and complete remediation within the noisgate 365-day window — but if you accept untrusted PRs anywhere, pull it forward to 30 days.
2. Block CI auto-install on untrusted PR branches — Gate pnpm install behind pull_request_target review approvals (GitHub Actions) or equivalent in GitLab/Jenkins. The vuln is dead if untrusted code never runs pnpm install until a human approves. Implement within 2 weeks.
3. Audit repos for patchedDependencies and lock down review on .patch file changes — Add CODEOWNERS rules requiring senior maintainer review for any *.patch file diff and any patchedDependencies modification. Most repos don't use this feature — your search will be short.
4. Run CI under rootless/unprivileged ephemeral runners — Containerized ephemeral runners with read-only HOME and no long-lived secrets mounted neuter the traversal write target. Standard supply-chain hygiene.
5. Rotate any npm registry tokens potentially exposed to a vulnerable pnpm run — If you cannot quickly determine which pre-10.34.0 installs ran against PR branches, rotate npm publishing tokens proactively. Cheap insurance.

Run on each developer workstation and CI runner that uses pnpm. Invoke as bash check-cve-2026-50015.sh. No special privileges required — just executes pnpm --version and corepack info. Also scans the current repo for patchedDependencies, which scopes the exposure.

#!/usr/bin/env bash
# noisgate verification — CVE-2026-50015 (pnpm patch-file path traversal)
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u

VERDICT="UNKNOWN"
REASON=""

if ! command -v pnpm >/dev/null 2>&1; then
  echo "PATCHED (no pnpm installed)"
  exit 0
fi

RAW=$(pnpm --version 2>/dev/null | tr -d '[:space:]')
if [[ -z "$RAW" ]]; then
  echo "UNKNOWN (could not read pnpm --version)"
  exit 2
fi

# Strip prerelease suffix
VER="${RAW%%-*}"
IFS='.' read -r MAJ MIN PATCH <<<"$VER"
MAJ=${MAJ:-0}; MIN=${MIN:-0}; PATCH=${PATCH:-0}

is_vulnerable() {
  # < 10.34.0 -> vulnerable
  if (( MAJ < 10 )); then return 0; fi
  if (( MAJ == 10 )); then
    if (( MIN < 34 )); then return 0; fi
    return 1
  fi
  # 11.x: vulnerable when < 11.4.0
  if (( MAJ == 11 )); then
    if (( MIN < 4 )); then return 0; fi
    return 1
  fi
  # 12+ assumed patched
  return 1
}

if is_vulnerable; then
  VERDICT="VULNERABLE"
  REASON="pnpm $RAW is in affected range (<10.34.0 or 11.0.0 \u2264 v < 11.4.0)"
else
  VERDICT="PATCHED"
  REASON="pnpm $RAW is at or above fixed release"
fi

# Bonus: scope check — does current dir use patchedDependencies?
if [[ -f package.json ]]; then
  if grep -q '"patchedDependencies"' package.json 2>/dev/null; then
    REASON="$REASON | package.json declares patchedDependencies — high relevance"
  fi
fi

echo "$VERDICT: $REASON"
case "$VERDICT" in
  VULNERABLE) exit 1 ;;
  PATCHED)    exit 0 ;;
  *)          exit 2 ;;
esac

Sources

1. GitHub Security Advisory GHSA-rxhj-4m44-96r4
2. DailyCVE — CVE-2026-50015 writeup
3. pnpm release notes (10.34.0)
4. pnpm release notes (11.4.0)
5. pnpm patchedDependencies docs
6. TheHackerWire — pnpm vulnerabilities tracker
7. CWE-22: Path Traversal
8. FIRST EPSS