CVE-2026-45321 Mini Shai-Hulud : 170+ paquets npm compromis

Les faits

Le 11 mai 2026 entre 19h20 et 19h26 UTC, un attaquant identifié comme TeamPCP a publié 84 versions malveillantes réparties sur 42 paquets de l'écosystème @tanstack/* sur le registre npm. Cet incident, suivi sous l'identifiant CVE-2026-45321 et noté CVSS 9.6 (Critical), n'était que la pointe émergée d'une campagne plus vaste rapidement baptisée « Mini Shai-Hulud 2.0 » par Aikido, StepSecurity, Wiz, JFrog et Socket. Au total, plus de 170 paquets et 401 versions compromises ont été identifiés en 24 heures, touchant TanStack (router, query, table, form…), la SDK suite de Mistral AI, 65 paquets d'automatisation UiPath, OpenSearch et plusieurs paquets Squawk. Plusieurs paquets compromis dépassent 12 millions de téléchargements hebdomadaires, ce qui fait de cette campagne l'une des attaques supply chain npm les plus impactantes depuis le ver Shai-Hulud original de novembre 2025.

Le vecteur initial est d'une sophistication notable. L'attaquant a exploité une triple chaîne de vulnérabilités sur GitHub Actions : d'abord une mauvaise configuration de type « Pwn Request » via le déclencheur pull_request_target — qui exécute les workflows avec les droits du dépôt cible y compris pour les pull requests issues de forks externes — ; ensuite un empoisonnement du cache GitHub Actions à travers la frontière de confiance fork↔base, permettant de polluer le magasin de dépendances pnpm partagé entre les exécutions ; enfin une extraction d'un jeton OIDC directement depuis la mémoire du processus Runner.Worker via lecture de /proc/<pid>/maps et /proc/<pid>/mem. Avec ce jeton, l'attaquant a publié directement vers npm sans passer par l'étape publish habituelle du workflow, court-circuitant tous les contrôles de chaîne de publication.

La diffusion du malware s'appuie sur une technique de « dependency smuggling » via un commit orphelin. Les paquets compromis déclarent un bloc optionalDependencies pointant vers une URL Git précise qui référence le commit 79ac49eedf774dd4b0cfa308722bc463cfe5885c dans un fork du dépôt TanStack. Lors de l'installation, npm récupère silencieusement cette dépendance optionnelle, exécute son script preinstall et déclenche le payload malveillant. Le commit orphelin n'apparaît dans aucune branche officielle du dépôt et reste invisible aux audits classiques de l'historique git.

Le payload est sophistiqué et conçu pour maximiser le vol de credentials. D'après Aikido, StepSecurity et Socket, le malware énumère plus de 100 chemins de fichiers sur le système hôte, ciblant les fichiers .env, ~/.aws/credentials, ~/.ssh/, ~/.npmrc, ~/.gitconfig, les wallets de cryptomonnaies (Metamask, Phantom, Trust Wallet), les bases de mots de passe (KeePass, 1Password locale), mais aussi les configurations d'outils IA comme ~/.cursor/, ~/.continue/ et ~/.claude/. L'exfiltration s'effectue de manière originale en mélangeant le CDN du protocole Session (réseau anonymisé décentralisé) et l'API GraphQL native de GitHub, ce qui rend la détection par bord de réseau particulièrement délicate.

La caractéristique la plus dangereuse de Mini Shai-Hulud est son aspect « worm » (vermiforme). Le malware n'exfiltre pas seulement les credentials : il énumère ensuite tous les paquets que le mainteneur compromis peut publier, injecte le même payload dans chacun d'eux et republie de manière autonome. Cette propagation auto-réplicante explique la croissance explosive du nombre de paquets compromis dans les 6 premières heures de l'attaque. Le ver dérivé partage ADN et infrastructure avec l'incident Shai-Hulud original de novembre 2025 (UNC5221 / TeamPCP), qui avait précédemment frappé Bitwarden CLI, les paquets SAP CAP et le paquet Lightning AI sur PyPI.

TanStack a publié un postmortem complet dès le 12 mai 2026 expliquant la chronologie précise, les actions de remédiation et le rappel des versions publiées. Les versions malveillantes ont été dépubliées de npm en quelques heures, mais les fichiers de verrouillage (package-lock.json, yarn.lock, pnpm-lock.yaml) générés pendant la fenêtre d'attaque continuent de référencer les hashs malveillants. Toute reconstruction d'un environnement basé sur un lockfile généré entre 19h20 UTC le 11 mai et la dépublication officielle réinstallera silencieusement le malware.

