Le 16 septembre 2026, un inconnu publie sur un forum l'intégralité du code privé de CrowdSec. L'éditeur français de cybersécurité découvre alors qu'on lui a copié 170 dépôts quatre mois plus tôt, en neuf minutes, avec le jeton d'un salarié déjà parti. La traîne d'une attaque qu'on croyait éteinte.
Neuf minutes et un jeton déjà mort
Le 22 mai 2026, entre 05h52 et 06h01 UTC, quelqu'un se connecte aux serveurs de GitHub depuis une adresse IP à Toronto. Neuf minutes plus tard, environ 170 dépôts privés de CrowdSec sont copiés. Trois virgule quatre gigaoctets de code non public. L'opération est propre, rapide, silencieuse.
Personne ne voit rien.
CrowdSec ne s'en apercevra que le 16 septembre, à 17h45, quand un inconnu diffuse l'archive sur un forum cybercriminel. Près de quatre mois. Et il y a une raison à ce silence, une vraie, presque embarrassante : le jeton qui a servi au vol n'existait plus. Créé, utilisé, révoqué. Sans trace exploitable.
C'est Philippe Humeau, le CEO, qui raconte. Dans son post-mortem publié le 18 septembre, il écrit avoir cherché la version hachée du jeton dans les journaux d'audit de son organisation et de ses membres. Rien. GitHub ne conserve l'activité git que sur une fenêtre glissante de sept jours, et seulement pour les plans Enterprise. CrowdSec n'en a pas. Le mot du CEO tient en quatre mots : « GitHub to the rescue ». C'est l'équipe de GitHub, en retraçant le cycle de vie complet du jeton, qui a remonté jusqu'à TanStack.
Un départ en bons termes, un portable infecté
Le jeton appartenait à un développeur qui venait de quitter l'entreprise. On s'était quittés en bons termes, explique Humeau. Le compte était resté membre de l'organisation pour lui laisser finir du travail. Son portable, lui, avait chopé le malware TanStack le 11 mai, onze jours plus tôt.
Le 25 mai, trois jours après la copie, le compte est retiré de l'organisation. Trop tard, évidemment. La leçon est d'une banalité affolante : on révoque l'accès le jour du départ, pas trois jours après. Pas quand le type a fini son travail. Le jour même.
Le pire, c'est que CrowdSec a fait les contrôles. Les machines des développeurs encore en poste, déclarées propres. Aucune publication malveillante @tanstack/* dans leurs dépôts. Le trou ne venait pas d'eux. Il venait de quelqu'un qui n'était plus là.
Le « Waze de la cybersécurité » s'est fait piquer son itinéraire
Pour mesurer l'ironie, il faut savoir qui est CrowdSec. Un éditeur français, basé à Montrouge, dans les Hauts-de-Seine. Environ 150 000 utilisateurs. Un moteur de détection open source qui bloque les adresses IP malveillantes, alimenté par une communauté : chacun partage ses détections, tout le monde reçoit une blocklist commune. La presse française l'a surnommé « le Waze de la cybersécurité ». On voit le tableau.
L'entreprise a levé 14 millions d'euros en série A en octobre 2022, menée par Supernova Invest avec Breega, selon Le Monde Informatique. Depuis, rien. Humeau l'écrit noir sur blanc : l'accès aux fonds était plus limité qu'avant, l'équipe un peu plus petite, cap sur le break-even. Autrement dit, une boîte qui serre les boulons et qui n'a pas les moyens de s'offrir un plan GitHub Enterprise avec sa fenêtre de rétention de sept jours. C'est précisément là que le bât blesse.
Une entreprise dont le métier est de voir les attaques. Qui n'a pas vu la sienne. Pendant quatre mois.
Ce qu'il y a vraiment dans 3,4 Go de code volé
Maintenant, soyons précis. Que contenait l'archive ?
La console web commerciale, l'API centrale, les services de threat intelligence, les scripts de data science. Et un truc qui fâche : les seuils exacts de l'algorithme de consensus, celui qui décide quelles IP rejoignent les blocklists. Combien de détections il faut, quelle diversité de systèmes autonomes, avant de blacklister une IP. Ces chiffres n'étaient pas publics. Ils le sont maintenant.
Mais le plus sensible, c'est autre chose. 134 personnes exposées. 83 adresses e-mail d'utilisateurs, que l'équipe data science gardait pour suivre l'usage du produit. Et 51 investisseurs potentiels de 2020, avec nom, e-mail et contexte d'investissement. Le site Fuites Info, qui recense les fuites touchant la France, a validé la fuite et listé les catégories de données concernées.
Pour le reste, CrowdSec relativise. Un seul identifiant réellement exploitable : un secret AWS SNS, limité à la publication sur un seul topic. Testé le 17 août depuis une IP américaine, sans effet au-delà de son périmètre. Pas d'accès aux bases de données, aucune modification de code, ni open source, ni privé, ni pipelines de build. Le CEO va jusqu'à écrire que la console volée n'a « presque aucune valeur » hors de son contexte AWS.
C'est l'argument qu'on veut bien entendre. Et qu'il faut prendre avec des pincettes. Dire « le réseau ne peut pas être empoisonné » parce qu'il faudrait des dizaines de détections, depuis des dizaines de moteurs vérifiés, répartis sur des dizaines de systèmes autonomes, c'est un calcul de l'éditeur. Pas un audit indépendant. Le fait même que les seuils soient désormais publics réduit le coût d'une future tentative.
La facture différée du npm
Revenons en arrière, parce que le vrai sujet n'est pas « un éditeur de sécurité se fait voler son code ». C'est la traîne.
Tout part du 11 mai 2026. Ce jour-là, TanStack se fait compromettre. Quarante-deux paquets @tanstack/*, 84 versions malveillantes publiées sur le registre npm entre 19h20 et 19h26 UTC. Six minutes. La CVE-2026-45321, un CVSS de 9,6. Derrière, l'acteur TeamPCP, aussi connu sous le nom UNC6780, et son malware Shai-Hulud, la variante Mini Shai-Hulud.
L'attaque en amont est un cas d'école. Trois vulnérabilités en chaîne, aucune suffisante seule. Un workflow pull_request_target qui s'exécute sur des PR de forks sans approbation. Un cache GitHub Actions empoisonné : un payload écrit dans le répertoire pnpm-store sous une clé précise, celle que le workflow de release légitime recalcule ensuite. Et un jeton OIDC extrait en mémoire du runner, en lisant /proc/<pid>/mem, avant d'être balancé directement sur registry.npmjs.org. Le tampon de confiance du projet, détourné.
Le malware installé, lui, est une saloperie. Il se déclenche à chaque npm install, pnpm install ou yarn install. Il récupère une charge de 2,3 Mo, collecte les identifiants — AWS, GCP, Kubernetes, Vault, ~/.npmrc, jetons GitHub, clés SSH. Il exfiltre via le réseau de partage de fichiers de Session, chiffré de bout en bout, sans C2 contrôlé. Puis il se propage en énumérant les autres paquets maintenus par la victime.
Les victimes secondaires s'empilent. OpenAI a confirmé deux postes employés touchés, avec rotation des certificats de signature macOS. Mistral AI, un poste développeur, des SDK npm et PyPI trojanisés, et du code mis à prix sur un forum. UiPath. OpenSearch. Guardrails AI. Et plus tard, selon les analystes de Protos Labs, Trivy, LiteLLM, Grafana, jusqu'à GitHub lui-même, via une extension VS Code piégée restée en ligne dix-huit minutes.
CrowdSec n'est donc pas la victime d'une attaque. C'est le troisième rebond d'une onde de choc. L'incident « éteint » côté TanStack en mai a continué à produire des dégâts en septembre.
Le 17 ils disaient « aucun nom », le 18 ils disent « 134 personnes »
Reste la zone d'ombre, et elle n'est pas glorieuse.
Le 17 septembre, dans un premier communiqué, CrowdSec affirme qu'aucun nom n'a fui. Le lendemain, le post-mortem reconnaît le contraire : 83 e-mails d'utilisateurs, 51 investisseurs potentiels. Fuites Info relève explicitement le revirement. C'est un point de fait, à citer tel quel.
L'autre critique vient du fil Hacker News, où l'affaire n'a récolté que 7 points et un commentaire. Un lecteur résume : « ils n'ont jugé bon de prévenir personne depuis mai, jusqu'à ce que le git fuite ». CrowdSec répond que, techniquement, il ne pouvait pas savoir. C'est vrai. C'est aussi le problème. Une entreprise de cybersécurité qui découvre une fuite par le forum d'un pirate, ça devrait faire réfléchir sur ce que signifie « surveiller » en 2026.
Il reste des questions sans réponse. Quel paquet malveillant précis a atteint le portable du développeur partant, et quand. Ce que GitHub a conclu exactement, au-delà de la substance reformulée par CrowdSec. Et l'attribution — « diencracked », un membre de BreachForum, identifié via l'IP de Toronto et le fuseau UTC-4 — relève de la métadonnée git, pas d'une enquête judiciaire.
Ce qu'il faut retenir, pour ne pas être le prochain
Le cas donne une checklist courte, et elle tient en cinq lignes. Révoquer l'accès GitHub le jour du départ, pas trois jours après. Tourner systématiquement les identifiants présents dans le code. Donner aux jetons AWS le scope le plus étroit possible. Avoir une journalisation d'audit qui tienne la route. Et savoir qu'un jeton mort ne laisse pas de trace exploitable si l'on n'a pas un plan Enterprise avec une fenêtre de rétention longue.
Du côté des mainteneurs open source, l'incident TanStack a déjà servi de leçon : fin des pull_request_target non audités, épinglage des actions tierces par SHA, refus des refs flottantes. TanStack le reconnaît lui-même dans son post-mortem. Tant mieux. Mais la leçon de CrowdSec est plus large : le risque ne s'arrête pas à votre paquet. Il continue chez tous ceux qui l'ont installé.
Verdict
Ce n'est pas un article pour dire « CrowdSec est nul ». C'est un article pour dire : la chaîne d'approvisionnement logicielle est devenue une machine à retardement, et le retardement peut durer des mois.
Ce qui est arrivé à CrowdSec arrivera à d'autres. Un salarié part, on garde son compte par politesse, son portable traîne un malware depuis deux semaines, et quatre mois plus tard votre code privé fait la une de BreachForum. La seule défense tient en une ligne : révoquer l'accès le jour du départ, tourner les identifiants, et ne jamais croire qu'un incident « résolu » ne fera plus de dégâts.
Le Waze de la cybersécurité a découvert qu'on lui avait volé son itinéraire. Quatre mois après, par un forum. Ça se retient.
Sources
- Post-mortem officiel de CrowdSec — source primaire : chronologie, forensique du jeton, inventaire de l'impact (18/09/2026)
- Fuites Info — « CrowdSec détaille la fuite de son code source : 134 personnes exposées » — source francophone, catégories de données, contexte France (16/09, mis à jour 18/09)
- The Hacker News — synthèse de l'attaque TanStack — CVE-2026-45321, CVSS 9,6, 42 paquets / 84 versions (13/05/2026)
- The Hacker News — répercussions OpenAI et Mistral AI — 2 postes OpenAI, certificats macOS, 1 poste Mistral (15/05/2026)
- Post-mortem TanStack — chaîne d'attaque en trois étapes, chronologie, IOC (mis à jour 15/05/2026)
- Protos Labs — campagne Shai-Hulud & Megalodon — victimes confirmées, extension VS Code GitHub (06/06/2026)
- Fil Hacker News — réception communautaire, critique du délai (20/09/2026)
- Le Monde Informatique — série A de 14 M€ — contexte financement (07/10/2022)
Idée d'illustration
💡 Une vue nocturne en plongée sur un bureau d'open space déserté, un écran éteint au premier plan dont le reflet montre un terminal noir. Sur l'écran, une ligne de commande git qui défile en vert : cloning 170 repos... avec un sablier. Au fond, par la fenêtre, la tour Montparnasse de nuit en silhouette. Ambiance néon froide bleu/violet, grain photographique, style éditorial néobrutaliste. Un détail ironique : un badge d'agent de sécurité posé sur le clavier, abandonné. Aucun texte superflu, la tension vient de la composition.
