CrowdSec perd 170 dépôts privés après la chaîne TanStack npm et un départ mal révoqué
Le 18 septembre 2026, CrowdSec a révélé qu’un attaquant a copié environ 170 dépôts GitHub privés en mai, via le compte d’un ancien salarié dont l’accès n’avait pas été révoqué. La compromission initiale venait des paquets npm malveillants de TanStack, qui ont aussi touché Mistral AI et OpenAI.
18 septembre 2026. CrowdSec reconnaît qu’un attaquant a copié environ 170 dépôts GitHub privés le 22 mai, en utilisant le compte d’un salarié qui venait de quitter l’entreprise. 11 mai. Les paquets npm malveillants de TanStack étaient publiés, semant la première graine. 16 septembre. Le code copié apparaît sur un forum. Pourquoi c’est important : ce n’est pas une seule faille, mais deux défaillances indépendantes enchaînées — une chaîne d’approvisionnement compromise et un départ mal révoqué — qui montrent comment un éditeur de sécurité français peut lui-même se faire voler son code.
La chaîne TanStack : 84 paquets npm piégés
Le point d’entrée est un cas d’école de supply chain attack sur l’écosystème npm. Le 11 mai 2026, 84 versions malveillantes de 42 paquets TanStack ont été publiées. L’incident est suivi sous le numéro CVE-2026-45321. Installer l’une de ces versions exécutait un code qui dérobait les identifiants de la machine du développeur : jetons GitHub, clés SSH et identifiants cloud.
Le salarié de CrowdSec concerné avait installé l’un de ces paquets sur son ordinateur portable. Le vol de jetons qui en a résulté est le maillon qui, onze jours plus tard, a permis la copie des dépôts. La chaîne d’approvisionnement n’est pas une métaphore : un paquet légitime et populaire a été remplacé par une version piégée, et la confiance implicite des développeurs dans npm install a fait le reste.
La même attaque a frappé d’autres entreprises françaises et américaines. Mistral AI a déclaré qu’un appareil de développeur était impliqué dans son cas. OpenAI a indiqué que deux appareils de salariés avaient été touchés, avec un accès non autorisé à un sous-ensemble limité de ses dépôts de code internes. CrowdSec, Mistral AI et OpenAI : trois éditeurs d’IA et de sécurité, un seul vecteur.
La copie : un départ dont l’accès a survécu
Le second maillon est plus embarrassant, car il est entièrement interne. L’attaquant a copié les dépôts avec un jeton OAuth GitHub appartenant à un ancien salarié. CrowdSec avait conservé son accès GitHub ouvert pour lui permettre de terminer un travail — une pratique courante, et rarement remise en cause au moment du départ.
La chronologie est édifiante. La copie a lieu le 22 mai. CrowdSec ne retire le compte de son organisation GitHub que le 25 mai, soit trois jours après la copie — et des mois avant d’apprendre la fuite. Le jeton n’a laissé aucune trace dans les journaux GitHub consultables, et n’existait plus au moment où l’entreprise a découvert le vol. C’est le support GitHub qui a retracé l’historique du jeton et confirmé que TanStack était bien la source.
Le code copié n’a pas été modifié : l’infrastructure et les bases de données n’ont pas été touchées. Mais ce qui a fuité est substantiel. Le lot comprend la console web de CrowdSec, ses scripts et modèles de data science, ses scripts d’automatisation, et surtout l’algorithme de consensus qui détermine quelles adresses IP entrent dans les listes de blocage partagées.
Ce que la fuite contenait, et ce qu’elle ne contenait pas
L’archive diffusée le 16 septembre sur un forum contenait aussi des données personnelles : les adresses e-mail de 83 utilisateurs de CrowdSec, et les noms, e-mails et contextes d’investissement de 51 investisseurs potentiels datant de 2020. Le PDG Philippe Humeau s’est adressé aux investisseurs pour « s’excuser personnellement » — un aveu rare dans ce type d’incident.
L’analyse d’impact de CrowdSec cherche à rassurer sur un point précis : la liste de blocage ne peut pas être empoisonnée. Il faudrait, selon l’entreprise, des dizaines de détections issues de dizaines de moteurs de confiance répartis sur des dizaines de réseaux distincts — à un coût prohibitif. L’entreprise peut en outre modifier les seuils de l’algorithme, ce qu’elle fait régulièrement.
Reste un détail qui en dit long : la seule identifiant utilisable dans la fuite était un accès au service de notification AWS SNS, limité à la publication sur un seul sujet. Quelqu’un a tenté de l’utiliser le 17 août, un mois avant la diffusion du code, sans aller plus loin. Les autres jetons avaient déjà été rotés ou n’étaient pas joignables depuis Internet.
La leçon devops : automatiser ce que l’humain oublie
L’incident CrowdSec est moins une histoire de malware sophistiqué que de processus défaillants. Deux choses auraient suffi à l’arrêter, et aucune n’est technologiquement difficile.
La première est l’automatisation de la révocation. Conserver l’accès d’un salarié parti « pour terminer un travail » est la règle implicite dans beaucoup d’équipes, et c’est exactement la fenêtre que l’attaquant a exploitée. Un offboarding qui révoque mécaniquement les accès GitHub, SSH et cloud au moment du départ — sans exception manuelle — ferme ce maillon. La seconde est la protection des postes de développement : CrowdSec n’exigeait pas de logiciel de protection des terminaux à l’époque, et le fait désormais sur les ordinateurs des salariés qui touchent au code ou aux systèmes.
La vérification du côté des dépendances se fait avec les outils déjà disponibles, en deux gestes :
# Auditer les dépendances npm du projet et signaler les vulnérabilités connues
npm audit --omit=dev
# Vérifier l'intégrité des paquets installés par rapport au lockfile
npm ci --ignore-scripts && npm ls --depth=0Le --ignore-scripts n’est pas un détail : ce sont les scripts d’installation (preinstall, postinstall) que les paquets piégés utilisent pour s’exécuter. Les désactiver par défaut, et ne les réactiver que pour les paquets dont on a vérifié la provenance, réduit directement la surface de cette attaque.
Verdict
CrowdSec a perdu 170 dépôts privés non pas à cause d’un exploit zero-day, mais de deux défaillances de processus qui se sont additionnées : une dépendance npm compromise et un accès de départ non révoqué. Si vous gérez des dépôts privés, automatisez la révocation des accès à l’offboarding — c’est la mesure la plus rentable de tout votre programme de sécurité. Si vos développeurs installent des paquets npm, auditez vos dépendances, désactivez les scripts d’installation par défaut et déployez une protection des terminaux sur les postes qui touchent au code. Les deux leçons coûtent moins cher que le jour où vous découvrirez votre propre code sur un forum.