Le 11 mai 2026, entre 19 h 20 et 19 h 26 (UTC), 84 versions malveillantes de 42 paquets @tanstack/* ont été publiées sur npm. TanStack est une famille de bibliothèques très utilisée dans l’écosystème React. Particularité de l’attaque : aucun jeton npm n’a été volé, et le workflow de publication lui-même n’a pas été compromis. Le post-mortem publié par l’équipe est un cas d’école pour quiconque fait de l’intégration continue.
Trois faiblesses, une chaîne
Prise isolément, aucune des trois faiblesses n’aurait suffi. C’est leur enchaînement, qui franchit à chaque fois une frontière de confiance, qui a fait l’attaque.
1. Le « Pwn Request »
Un workflow chargé de mesurer la taille des paquets utilisait l’événement pull_request_target. Il récupérait le code de la pull request venant d’un fork, puis lançait un build. Or pull_request_target s’exécute avec les droits du dépôt principal. L’attaquant a ouvert une pull request depuis un fork renommé, avec un commit piégé : son code s’est exécuté dans un contexte de confiance, sans validation préalable d’un nouveau contributeur.
2. L’empoisonnement du cache
Pendant ce build, le script malveillant a enregistré un cache pnpm empoisonné, sous une clé que le workflow de publication allait restaurer plus tard sur la branche principale. La pull request a ensuite été refermée : le piège, lui, est resté dans le cache.
3. Le vol du jeton OIDC en mémoire
Quand le workflow de publication s’est exécuté sur la branche principale, il a restauré le cache piégé. Le code de l’attaquant a alors lu la mémoire du runner pour en extraire le jeton OIDC, et l’a utilisé pour publier directement sur le registre npm, en contournant l’étape de publication prévue.
Ce que faisaient les versions piégées
À l’installation, une dépendance optionnelle injectée et un script prepare lançaient un fichier JavaScript obscurci d’environ 2,3 Mo. Il :
- récupérait des identifiants : secrets cloud, jetons Kubernetes et Vault, identifiants npm et GitHub, clés SSH ;
- les exfiltrait via un réseau de partage de fichiers décentralisé, sans serveur de commande facile à bloquer ;
- se propageait en republiant les autres paquets maintenus par la victime avec la même injection.
TanStack recommande à toute personne ayant installé une version touchée le 11 mai de considérer la machine comme compromise et de renouveler tous ses identifiants : AWS, GCP, Kubernetes, Vault, GitHub, npm et SSH.
Une détection venue de l’extérieur
Le premier signalement public est venu d’un chercheur de StepSecurity, environ 26 minutes après la première publication. Les premières versions ont été dépréciées en une heure, l’ensemble du périmètre identifié en 1 h 43, et npm a retiré le dernier paquet du registre environ 4 h 35 après le début. Le 15 mai, TanStack a confirmé que toutes les versions disponibles étaient saines.
L’équipe reconnaît elle-même les failles de son dispositif : aucune alerte interne, des workflows pull_request_target jamais audités, des actions tierces référencées par branche (@main), et sept mainteneurs sur le scope npm, soit autant de cibles pour un vol d’identifiants.
Les leçons pour vos propres pipelines
- Auditez chaque
pull_request_target. Un workflow qui récupère et exécute le code d’un fork avec les droits du dépôt est une porte ouverte. - Séparez les caches entre les workflows qui traitent du code externe et ceux qui publient ou déploient.
- Épinglez les actions tierces par SHA, jamais par branche.
- Limitez qui et quoi peut publier : peu de comptes, double authentification, et pour les projets sensibles une validation humaine avant publication.
- Surveillez vos dépendances : une alerte sur une nouvelle version inattendue vaut mieux qu’une découverte par un tiers.
Depuis, npm a durci ses règles : depuis le 2 octobre 2026, les jetons issus d’événements issue_comment sont refusés, en plus de ceux de pull_request_target. Nous détaillions ces changements dans notre article du 24 octobre.
Pour vérifier qu’une archive ou un fichier n’a pas été modifié, notre calculateur d’empreinte SHA-256 fonctionne directement dans le navigateur.
Source
- TanStack, « Postmortem: npm supply-chain compromise », mai 2026 : https://tanstack.com/blog/npm-supply-chain-compromise-postmortem
