TanStack supply chain : 170 repos CrowdSec exfiltrés

Ce qui s'est passé

Le 16 septembre 2026, du code source appartenant à CrowdSec — spécialiste de la cybersécurité collaborative et éditeur d'un pare-feu communautaire open-source — est apparu en vente sur un forum fréquenté par des cybercriminels. L'enquête menée par la société a permis de retracer l'incident jusqu'à une attaque supply chain complexe menée contre l'écosystème npm TanStack en mai 2026, référencée sous le numéro CVE-2026-45321.

L'attaque contre TanStack s'est déroulée en plusieurs étapes le 11 mai 2026. Les attaquants ont d'abord identifié et exploité un workflow GitHub Actions configuré de façon non sécurisée via la directive pull_request_target, qui exécute du code de branches non approuvées avec les permissions complètes du dépôt principal. En combinant cette faille avec du cache poisoning dans GitHub Actions et l'extraction d'un token OpenID Connect (OIDC), ils ont pu publier 84 versions malveillantes réparties sur 42 packages npm de l'organisation officielle @tanstack. Chaque package embarquait un payload obfusqué qui s'exécutait à l'installation et collectait silencieusement des tokens GitHub et npm, des identifiants cloud (AWS, GCP, Azure), des secrets Kubernetes et Vault, ainsi que des clés SSH présentes sur les systèmes cibles.

TanStack est l'une des bibliothèques front-end les plus téléchargées dans l'écosystème JavaScript. TanStack Query (anciennement React Query) est utilisé dans des millions de projets, TanStack Router dans plusieurs centaines de milliers. L'ampleur de la distribution des packages malveillants — 84 releases sur 42 packages — signifie que des dizaines, voire des centaines de milliers de machines de développeurs ont pu être exposées lors de l'incident du 11 mai, le temps que les packages soient identifiés et retirés.

Dans le cas de CrowdSec, l'infection a touché le laptop d'un ancien employé. Cet employé avait quitté l'entreprise, mais son accès GitHub avait été conservé temporairement pour lui permettre de finaliser des tâches en cours. C'est précisément cette fenêtre de révocation différée qui a constitué le vecteur d'exploitation : le 22 mai 2026, soit onze jours après la compromission du package TanStack, l'attaquant a utilisé un token OAuth GitHub récupéré sur la machine de cet ancien employé pour s'authentifier auprès de l'API GitHub et cloner 170 dépôts privés appartenant à CrowdSec.

Les opérations réalisées via le compte compromis se sont limitées à des git fetch et git clone — aucune modification de code, aucun push, aucun accès aux secrets de pipeline CI/CD ou aux bases de données de production. CrowdSec confirme que son infrastructure de production n'a pas été atteinte. En revanche, le code source exfiltré comprend : la console SaaS de CrowdSec, des scripts et modèles de data science, des outils d'automatisation et de déploiement, ainsi que le code de l'algorithme de consensus utilisé pour valider et ajouter des adresses IP malveillantes à ses listes de blocage collaboratives — le cœur de son modèle de détection communautaire.

La durée entre le vol (22 mai) et la découverte (16 septembre) — environ quatre mois — est particulièrement préoccupante et illustre une limite bien documentée des systèmes de détection traditionnels : ils sont efficaces pour détecter des actions en temps réel ou quasi-réel, mais peinent à identifier des exfiltrations discrètes réalisées via des comptes légitimes, avec des outils légitimes (git), depuis des machines légitimes. L'opération n'a déclenché aucune alerte de DLP, aucune anomalie SIEM significative, aucun dépassement de rate limits sur l'API GitHub.

La chaîne d'attaque complète illustre ce que les experts en sécurité supply chain appellent une attaque en deux temps ou « time bomb » : un payload malveillant s'installe lors d'une dépendance npm, collecte des credentials, et les transmet à un serveur de commande et contrôle. Ces credentials restent ensuite exploitables longtemps après la désinfection initiale, surtout si les rotations de secrets ne sont pas systématiques. Dans ce cas précis, le token OAuth GitHub utilisé le 22 mai avait été capturé le 11 mai et n'avait pas été révoqué entre-temps.

CrowdSec a publié une analyse technique détaillée de l'incident et mis en place plusieurs mesures correctives : révision complète des accès GitHub des anciens employés, rotation de l'ensemble des tokens et secrets, audit des workflows GitHub Actions et activation de l'approbation obligatoire pour les pull requests externes. La société coopère avec les autorités compétentes dans le cadre de l'investigation sur les auteurs de l'attaque.

Pourquoi c'est important

Cet incident illustre trois risques systémiques que les équipes de sécurité sous-estiment régulièrement. Le premier est la persistance des accès après départ des collaborateurs. La politique de révocation immédiate des accès au moment du départ d'un employé est un contrôle de base dans tout référentiel de sécurité — ISO 27001, SOC 2, NIS2. Pourtant, dans la pratique, ces révocations sont souvent différées pour des raisons opérationnelles, créant une fenêtre d'exposition parfois exploitée des semaines plus tard. Le cas CrowdSec, onze jours entre la compromission du token et son utilisation, montre que les attaquants sont prêts à attendre.

Le deuxième risque est celui de la supply chain npm. Avec plus d'un million de packages et plusieurs milliards de téléchargements hebdomadaires, l'écosystème npm est une surface d'attaque d'une ampleur exceptionnelle. La technique utilisée ici — compromission d'un workflow GitHub Actions via pull_request_target pour publier des packages légitimes avec du code malveillant — n'est pas nouvelle, mais son application à un projet aussi populaire que TanStack démontre que même des bibliothèques très utilisées et maintenues par des équipes expérimentées peuvent devenir des vecteurs de distribution massive de malwares. Chaque développeur ayant exécuté npm install sur l'un des 42 packages affectés pendant la fenêtre du 11 mai a potentiellement exposé ses credentials.

Le troisième risque est celui de la visibilité dans les environnements DevOps modernes. Les outils de développement — IDE, terminaux, pipelines CI/CD — sont généralement exclus des politiques DLP ou de monitoring comportemental, car leur activité réseau normale (git clone, npm install, API calls) est indiscernable d'une exfiltration discrète. Il en résulte un angle mort structurel dans lequel les attaquants savent qu'ils peuvent opérer sans déclencher d'alertes significatives, comme l'a démontré le silence de quatre mois dans ce dossier.

Pour les RSSI et équipes SecOps, cet incident renforce plusieurs bonnes pratiques prioritaires : automatiser la révocation des accès dès le départ effectif des collaborateurs (zero-tolerance, même pour les accès « temporaires »), mettre en place du monitoring des tokens OAuth GitHub pour détecter les usages anormaux en dehors des heures de travail ou depuis des IPs inhabituelles, verrouiller les workflows GitHub Actions pour empêcher l'exécution de code non approuvé via pull_request_target, et imposer des rotations régulières des secrets de développement, indépendamment des incidents déclarés.

Ce qu'il faut retenir

• 170 dépôts privés de CrowdSec ont été exfiltrés via un token GitHub volé par le biais d'un package npm TanStack malveillant (CVE-2026-45321) en mai 2026.
• Le compte compromis était celui d'un ancien employé dont les accès GitHub n'avaient pas encore été révoqués — un vecteur classique mais systématiquement sous-estimé.
• Révoquer immédiatement tous les accès lors d'un départ, monitorer les tokens OAuth GitHub et verrouiller les workflows GitHub Actions sont les trois mesures prioritaires à implémenter.