Le 16 septembre 2026, CrowdSec a confirmé publiquement la compromission d'environ 170 de ses dépôts GitHub privés. L'origine : un paquet npm TanStack backdooré publié le 11 mai 2026 (CVE-2026-45321), qui avait extrait un jeton OAuth GitHub lié au compte d'un ancien employé dont les droits d'accès n'avaient jamais été révoqués. Le code source du SaaS, de connecteurs et de routines cloud a été copié. Aucune donnée client n'a été exposée. Pour les organisations qui utilisent les outils de CrowdSec, ou plus largement tout outil de sécurité hébergé, l'incident soulève des questions directes sur votre programme de gestion des tiers et vos obligations NIS2.
La chronologie de l'incident
Le 11 mai 2026, un attaquant a publié 84 versions malveillantes de 42 paquets TanStack sur le registre npm (source : CrowdSec blog, 16 septembre 2026). Ces paquets backdoorés ont été conçus pour extraire des jetons d'authentification des environnements de développement où ils étaient installés. CrowdSec utilisait TanStack dans son organisation et a été touché par ce vecteur.
Le 22 mai 2026, un attaquant a utilisé le jeton GitHub OAuth ainsi obtenu pour cloner environ 300 dépôts de l'organisation GitHub de CrowdSec, dont 170 dépôts privés. Ce jeton était associé au compte d'un ancien employé dont les accès n'avaient pas été désactivés après son départ.
La divulgation publique n'a eu lieu que le 16 septembre 2026. Entre la compromission initiale et la confirmation officielle, près de quatre mois se sont écoulés. Les dépôts privés concernés contiennent le code source de la console SaaS, des routines AWS et des connecteurs propriétaires.
Trois défaillances distinctes dans un seul incident
L'incident ne résulte pas d'une faille unique mais de trois défaillances cumulatives. La première : une dépendance npm utilisée sans analyse de composition logicielle (SCA) permettant de détecter les versions compromises dans les 24 à 48 heures suivant leur publication. La deuxième : un compte GitHub OAuth d'un ancien employé resté actif, constituant exactement le type d'identité non humaine orpheline que les programmes NIS2 doivent éliminer. La troisième : un délai de détection de plusieurs mois, incompatible avec les exigences de notification d'incident de NIS2 (24 heures pour l'alerte précoce, 72 heures pour la notification complète à l'autorité compétente).
Chacun de ces trois points correspond à une catégorie d'exigences NIS2 précise : la gestion des dépendances logicielles (article 21, paragraphe 2, point d), la gestion du cycle de vie des accès (article 21, paragraphe 2, point i) et les capacités de détection et de réponse aux incidents (article 21, paragraphe 2, point b).
Pourquoi cela vous concerne même si vous n'utilisez pas CrowdSec
La première réaction est de vérifier si CrowdSec figure dans votre inventaire logiciel. C'est nécessaire mais insuffisant. L'incident illustre un risque structurel : vos outils de sécurité sont eux-mêmes des fournisseurs tiers qui dépendent d'autres fournisseurs tiers.
Si vous utilisez un outil de sécurité open source ou SaaS, cet outil a une chaîne de dépendances npm, pip ou maven. Si l'un de vos outils de sécurité a été compromis, vous pouvez potentiellement être exposé à des vulnérabilités futures introduites dans le code source avant que les correctifs ne soient déployés, sans aucun moyen de le savoir si vous ne disposez pas d'un processus de surveillance contractuelle.
NIS2 article 21, paragraphe 2, point d, impose des mesures de sécurité pour la chaîne d'approvisionnement, y compris les aspects relatifs à la sécurité concernant les relations entre chaque entité et ses fournisseurs directs ou ses prestataires de services. Les outils de cybersécurité que vous déployez sont des prestataires de services au sens de cette disposition. Ils doivent figurer dans votre cartographie des tiers avec le même niveau de rigueur que vos prestataires de traitement de données.
Les angles morts dans votre programme TPRM
La plupart des programmes de gestion des risques tiers (TPRM) catégorisent leurs fournisseurs par nature de traitement de données ou par criticité métier. Les outils de sécurité finissent souvent dans une catégorie à part, traitée différemment sous prétexte qu'ils sont eux-mêmes des outils de sécurité. C'est un biais de confiance implicite que l'incident TanStack-CrowdSec illustre concrètement.
Les sept pièges classiques du démarrage d'une cartographie tiers incluent justement cette catégorie d'outils sous-évalués, comme le détaille l'article sur la cartographie des tiers 2026. Un outil de sécurité deployé en agent sur vos endpoints a un niveau d'accès aux systèmes qui justifie a minima une évaluation de maturité équivalente à celle d'un sous-traitant critique.
Deux questions concrètes à intégrer dans vos évaluations fournisseurs d'outils de sécurité :
Première question : avez-vous un inventaire des dépendances logicielles tierces (SCA) couvrant vos paquets npm, pip et maven, avec une fréquence d'analyse au moins hebdomadaire ? Un fournisseur qui ne peut pas répondre à cette question ne gère pas ce risque.
Deuxième question : quel est votre processus documenté de révocation des accès GitHub, AWS et systèmes d'intégration continue lors du départ d'un employé ? Dans quel délai est-il appliqué ? L'accès non révoqué d'un ancien employé était le vecteur d'amplification dans cet incident. CVE-2026-45321 en était l'entrée initiale.
Ce que la notification contractuelle doit couvrir
Si le code source de votre fournisseur de sécurité est exposé, vous avez besoin de savoir. Dans quel délai votre contrat exige-t-il qu'il vous notifie ? Si cette clause est absente, vous découvrirez l'incident par les médias spécialisés, comme beaucoup d'utilisateurs de CrowdSec.
NIS2 impose à chaque entité soumise de gérer les risques liés à ses prestataires. Si votre fournisseur de sécurité est lui-même une entité NIS2 importante ou essentielle, il a ses propres obligations de notification à l'ANSSI. Si ce n'est pas le cas, votre seul recours est contractuel. Il doit donc être explicite.
Trois clauses à vérifier dans vos contrats avec vos fournisseurs d'outils de sécurité : notification d'incident dans un délai inférieur à 72 heures après la prise de connaissance, communication de l'étendue de l'exposition et des données ou codes potentiellement compromis, et droit d'audit ou d'accès au rapport d'investigation post-incident.
Ce que cela change dans votre plan d'action
L'incident TanStack-CrowdSec n'est pas exceptionnel. Il est représentatif d'une classe d'attaques documentée depuis plusieurs années, appliquée à un acteur qui n'avait pas suffisamment protégé ses propres processus. Ce qui est nouveau, c'est qu'il touche un éditeur de sécurité dont beaucoup d'organisations supposaient implicitement que la posture de sécurité était supérieure à la moyenne.
Pour votre programme TPRM, l'ajustement pratique est limité mais précis : intégrez vos fournisseurs d'outils de sécurité dans votre catégorie de tiers à risque élevé, appliquez-leur votre questionnaire d'évaluation standard incluant SCA, révocation d'accès et notification contractuelle, et vérifiez que leur présence dans votre inventaire logiciel est à jour. Si certains de ces outils sont déployés en tant qu'agents ou capteurs sur vos systèmes, le niveau d'accès justifie une réévaluation annuelle, pas seulement lors du renouvellement du contrat.