CrowdSec a perdu 170 dépôts privés en neuf minutes à cause d’une lacune dans le processus de départ

Le 22 mai 2026, entre 05:52:29 et 06:01:33 UTC, une personne travaillant depuis une adresse IP à Toronto, au Canada, a utilisé le compte GitHub d’un développeur qui venait de quitter CrowdSec pour copier environ 170 des dépôts privés de la société de sécurité française. CrowdSec a publié cette chronologie dans son propre rapport d’incident le 18 septembre 2026 — date que l’archive des incidents d’IA attribue à cet enregistrement — après qu’une archive de son code source est apparue sur la place de marché cybercriminelle pwnforum le 16 septembre. Le compte fonctionnait encore parce que l’entreprise avait délibérément laissé l’accès GitHub du développeur ouvert afin qu’il puisse terminer un travail. L’ordinateur portable derrière ce compte avait été infecté onze jours plus tôt par le ver voleur d’identifiants Mini Shai-Hulud que TeamPCP a diffusé via les paquets npm de TanStack. Cette entrée est tirée de l’enregistrement déposé le 18 septembre 2026, et l’ensemble complet des incidents documentés — chaque entrée comportant sa propre gravité, son niveau de confiance, son indicateur de contestation et ses sources — se trouve dans l’Orca AI Incident Archive, où cette entrée peut être consultée aux côtés des autres cas de chaîne d’approvisionnement de la même année.

Le vol ne s'est pas limité au code. Le rapport de CrowdSec a également divulgué les adresses e-mail de 83 utilisateurs, issues d'une liste interne de surveillance en science des données et majoritairement des comptes Gmail, ainsi que les prénoms et noms, adresses e-mail et le contexte d'investissement de 51 investisseurs potentiels de 2020. Sur environ 150 000 utilisateurs, 83 adresses représentent une faible fraction ; mais pas zéro. Le directeur général Philippe Humeau a réservé ses excuses personnelles aux investisseurs : « La divulgation de vos noms et adresses e-mail est un problème que nous aborderons directement avec vous et les autorités compétentes, et pour cela je vous présente personnellement mes excuses. »

Ce que neuf minutes ont réellement pris

Les enregistrements Git que GitHub a renvoyés à CrowdSec commencent à 05:52:32.138 UTC par un fetch sur l’un des dépôts de l’entreprise, et l’activité s’arrête à 06:01:33. Le chiffre de l’archive, environ 170 dépôts privés, provient de ces données Git. Dans son compte rendu, Humeau décrit l’exposition comme « limitée au code source de CrowdSecurity, y compris 130+ dépôts publics et de nombreux dépôts privés ». DevOps.com, qui a rapporté l’incident le 24 septembre, a évalué le nombre total de dépôts publics et privés à environ 300 dépôts — un chiffre plus élevé que celui des dépôts privés de CrowdSec, et que le rapport de l’entreprise ne mentionne pas.

Le contenu était constitué de l'équipement habituel d'une société SaaS en pleine croissance : le code source de la console web, les scripts de déploiement et d'automatisation, ainsi que les scripts et modèles de science des données derrière ses analyses. L'élément le plus sensible que CrowdSec cite est l'« algorithme de consensus » qui détermine quelles adresses IP parviennent à ses listes de blocage. L'architecture de l'algorithme était déjà publique, mais ses seuils de diversité et de détection ne l'étaient pas, et ils sont désormais connus. Humeau soutient que les seuils sont une cible mouvante et qu'orienter le consensus nécessiterait encore une flotte de serveurs importante et coûteuse ; l'entreprise affirme pouvoir les ajuster et surveiller les écarts.

Les identifiants étaient la partie qui aurait pu bien plus mal tourner. « Nous étions très proches d’être propres », a écrit Humeau. Le seul secret exploitable du dump était un jeton AWS Simple Notification Service, limité à la publication sur un seul sujet. Quelqu’un l’a testé le 17 août 2026 depuis l’IP 23.234.84.102, en appelant GetCallerIdentity et ListTopics sur les sujets dev et env, sans aller plus loin. La plupart des autres jetons et secrets du code avaient été révoqués ou renouvelés avant la fuite. CrowdSec affirme que son infrastructure et ses bases de données n’ont pas fait l’objet d’accès et qu’aucun code n’a été modifié dans le projet open source, son code source privé ou ses pipelines de compilation.

Pourquoi le compte fonctionnait encore

L'échec de l'offboarding est minime et précis. Au moment où le développeur est parti, CrowdSec avait déjà supprimé ses autres accès ; le compte GitHub a été maintenu actif, a écrit Humeau, parce que « nous nous sommes séparés en bons termes de notre développeur, et il voulait finaliser un travail ». Le compte a été retiré de l'organisation GitHub le 25 mai, trois jours après que les dépôts avaient déjà été copiés.