Mistral AI a confirmé séparément la compromission de plusieurs paquets de sa suite SDK et a alerté ses utilisateurs entreprise. UiPath a ouvert une investigation sur ses 65 paquets npm impactés. OpenSearch Project a publié une note urgente recommandant aux utilisateurs ayant tiré des dépendances ces 24 dernières heures de procéder à un audit complet. Aucune donnée chiffrée n'est encore publique sur le nombre d'environnements de développement effectivement compromis, mais GitHub a confirmé révoquer en masse les tokens identifiés comme exfiltrés et déclencher la rotation forcée des secrets concernés.

Côté français, le CERT-FR n'a pas encore publié d'alerte spécifique mais le bulletin d'actualité CERTFR-2026-ACT-021 du 11 mai mentionne la recrudescence d'attaques supply chain ciblant les écosystèmes de paquets ouverts. L'ANSSI rappelle dans ses guides la nécessité absolue de pinner les versions, de vérifier les signatures et d'utiliser des registres internes filtrés. Pour les organisations utilisant TanStack Router, Query ou Table en production — extrêmement courant dans l'écosystème React moderne — la priorité absolue est l'audit immédiat des installations récentes et la rotation de tous les secrets exposés sur les machines de build.

Impact et exposition

L'impact direct concerne tout environnement de développement ou pipeline CI/CD ayant exécuté npm install, yarn install ou pnpm install sur un projet utilisant un paquet compromis pendant la fenêtre d'exposition (11 mai 19h20 UTC jusqu'à la dépublication par paquet, étalée sur 6 à 18 heures). Compte tenu de la popularité de TanStack Router (12 millions de téléchargements hebdomadaires) et de l'utilisation massive de Mistral AI SDK et des outils UiPath, le périmètre d'exposition potentielle se chiffre en dizaines de milliers d'organisations.

L'exposition est aggravée par la nature vermiforme du malware : une seule machine compromise peut suffire à exfiltrer les credentials de publication npm d'un mainteneur, et donc à infecter à son tour d'autres paquets totalement indépendants. La frontière entre « victime » et « propagateur » est volontairement floue. Tout développeur ayant pu pousser une mise à jour vers un paquet npm avec son token volé devient un point de bascule supplémentaire dans la chaîne de propagation.

Les secrets les plus à risque sont par ordre de criticité : les tokens npm avec droits de publication, les tokens GitHub à granularité large, les credentials AWS/GCP/Azure stockés en clair sur des postes développeurs, les clés SSH non protégées par passphrase, les configurations Claude Code et Cursor (~/.claude/, ~/.cursor/) qui contiennent souvent des tokens d'API d'éditeurs IA, et les wallets de cryptomonnaies déchiffrés. Tous ces secrets doivent être considérés comme compromis sur toute machine ayant exécuté un install affecté.

L'exploitation est confirmée par l'observation des paquets eux-mêmes : il ne s'agit pas d'une hypothèse mais d'un fait avéré, documenté en parallèle par Aikido, StepSecurity, Socket, JFrog, Wiz et SafeDep, avec des hashs de paquets, des commits malveillants et des indicateurs de compromission publics.

Recommandations immédiates

• Lister immédiatement les installations npm/yarn/pnpm effectuées depuis le 11 mai 2026 19h20 UTC : tout pipeline CI, machine de build ou poste développeur ayant tiré une dépendance @tanstack/*, @mistralai/*, @uipath/*, @opensearch-project/* ou @squawk/* doit être traité comme potentiellement compromis.
• Révoquer immédiatement les tokens npm, GitHub, GitLab et les Personal Access Tokens éventuellement présents sur les machines concernées. Régénérer les clés SSH, faire tourner les credentials AWS/GCP/Azure et purger les sessions actives.
• Purger les caches CI : GitHub Actions cache, npm/pnpm store, Docker layer cache, caches Nix. Reconstruire les images de build depuis zéro après nettoyage. Supprimer les lockfiles générés pendant la fenêtre d'attaque et régénérer à partir d'un environnement sain.
• Activer le mode --ignore-scripts par défaut sur npm/yarn/pnpm dans les pipelines, et n'autoriser les scripts qu'aux paquets explicitement listés (allowlist). Privilégier l'utilisation d'un registre interne filtrant (Nexus, Artifactory, Verdaccio) avec scan SCA actif.
• Sur GitHub, désactiver pull_request_target sauf nécessité absolue. Si nécessaire, ne jamais checker out le code du fork dans un job pull_request_target. Activer la protection « Require approval for first-time contributors » et « Require approval for outside collaborators ».
• Surveiller le trafic sortant vers les CDN du protocole Session et l'API GraphQL GitHub depuis les machines de build : tout flux GraphQL non lié à un workflow connu doit être considéré comme suspect.
• Audit des configurations IA (~/.claude/, ~/.cursor/, ~/.continue/) sur les postes développeurs et rotation des clés API LLM associées.