Attaque npm TanStack : 42 packages compromis, CrowdSec touché

Comment 42 packages TanStack ont-ils été compromis ?

L’incident ne résulte pas du simple vol d’un mot de passe npm. TanStack utilisait GitHub Actions et le mécanisme OIDC Trusted Publishing, conçu pour éviter de conserver un token npm permanent dans les secrets du dépôt.

Lors d’une publication, le workflow autorisé obtient un jeton de courte durée pour communiquer avec npm. Cette architecture réduit les risques associés aux identifiants persistants, mais elle ne protège pas automatiquement contre la compromission du processus qui demande le jeton.

Selon le post-mortem de TanStack, un workflow GitHub Actions utilisant pull_request_target pouvait exécuter du code issu d’une pull request externe tout en interagissant avec un cache partagé. L’attaquant aurait exploité cette configuration pour empoisonner un cache ensuite restauré par un workflow légitime de publication.

Le code injecté a alors pu s’exécuter dans l’environnement de release et récupérer en mémoire le jeton OIDC destiné à npm. Ce jeton a servi à publier les versions malveillantes sous l’identité légitime du projet.

Le 11 mai 2026, deux versions malveillantes ont été publiées pour chacun des 42 packages @tanstack/* concernés, soit 84 versions au total. TanStack indique les avoir rapidement dépréciées puis retirées du registre.

Que faisait le code malveillant?

Les versions compromises contenaient un fichier JavaScript obfusqué d’environ 2,3Mo, exécuté pendant l’installation. D’après l’avis de sécurité publié par TanStack et GitHub, il recherchait plusieurs catégories de secrets accessibles depuis le poste ou l’environnement d’intégration continue.

Le code disposait aussi d’un mécanisme de propagation. Lorsqu’il trouvait les informations d’un mainteneur npm, il pouvait rechercher les autres packages associés à ce compte afin de tenter de les republier avec le même contenu malveillant.

Le risque ne dépend donc pas des données contenues dans le package lui-même. Il dépend surtout des ressources accessibles au processus qui exécute son script d’installation. Sur un poste de développement ou dans une CI, ce périmètre peut inclure des dépôts privés, des services cloud et des environnements de déploiement.

Du package npm aux dépôts privés de CrowdSec

Le 16 septembre 2026, CrowdSec a découvert qu’une archive contenant du code issu de son organisation GitHub avait été publiée sur un forum. L’entreprise a lancé une investigation avec GitHub afin de retracer le token OAuth utilisé pour télécharger les dépôts.

Selon CrowdSec, le token appartenait au compte d’un développeur ayant récemment quitté l’entreprise. Certains accès avaient déjà été révoqués, mais le compte restait présent dans l’organisation GitHub pour terminer des travaux en cours. Son poste aurait été compromis par l’attaque visant les packages TanStack.

Le 22 mai, ce compte aurait servi à cloner environ 170 dépôts GitHub privés. Son accès a été supprimé le 25 mai, avant que CrowdSec ait connaissance du clonage. L’archive n’est devenue publique que plusieurs mois plus tard.

Un périmètre important, mais circonscrit selon CrowdSec

CrowdSec affirme n’avoir constaté ni modification de ses dépôts, ni altération de ses pipelines de build ou de son code. L’entreprise indique également que ses bases de données et son infrastructure n’ont pas été compromises: le compte concerné aurait uniquement servi à cloner les dépôts.

La fuite comprenait toutefois du code privé, certaines adresses électroniques et quelques secrets présents dans les dépôts. CrowdSec cite notamment un token AWS lié au service SNS qui restait exploitable, mais dont les permissions limitées n’auraient pas permis de dépasser son périmètre prévu.

Le moindre privilège ne remplace ni la protection des postes ni la surveillance des identités. Il constitue une couche de confinement: lorsqu’une première barrière cède, les autorisations restantes déterminent jusqu’où l’attaquant peut aller.

Pourquoi les développeurs web sont particulièrement concernés

Un poste de développement concentre souvent de nombreux privilèges. Il peut être simultanément connecté à GitHub, npm, un hébergeur, plusieurs services cloud, des serveurs SSH, des bases de données et des environnements de préproduction.

Dans le même temps, ce poste installe régulièrement du code provenant de centaines, voire de milliers de dépendances directes et indirectes. Or certains packages disposent de scripts exécutés automatiquement pendant l’installation.

Une commande npm install ne télécharge donc pas seulement des fichiers JavaScript. Elle peut exécuter du code avec les permissions de l’utilisateur ou du processus CI qui l’a lancée. Une attaque contre npm peut ainsi devenir un incident GitHub, cloud ou CI/CD.

Comment vérifier si un projet a été exposé?

L’attaque a eu lieu le 11 mai 2026. TanStack indique que les versions malveillantes ont été détectées, dépréciées puis retirées et que les versions actuellement disponibles sont considérées comme sûres. Une équipe utilisant TanStack doit néanmoins vérifier si une version affectée a été résolue et exécutée pendant la période concernée.

L’avis de TanStack précise qu’une installation avec npm, pnpm ou Yarn pouvait déclencher le payload lorsqu’une version concernée était résolue. Tout environnement ayant exécuté l’une de ces versions doit donc être traité comme potentiellement compromis.

Six mesures pour réduire le risque supply chain

Renforcer les dépendances, les workflows et les identités

1. Verrouiller les versions et surveiller les changements inattendus dans les lockfiles.
2. Auditer les workflows GitHub Actions, notamment ceux utilisant pull_request_target.
3. Séparer les caches entre les contributions externes et les processus de publication de confiance.
4. Limiter les permissions de chaque token, compte, service et workflow au strict nécessaire.
5. Surveiller les installations et conserver des journaux permettant de retracer les opérations inhabituelles.
6. Retirer rapidement les accès des collaborateurs qui quittent l’organisation ou n’en ont plus besoin.

TanStack indique avoir renforcé ses workflows, leurs permissions, la gestion des caches et le verrouillage de certaines GitHub Actions après l’incident. Le cas montre que les fichiers situés dans .github/workflows font pleinement partie de l’infrastructure de sécurité d’un projet.

Encadrer les accès conservés après un départ

Le maintien temporaire d’un accès peut répondre à une contrainte opérationnelle, mais cette exception doit rester explicite, limitée dans le temps et surveillée. Une identité peu utilisée demeure exploitable si son poste, sa session ou ses tokens sont compromis.

Faut-il arrêter d’utiliser TanStack ou npm?

Non. TanStack a publié un post-mortem, retiré les versions concernées et mis en place plusieurs changements de sécurité. Au 15 mai, le projet indiquait que les versions alors disponibles étaient sûres à installer.

L’incident ne signifie pas non plus que npm soit intrinsèquement dangereux. Les applications JavaScript reposent nécessairement sur des bibliothèques tierces. Réécrire chaque composant ne supprimerait pas le risque et pourrait introduire d’autres vulnérabilités.

La réponse consiste plutôt à traiter les dépendances, les scripts d’installation et les pipelines qui les manipulent comme une partie entière de la surface d’attaque.

Une dépendance n’est pas seulement du code

Les pratiques habituelles se concentrent souvent sur les vulnérabilités connues et la mise à jour régulière des packages. Les attaques supply chain ajoutent une autre question: que se passe-t-il si la nouvelle version devient elle-même le vecteur d’attaque?

Dans ce scénario, installer la version la plus récente ne constitue plus automatiquement une protection. La sécurité repose sur plusieurs couches: contrôle des versions, analyse des nouvelles dépendances, séparation des permissions, protection des postes, surveillance des publications et capacité à renouveler rapidement les secrets.

Le risque npm dépasse largement node_modules

L’incident ne s’est pas limité aux 42 packages publiés sur npm. Une dépendance compromise a pu rechercher des informations dans un environnement de développement. D’après l’investigation de CrowdSec, l’un des accès ainsi exposés aurait ensuite permis de cloner environ 170 dépôts GitHub privés.

Le fichier malveillant peut se trouver dans node_modules, mais sa cible réelle peut être GitHub, le cloud, la CI/CD ou tout autre service accessible depuis le poste du développeur.

Avant d’installer une dépendance, la question n’est donc plus seulement de savoir si elle fonctionne. Il faut aussi déterminer ce à quoi elle pourra accéder si elle devient malveillante. C’est ce périmètre qui fixe l’impact réel d’une compromission.