CrowdSec n'a pas pu constater le vol sur le moment, et la raison mérite d'être énoncée avec précision. Le jeton OAuth n'était présent ni dans le journal d'audit de l'organisation, ni dans celui d'aucun membre actuel, et au moment où quelqu'un s'est mis à le chercher, il n'existait plus : il avait été créé, utilisé et expiré sans laisser de trace que l'entreprise puisse lire. GitHub ne conserve l'activité Git que sur une fenêtre glissante de sept jours pour les organisations qui ne sont pas sur un plan Enterprise, comme CrowdSec le note elle-même. Le déclic est venu de l'équipe d'assistance de GitHub, qui a retracé le cycle de vie complet du jeton et fourni l'activité Git pour la fenêtre de deux heures autour de la copie. C'est ainsi que l'entreprise est remontée jusqu'au compte d'un ancien employé. Le lien avec TanStack est ressorti du même exercice.

L'archive divulguée portait ses propres preuves. Le .github/.git/config qu'elle contenait enregistrait une URL d'origine de la forme oauth2:gho_xxxxxxxxx@github.com, ce qui identifiait le justificatif d'accès comme un jeton OAuth GitHub et correspondait à la méthodologie documentée de TeamPCP. CrowdSec indique avoir inspecté les machines de développeurs à la recherche de paquets malveillants et n'avoir trouvé aucune des versions de TanStack contenant une porte dérobée dans ses propres dépôts — un résultat qu'elle qualifie de non concluant plutôt que disculpatoire.

Qui l’a fait, et quelle est la solidité de l’attribution

CrowdSec attribue le téléchargement à « l’un des fondateurs de BreachForum et à un membre, diencracked », l’adresse du membre étant indiquée comme diencracked@cock.li, opérant depuis une IP de Toronto avec le fuseau horaire de la machine réglé sur UTC-4. L’entreprise ajoute sa propre réserve dans la même phrase : « Du moins, c’est ce que montrent les données Git. » Le rapport de Dark Reading du 22 septembre reprend la même attribution au fondateur de BreachForum et au pseudo diencracked.

La campagne en amont est mieux documentée que les identités qui se cachent derrière elle. Les paquets de TanStack ont été compromis par une porte dérobée le 11 mai 2026, lorsque 84 versions malveillantes réparties sur 42 paquets ont été publiées ; The Hacker News documente la compromission sous la référence CVE-2026-45321 et cite l’avis de TanStack lui-même concernant la charge utile de vol d’identifiants. La chronologie de CrowdSec indique que le 22 mai, le jour même de la copie du dépôt, TeamPCP — suivi par CrowdSec sous le nom de UNC6780 — a revendiqué la compromission de dépôts appartenant à Mistral AI.

Ce qui est établi, et ce qui ne l’est pas

Établi : une copie d'environ 170 dépôts privés a eu lieu le 22 mai 2026, sur une fenêtre de neuf minutes, à l'aide du compte GitHub encore valide d'un développeur parti — une séquence reconstituée à partir des propres registres d'activité Git de GitHub, et non déduite. Également établi par la version de l'entreprise elle-même : l'exposition de 83 adresses e-mail d'utilisateurs et des coordonnées de 51 investisseurs potentiels, la révocation du 25 mai, le jeton SNS sondé, et la conclusion qu'aucun code n'a été modifié et qu'aucune infrastructure ni base de données n'a été atteinte.

Non établi : quel paquet empoisonné a atteint l'ordinateur portable, et quand. CrowdSec déclare clairement qu'il n'a identifié ni l'un ni l'autre. L'analyse du dépôt de l'entreprise n'a pas été concluante, et ses machines de développeurs se sont révélées propres, ce qui s'accorde mal avec un ordinateur portable qui, de l'aveu même de l'entreprise, a été compromis. Cette lacune est reconnue plutôt que comblée.

Non publié : le versant GitHub de l’enquête. CrowdSec affirme que l’équipe d’assistance de GitHub a corroboré l’origine TanStack, mais The Hacker News note que le rapport de l’entreprise ne contient aucune conclusion émanant de GitHub lui-même, et GitHub n’a pas publié son propre compte rendu du cycle de vie du jeton.

Corroboration :Dark Reading, The Hacker News et DevOps.com ont chacun couvert l'incident en l'espace d'une semaine, et tous trois s'appuient sur le rapport de CrowdSec et l'avis de TanStack plutôt que sur un examen forensic indépendant des systèmes de CrowdSec. Dark Reading ajoute les commentaires de praticiens extérieurs, dont Denis Calderone de Suzu Labs, qui a qualifié ce manquement à la révocation de « day-one stuff ». Une note de recherche de la Cloud Security Alliance datée du 20 septembre reprend la séquence, mais le document comporte son propre avertissement selon lequel il a été généré avec l'aide de l'IA et n'a pas fait l'objet d'une relecture officielle de la CSA — bon à savoir avant de le compter comme une seconde constatation indépendante. L'archive attribue à la fiche la confiance A, disputed false, real harm true.

