Mini Shai-Hulud : le ver qui a compromis TanStack et 169 paquets npm — 518 millions de telechargements, CVE-2026-45321, et ce que chaque developpeur open source doit verifier maintenant

Le 11 mai 2026, a 19:20 UTC, l ecosysteme npm a subi ce qui restera probablement comme l attaque supply chain la plus sophistiquee de son histoire. En six minutes — de 19:20 a 19:26 UTC — le groupe TeamPCP a publie 84 versions malveillantes a travers 42 paquets @tanstack/*, affectant des bibliotheques utilisees par des millions de developpeurs dans le monde. @tanstack/react-router a lui seul cumule 12,7 millions de telechargements hebdomadaires. L attaque, baptisee Mini Shai-Hulud en reference au ver des sables de Dune, n a pas exploite une faille dans le code de TanStack. Elle a exploite une faille dans la facon dont TanStack construit et publie son code — via GitHub Actions.

Ce qui rend cette attaque veritablement terrifiante, c est que les paquets compromis ont ete publies en utilisant le pipeline de release legitime de TanStack et son identite OIDC de confiance. Aucun mot de passe n a ete vole. Aucun token n a ete divulgue. L attaquant a simplement fait en sorte que l infrastructure de confiance de TanStack travaille pour lui. Pour npm, pour les registries, pour les outils de verification — ces paquets etaient authentiquement signes par TanStack. C est la difference fondamentale avec les attaques de typosquatting ou les paquets malveillants classiques : ici, le paquet compromis est le vrai paquet. La signature OIDC le confirme. Le CVE-2026-45321 a recu un score CVSS de 9.6 sur 10, et ce score est merite.

Pour les developpeurs open source francais, cette attaque est un signal d alarme. Si un projet aussi bien maintenu que TanStack — avec des milliers de contributeurs, une equipe de securite, et des processus CI/CD matures — peut etre compromis de cette maniere, aucun projet n est a l abri. Et la cible de l attaque n etait pas le code source — c etait votre pipeline CI/CD. Si vous utilisez pull_request_target dans vos GitHub Actions, si vous cachez des artefacts provenant de PRs externes, si vous faites confiance aveuglément aux paquets signes OIDC — vous etes potentiellement vulnerable. Cet article decortique la chaine d attaque complete, explique les mecanismes techniques, et vous donne les actions concretes a executer maintenant pour proteger vos projets.

Anatomie de l attaque : comment TeamPCP a compromis TanStack en 6 minutes

L attaque Mini Shai-Hulud repose sur une chaine de 3 vulnerabilites dans les workflows GitHub Actions de TanStack. Chaque vulnerabilite, prise isolement, aurait pu sembler benigne. Mais combinees, elles ont permis une compromission totale du pipeline de publication. Voici la chaine complete, etape par etape.

Etape 1 : Le fork strategique. L attaquant a cree un fork du repository TanStack/router et l a immediatement renomme en zblgg/configuration. Ce renommage n est pas anodin : il vise a echapper a la detection. Les outils de monitoring qui surveillent les forks de repositories populaires cherchent des noms associes au repository original. Un fork nomme "configuration" dans un compte obscur ne declenche aucune alerte. L attaquant a ensuite modifie le code du fork pour injecter un script malveillant dans les fichiers de configuration du build — specifiquement dans les scripts que pnpm execute lors de l installation des dependances.

Etape 2 : La pull request piege. L attaquant a ouvert une PR depuis son fork vers le repository TanStack/router. Cette PR, en apparence anodine, avait un seul objectif : declencher un workflow GitHub Actions configure avec l evenement pull_request_target. La difference cruciale entre pull_request et pull_request_target est que ce dernier execute le workflow dans le contexte du repository cible, avec acces aux secrets, aux tokens, et aux permissions de publication. Le workflow de TanStack faisait ensuite un actions/checkout en utilisant la reference du code du fork — executant ainsi le code de l attaquant avec les privileges du repository TanStack.

Etape 3 : L empoisonnement du cache. Le code malveillant execute dans le workflow n a pas tente de publier directement les paquets — ce qui aurait pu etre detecte. Au lieu de cela, il a empoisonne le cache GitHub Actions en modifiant le store pnpm cache. Lors du prochain build legitime declenche par un commit d un mainteneur TanStack, le cache empoisonne a ete restaure, injectant les modifications malveillantes dans les paquets construits. Les paquets ont ensuite ete publies via le pipeline de release normal de TanStack, signes avec l identite OIDC de confiance du projet. Pour npm et pour le monde, c etait une release authentique de TanStack.

Les paquets malveillants etaient concus pour operer silencieusement. Lors de l installation via npm install ou pnpm install, un script postinstall s executait en arriere-plan, scannait l environnement a la recherche de variables d environnement contenant des tokens (GITHUB_TOKEN, AWS_ACCESS_KEY_ID, NPM_TOKEN, etc.), les exfiltrait vers un serveur de commande et controle, puis s auto-nettoyait pour ne laisser aucune trace dans le systeme de fichiers. La sophistication du payload montrait que TeamPCP ne visait pas les developpeurs individuels — ils visaient les pipelines CI/CD ou ces variables sont systematiquement presentes.

Timeline de l attaque : 6 minutes qui ont ebranle npm

La chronologie de l attaque revele une preparation meticuleuse. Le fork et la modification du code ont eu lieu plusieurs jours avant la publication des paquets malveillants. La PR piege a ete soumise et le workflow declenche discretement. Mais la phase de publication elle-meme a ete d une rapidite fulgurante — concu pour minimiser la fenetre de detection.

L attaque n a pas vise uniquement TanStack. Dans la meme campagne coordonnee, TeamPCP a cible des paquets lies a Mistral AI, UiPath, Guardrails AI, et OpenSearch sur npm et PyPI. Au total, 170+ paquets ont ete compromis a travers les deux ecosystemes, totalisant 518 millions de telechargements cumulatifs. OpenAI a publie un communique confirmant que 2 postes employes avaient ete impactes par les paquets malveillants, mais qu aucun systeme de production n avait ete compromis. Cette confirmation d OpenAI est significative : meme les entreprises avec les ressources de securite les plus elevees au monde n ont pas ete epargnees. Pour nous, cela rappelle les lecons tirees lors de l analyse de l attaque supply chain LiteLLM sur PyPI en mars 2026.

pull_request vs pull_request_target : le piege mortel des workflows GitHub Actions

La vulnerabilite centrale exploitee par Mini Shai-Hulud est la confusion entre deux evenements GitHub Actions qui semblent similaires mais ont des modeles de securite radicalement differents. Comprendre cette difference est vital pour tout mainteneur open source. Si vous avez des workflows GitHub Actions dans vos projets, cette section pourrait bien etre la plus importante que vous lirez cette annee.

Le piege est subtil. pull_request_target a ete concu par GitHub pour un cas d usage specifique : permettre aux mainteneurs d executer des actions automatisees en reponse a des PRs externes (comme ajouter des labels, poster un commentaire de bienvenue, ou executer un check de CLA). Le workflow est cense utiliser uniquement le code du repository de base, pas celui du fork. Mais rien dans GitHub Actions n empeche un workflow pull_request_target de faire un actions/checkout en utilisant la reference du code de la PR — c est-a-dire du fork. Et c est exactement ce que faisait le workflow de TanStack. Nous avions deja alerte sur ces risques dans notre guide sur l audit des runners GitHub Actions.

Le pattern dangereux ressemble a ceci dans un fichier workflow :

# DANGEREUX — NE FAITES PAS CECI
on:
  pull_request_target:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
          # ^ Execute le code du FORK avec les secrets du REPO CIBLE
      - run: pnpm install
      - run: pnpm build

Contre ce pattern securise :

# SUR — Utilisez pull_request pour le build/test
on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        # Checkout du code du fork en mode lecture seule
        # Pas d acces aux secrets du repo cible
      - run: pnpm install
      - run: pnpm build

OIDC et la confiance compromise : quand la signature authentique devient une arme

L aspect le plus insidieux de Mini Shai-Hulud est l utilisation de l identite OIDC de confiance de TanStack pour signer les paquets malveillants. OIDC (OpenID Connect) est le mecanisme par lequel GitHub Actions permet a un workflow de prouver son identite aupres de services externes — comme npm — sans avoir besoin de stocker un token npm en secret. Le workflow demande un token ephemere a GitHub, qui atteste que le code est bien execute dans le repository TanStack/router, et npm fait confiance a cette attestation pour autoriser la publication.

Le probleme est que l attestation OIDC verifie d ou le code est execute, pas quel code est execute. Quand le workflow pull_request_target de TanStack a fait un checkout du code du fork et l a execute, GitHub a quand meme atteste que le workflow tournait dans le contexte de TanStack/router. L attestation OIDC etait donc techniquement correcte — le workflow etait bien dans le bon repo — mais le code execute etait celui de l attaquant. Npm a accepte les publications parce que l identite OIDC etait valide. Les checksums etaient coherents. Les signatures etaient authentiques. Du point de vue de npm, c etait une release normale de TanStack.

Cette faille remet en question le modele de confiance entier de la publication npm via OIDC. Si un attaquant peut exploiter un workflow mal configure pour publier des paquets avec une identite OIDC legitime, alors la signature OIDC ne garantit plus l integrite du paquet. Elle garantit seulement que le paquet a ete publie depuis un environnement CI/CD autorise — meme si cet environnement executait du code malveillant. Pour les developpeurs qui comptaient sur les signatures OIDC comme couche de verification supplementaire, c est un reveil brutal. Les outils comme npm audit signatures n auraient rien detecte dans ce cas.

Votre projet est-il vulnerable ? L arbre de decision

Avant de paniquer, evaluons methodiquement si votre projet est expose a ce type d attaque. L arbre de decision ci-dessous couvre les trois vecteurs principaux : l utilisation de paquets compromis, la vulnerabilite de vos workflows, et l exposition de vos secrets.

Impact sur l ecosysteme npm et au-dela

L attaque Mini Shai-Hulud a des consequences qui depassent largement le perimetre de TanStack. Elle expose une faiblesse systemique dans la facon dont l ecosysteme npm gere la confiance. Le modele actuel repose sur une hypothese simple : si un paquet est publie par un compte autorise (ou via OIDC depuis un repo autorise), alors le paquet est fiable. Mini Shai-Hulud demontre que cette hypothese est fausse. Un paquet peut etre publie par le bon compte, depuis le bon repo, avec la bonne signature, et etre neanmoins malveillant.

Les 42 paquets @tanstack/* compromis couvrent un spectre large de l ecosysteme JavaScript moderne. @tanstack/react-router (12,7M telechargements/semaine), @tanstack/react-query, @tanstack/react-table, @tanstack/react-virtual — ces bibliotheques sont des composants fondamentaux de milliers d applications web en production. L impact potentiel est vertigineux : chaque application qui a fait un npm install ou un pnpm install pendant les quelques heures ou les versions malveillantes etaient disponibles a potentiellement execute le payload de vol de credentials.

L extension de l attaque a PyPI montre que TeamPCP a une vision multi-ecosysteme. Les paquets Python lies a Mistral AI, UiPath, et Guardrails AI ont ete compromis avec des techniques similaires adaptees a l ecosysteme Python. Cela suggere que le groupe dispose de capacites techniques avancees et d une connaissance approfondie des CI/CD de multiples organisations majeures. Ce n est pas le travail d un scriptkiddie — c est une operation de renseignement sophistiquee ciblant la chaine d approvisionnement logicielle de l industrie tech mondiale. Les developpeurs Python francais trouveront des conseils complementaires dans notre guide pour proteger leur pipeline Python contre les attaques supply chain.

Ce que ca signifie pour vous — actions concretes

Action 1 : Auditez vos lockfiles immediatement. Executez npm audit ou pnpm audit sur tous vos projets. Verifiez que vos fichiers package-lock.json ou pnpm-lock.yaml ne referencent pas des versions de paquets @tanstack/* publiees pendant la fenetre d attaque. Les versions malveillantes ont ete retirees de npm, mais si votre lockfile les reference encore, executez npm ci apres avoir mis a jour les references pour forcer une reinstallation propre.

Action 2 : Auditez vos workflows GitHub Actions. Executez grep -r "pull_request_target" .github/workflows/ dans chacun de vos repositories. Si vous trouvez un workflow utilisant cet evenement, verifiez immediatement qu il ne fait PAS un actions/checkout avec une reference vers le code du fork. Si c est le cas, migrez vers pull_request ou supprimez le checkout du fork. Notre guide detaille sur la configuration de pipelines CI/CD avec GitHub Actions couvre ces patterns en profondeur.

Action 3 : Verifiez vos caches CI/CD. Si vos workflows utilisent le caching (actions/cache, setup-node avec cache, etc.), assurez-vous que les caches ne peuvent pas etre ecrits par des workflows declenches par des contributeurs externes. Utilisez des cles de cache qui incluent le nom de la branche et le SHA du commit pour eviter la reutilisation de caches potentiellement compromis. Pour les projets critiques, considerez la desactivation complete du cache pour les workflows de publication.

Action 4 : Rotationez vos secrets. Si vous avez installe des paquets @tanstack/* entre le 11 mai 19:20 UTC et le moment ou les versions malveillantes ont ete retirees, considerez que vos tokens et credentials ont potentiellement ete exfiltres. Rotationez vos tokens GitHub, vos cles API cloud (AWS, GCP, Azure), vos tokens npm, et tous les secrets accessibles dans votre environnement de developpement. C est la meme logique que celle que nous avions detaillee dans notre guide pour configurer Dependabot et Renovate pour l audit de securite des dependances.

Les lecons de Mini Shai-Hulud pour la securite supply chain

Lecon 1 : Les pipelines CI/CD sont la nouvelle surface d attaque. L epoque ou les attaques supply chain se limitaient au typosquatting (creer un paquet avec un nom similaire) ou a la compromission de comptes mainteneurs (voler un mot de passe npm) est revolue. Mini Shai-Hulud demontre que la cible la plus rentable est le pipeline de build et de publication lui-meme. Un attaquant qui compromet le pipeline n a pas besoin de voler des credentials — il utilise les credentials legitimes du projet pour publier des paquets malveillants. La defense doit se deplacer en amont, vers la securisation des workflows CI/CD.

Lecon 2 : La confiance transitive est un vecteur d attaque. Quand npm fait confiance a OIDC, que OIDC fait confiance a GitHub Actions, et que GitHub Actions execute du code non fiable via pull_request_target, la chaine de confiance est rompue mais personne ne le voit. Chaque maillon de la chaine fait son travail correctement — OIDC atteste que le workflow tourne dans le bon repo, npm verifie que l attestation est valide — mais le resultat est une publication malveillante. Les architectures de securite doivent prendre en compte ces cascades de confiance transitive et verifier a chaque etape que l hypothese de confiance tient.

Lecon 3 : La vitesse est une arme offensive. 84 versions en 6 minutes. C est le rythme de publication que TeamPCP a maintenu pendant la fenetre d attaque. Cette vitesse n est pas accidentelle — elle est concu pour depasser la capacite de detection humaine. Aucun mainteneur ne peut analyser 84 releases en 6 minutes. Les outils de monitoring npm traditionnels sont configures pour des anomalies sur des heures ou des jours, pas sur des minutes. La defense contre ce type d attaque necessite des systemes de detection automatises capables de reagir en temps reel — et ces systemes n existent pas encore de maniere generalisee dans l ecosysteme npm.

Lecon 4 : L open source n est pas inherement moins securise, mais ses vecteurs d attaque sont differents. Le fait que TanStack soit open source a permis a l attaquant de forker le repo et de creer une PR. Mais c est aussi le fait que le code soit open source qui a permis a la communaute de detecter l attaque en moins de 90 minutes et d analyser exactement ce que le payload faisait. Les projets proprietaires qui utilisent les memes patterns de workflow GitHub Actions sont tout aussi vulnerables — ils ont simplement moins d yeux pour detecter le probleme. La securite de l open source repose sur la transparence et la reaction rapide, pas sur l obscurite. Nous avions explore cette dynamique dans notre analyse du projet Glasswing d Anthropic et la securite open source.

FAQ