La première déclaration, et la correction

La première déclaration publique de CrowdSec, le 17 septembre, indiquait qu’« aucune donnée client, identifiant/mot de passe, nom, organisation ou quoi que ce soit d’autre n’avait fuité, et que CrowdSec ne stocke ni données personnelles ni journaux clients ; l’impact se limite à CrowdSec ». Elle a également avancé une hypothèse technique : celle selon laquelle un composant interne aurait été piégé par une porte dérobée afin de voler une clé API capable de lire du code privé.

Le rapport plus complet, un jour plus tard, a remplacé cette hypothèse par la version de l’employé parti et a révélé les 83 adresses et les 51 investisseurs. The Hacker News décrit cela comme une correction de l’affirmation initiale. La présentation de CrowdSec elle-même est plus étroite : les 83 adresses provenaient d’une liste de surveillance de science des données plutôt que de dossiers clients, et les détails sur les investisseurs dataient de 2020. Les deux descriptions peuvent être vraies en même temps — les adresses n’étaient pas des comptes clients, et elles restaient des données personnelles dans un dump publié sur un forum criminel. L’entreprise indique qu’elle informera les utilisateurs et les investisseurs concernés et signalera la fuite aux autorités.

Qu’est-ce qui a changé par la suite ?

• Les identifiants et jetons trouvés dans l'archive ont été renouvelés dans la nuit du 16 septembre et tout au long du 17 septembre, le reste du renouvellement ayant été achevé le lendemain matin.

• La détection et la réponse sur les points terminaux est désormais déployée sur les postes de travail et les ordinateurs portables des personnes qui touchent à la base de code ou à l'infrastructure de CrowdSec ; la société désigne Aikido Security comme produit. Humeau reconnaît qu'elle aurait dû être en place plus tôt, et reconnaît également que la machine d'un ancien employé n'était probablement pas équipée.

• Les seuils de l'algorithme de consensus révélés par la fuite sont en cours d'ajustement, avec un suivi renforcé des déviations statistiques sur l'ensemble du réseau de listes de blocage.

• L’entreprise s’est fixé pour objectif de réduire ce même délai d’intervention — inventaire, rotation, analyse forensique et divulgation — de 48 heures à moins de 24.

• Les utilisateurs et investisseurs concernés sont contactés directement, et la fuite est signalée aux autorités, selon la formulation de l’entreprise.

Pourquoi cela figure dans une archive d’incidents d’IA

L'implication de l'IA ici est d'ordre infrastructurel, et il vaut la peine d'être précis sur ce que cela signifie. Rien dans le récit de CrowdSec ne décrit un système d'IA prenant une décision pendant l'intrusion ; l'acteur était une personne ou des personnes utilisant un jeton volé. Ce qui fait de ce cas un incident du secteur de l'IA, c'est son rayon d'impact. Les bibliothèques de TanStack constituent les interfaces d'une grande partie des logiciels modernes, le ver qui a récupéré le jeton est conçu pour s'emparer en une seule passe des identifiants cloud, SSH et de fournisseurs de modèles, et les éléments copiés depuis CrowdSec comprenaient des scripts et des modèles de data science, et non uniquement du code applicatif.

La même campagne a directement touché des entreprises d’IA. La chronologie de CrowdSec rapporte que TeamPCP a revendiqué les dépôts de Mistral AI le 22 mai, et The Hacker News rapporte que deux appareils d’employés d’OpenAI ont été affectés, avec un accès non autorisé à un ensemble limité de dépôts de code internes. L’archive consigne le cas CrowdSec comme la deuxième victime en aval de la compromission de TanStack de mai, après ces appareils du personnel d’OpenAI.

L’écart entre la copie et sa découverte est la partie qui devrait circuler. Les dépôts ont été récupérés le 22 mai ; CrowdSec a appris la fuite le 16 septembre, lorsque l’équipe de Fuites Info a contacté l’entreprise au sujet du post sur pwnforum — 117 jours plus tard, et non grâce à sa propre surveillance. Le mécanisme qui a rendu ce retard possible n’avait rien d’exotique : un compte qui a survécu trois jours à son objectif, un jeton qui n’a laissé aucune trace dans les journaux que l’entreprise pouvait lire, et des ordinateurs portables de développeurs sans détection de point de terminaison. CrowdSec, une entreprise qui vend de la détection de menaces, réunissait les trois.