Analyse de l’attaque de la supply chain TanStack

Version courte

CrowdSec utilise GitHub pour versionner son code, tant open source que privé. Le code source privé de la console et de certains outils satellites a été mis en ligne par des cybercriminels. Ce code a été volé en mai 2026. Aucune donnée client, utilisateur ou fournisseur n’a été impactée, c’est essentiellement le code source de la console SaaS qui a été publié. L’attaque a été menée concomitamment à celle de Mistral.ai, et elle a consisté en la compromission de l’entité TanStack par un groupe du nom de TeamPCP. Tanstack met à disposition des paquets NodeJS dans lesquels une porte dérobée a été introduite. Un de nos anciens employés, toujours membre de l’organisation github (pour finaliser un projet) a été infecté par la récupération d’une version compromise du paquet lui a été servie par TanStack. Celle-ci contenait une backdoor du nom de Shai Ulud qui a permis à TeamPCP d’obtenir un token API GitHub valide lui permettant de lire les bases de code non-publiques de CrowdSec sur GitHub.

Contexte

Chaque hack intervient dans un contexte humain, business, technologique et sociologique en pleine évolution. Ce qui est douloureux pour CrowdSec aujourd’hui, c’est que beaucoup d’entre nous viennent du monde du test d’intrusion, ont fait des décennies de cybersécurité, et ont développé des réflexes « cybersec » dans leur travail quotidien. Dans ce contexte, découvrir que l’on “leak” du code privé prend une autre dimension.

CrowdSec a trouvé son business model (PMF, ou Product-Market Fit pour les intimes), et notre modèle SaaS low-touch a commencé à prendre auprès des utilisateurs. La société prend son envol. Certes, l’équipe s’est un peu réduite, car nous avons dû maîtriser les coûts dans un environnement où l’accès au capital était plus contraint qu’avant, mais globalement, nous sommes une startup heureuse, voguant vers le break-even. Récemment, nous avions d’ailleurs entamé des discussions avec des gouvernements et des ministères dans pas moins de 7 pays, tandis qu’un profil “AAA” de l’industrie toquait à notre porte. Tout allait donc pour le mieux, c’est pourquoi le 16 septembre nous a pris par surprise.

Que s’est-il passé, comment, quelle a été la réaction de l’équipe, la timeline, le point d’origine, comment réagir si quelque chose de similaire arrive à votre équipe, et que fera-t-on différemment à l’avenir ? Quel est l’impact réel derrière le gros titre ? Qu’est-ce qui est important, marginal, ou objectivement insignifiant ?

Mais d’abord… que s’est-il passé ?

The Timeline

• 11 mai 2026 : TeamPCP compromet un dépôt de paquets NPM célèbre nommé TanStack, largement utilisé par les développeurs pour créer des UI web basées sur Node.js. 42 packages sont backdoorés avec leur malware « Shai Hulud », spécialisé dans le vol de credentials et de tokens.
• 22 mai 2026 : TeamPCP (Threat Actor UNC6780) revendique le piratage de plusieurs dépôts de Mistral AI.
• 22 mai 2026 – 05h52:29 à 06h01:33 UTC : l’un des fondateurs de BreachForum et un membre, diencracked (a priori), télécharge le contenu de ~170 dépôts GitHub privés de CrowdSec depuis une adresse IP située à Toronto, au Canada (UTC-4). Le nombre de dépôts est relativement secondaire, tout comme leur taille absolue, puisque cela dit davantage de l’organisation du code et des images utilisées dans l’interface web qu’autre chose. Mais sur les forums de breach, les gros chiffres sont un argument de communication. Le point clé, c’est qu’il a eu accès à une base de code privée qui n’était pas censée être exposée, et ça, c’est un fait réel et vérifié par nos soins.
• 25 mai 2026 – après-midi : L’accès GitHub du laptop de l’employé compromis est révoqué (tous les autres l’étaient déjà et on reviendra sur ce point) pour une raison sans lien avec l’incident de sécurité. On l’avait laissé actif parce qu’on s’était séparés en bons termes avec notre développeur, qui souhaitait finaliser certains travaux.
• 17 août 2026 : Le token AWS utilisé pour les notifications SNS (contenu dans le leak) est testé afin de vérifier ses autorisations exactes.
• 16 sept. 2026 – 17h45 : Publication sur le forum.
• 16 sept. 2026 – 20h : Entre fuitesinfos.fr et CrowdSec, une cellule de crise est mise en place.
• 16 sept. 2026 – nuit : Actions forensiques initiales, rotation des identifiants et des tokens clés.
• 17 sept. 2026 – matin: Forensic, coordination, reporting, rotation des tokens/credentials restants.
• 17 sept. 2026 – midi : Communication  initiale exposant les faits dont on était déjà sûrs
• 17 sept. 2026 – 18h : GitHub nous apporte une réponse sur le token incriminé, ce qui nous permet de retracer son cycle de vie (la clé API que MrWHO évoque sur le forum).
• 18 sept. 2026 : Publication de ce rapport en Anglais
• 21 sept. 2026 : Publication de ce rapport en Français.
  

Évaluation des risques post-incident

Lors d’une analyse d’incident cyber, on est toujours sous pression pour déterminer si seule la base de code a été touchée ou si les données connectées et l’infrastructure cloud l’ont également été. En « théorie », le scénario idéal en cybersécurité, c’est que les mécanismes d’authentification, les tokens, les identités, et toute forme de credentials soient absolument absents de toute base de code. Sauf qu’on ne vit pas dans cette belle « théorie » ; on vit sur Terre, avec des humains.

Code:

Console : Pour la petite histoire, nous avons longuement réfléchi à open-sourcer la console elle-même, mais nous ne l’avons pas fait (encore) pour trois raisons principales: 

1/ Cet outil n’est pas utilisable sans les microservices AWS qui tournent derrière

2/ Structurellement, ce n’est pas réellement un projet où les utilisateurs peuvent contribuer, il est plus simple de demander une fonctionnalité que de l’ajouter soi-même 

3/ Le fait qu’une branche de code soit open source est délibérément planifié en amont. Même s’il est possible d’open-sourcer quelque chose a posteriori, les bases de code qui évoluent rapidement (comme la console SaaS) ne sont pas des candidats idéaux. 

Le réel problème, c’est que personne n’en aurait l’utilité. Ce code a-t-il de la valeur ? Oui, le temps que notre équipe a passé à coder, à réfléchir aux fonctionnalités, à leur agencement, aux interfaces de reporting, etc. Cela a-t-il de la valeur pour autrui ? Très probablement non, ce code est beaucoup trop contextuel. Contenait-il des secrets ? Non. La vraie question reste : la connaissance intime du code peut-elle aider à mener des attaques ultérieurement ? La sécurité par l’obscurité n’est jamais un bon modèle, mais avoir le code source complet en main peut accélérer la recherche de faiblesses potentielles, notamment à l’époque de l’IA-everywhere. Cela dit, CrowdSec a également accès à ces modèles d’IA et nous pouvons (et le faisons) évaluer la sécurité de notre propre code. Alors, est-ce idéal ? Non. Est-ce très grave ? Non. Nous continuerons à surveiller étroitement les diverses sources de logs, traces et audits à notre disposition, et à vérifier que rien ne dévie de la normale. De toute façon, cette base de code évolue rapidement, et 4 mois plus tard, elle est déjà significativement différente de ce qui a été publié.

Traitement des données : Certains scripts et modèles de data science font partie du leak mais sans les données pour entraîner ces modèles ou alimenter ces scripts, ils n’ont que peu de valeur. L’« algorithme de consensus » faisait aussi partie du leak, mais nous avions déjà expliqué très clairement comment il a été conçu. L’idée de l’open sourcer nous a également effleuré plusieurs fois, mais, pour les mêmes raisons énoncées plus haut, nous avions renoncé à le faire. Est-ce que le Consensus (l’algorithme qui ajoute des adresses IP aux blocklists) peut être empoisonné ou compromis ? De notre point de vue et de notre compréhension de notre propre système, non. L’algorithme nécessite des dizaines de signalements provenant de dizaines de security engines vérifiés, répartis sur des dizaines d’Autonomous Systems différents. Ce qui n’était pas public, ce sont principalement les seuils que nous avons fixés pour la diversité et le nombre de détections avant de considérer une IP comme dangereuse. Même si ces “poids” sont ajustés régulièrement. Il faudrait un attaquant motivé, disposant d’une importante somme d’argent, pour instancier suffisamment de serveurs afin d’influencer le réseau et bannir une IP non fautive. La différence, c’est qu’avant ce leak, l’attaquant ne savait pas exactement combien ; maintenant, les seuils sont connus. Nous pouvons les ajuster (comme nous le faisons fréquemment) et rester très vigilants quant aux écarts par rapport à la norme, mais l’effet de réseau et sa taille font que les variations statistiques sont très visibles sur notre radar, puisque la « moyenne » est très solide.

Scripts d’automatisation divers : Ce point couvre de nombreux scripts et contenus satellites. Des automatisations de robots Slack fournissant des statistiques ou des rappels, des sites pour publier des news ou du contenu, des scripts de déploiement pour les tests, la QC, la QA, etc. Les détails sont extrêmement ennuyeux, mais en résumé : aucune valeur, aucun risque pour les utilisateurs, les clients, le réseau ou l’intégrité des données, c’est essentiellement de la “plomberie digitale”.

Credentials : Nous étions très proches de zéro leak ici. Le seul identifiant utile qui a fuité était un token pour utiliser un service AWS appelé SNS, correctement scopé (dans notre jargon, limité au strict minimum en termes de droits). Techniquement « vivant » et utilisable, mais uniquement pour envoyer des notifications simples. Quelques autres tokens (très peu) étaient soit déjà remplacés, soit inutilisables via Internet.

Données : Ce n’est pas seulement critique pour la sécurité des clients, mais constitue également une violation du RGPD. Il n’y avait aucune information sur les clients ou partenaires dans le leak, à l’exception de 83 adresses e-mail utilisées spécifiquement par notre équipe Data Science pour suivre l’usage des projets, les réactions des utilisateurs à de nouvelles fonctionnalités ou des raisons statistiques. Cela reste peu, comparé aux ~150K utilisateurs (<0,05%), et nous ne parlons que de l’adresse e-mail (essentiellement des e-mails génériques). Ces adresses ne proviennent pas d’un accès à une base de données mais d’un extrait analysé localement. Nous avons contacté les utilisateurs concernés pour leur expliquer la situation, mais cela n’affaiblira pas leur posture de sécurité, les cybercriminels savent juste qu’ils utilisent CrowdSec. Nous avons aussi involontairement divulgué les noms et prénoms de 51 investisseurs réels ou potentiels de 2020, leurs adresses e-mail et le contexte de l’investissement, ce que nous leur avons signalé ainsi qu’aux autorités compétentes, et ce qui est plus regrettable dans cette fuite. 

Quels sont les impacts ?

En tant que fondateur, voici mon analyse plus détaillée des impacts potentiels.

La première chose qui m’est venue à l’esprit, était un sentiment d’injustice, lié à quelque chose hors de notre contrôle, qui allait avoir un impact négatif. La réalité m’apparaît assez différente 48 heures plus tard. En premier lieu, j’ai été bluffé par la compréhension et la bienveillance sincères de notre équipe, de nos clients, de nos partenaires et de nos prestataires.

Nous avons reçu beaucoup de soutien de notre communauté, de nos partenaires, et de nos VC. Aikido, Fuitesinfos.fr et GitGuardian nous ont proposé leurs outils, et l’intervention de l’équipe de GitHub a été fondamentale pour nos recherches. Certains clients ont posé des questions légitimes, mais ils ont tous (à ce jour) compris la posture, apprécié le professionnalisme et la transparence, et attendu patiemment des réponses factuelles plutôt que hâtives.

Et… notre équipe. Ce tango où tout le monde savait quoi faire, comment, de façon synchronisée, avec des recherches, des inspections, des introspections approfondies et des questions douloureuses, c’était impressionnant. Être le dirigeant d’une startup, c’est souvent un poste solitaire, mais ressentir tous ces experts construire ensemble une réponse professionnelle à un rythme soutenu, c’était aussi un moment de fierté, qui allégeait la douleur. Quant à mon cher réseau de professionnels sur LinkedIn, alumni et amis : merci beaucoup pour votre soutien. Enfin, on n’organise pas un effort aussi intense sans une équipe aussi professionnelle.

Bien sûr, certains ont souligné : « Ils prétendent savoir qui attaque sur Internet, mais n’arrivent pas à bloquer les attaques contre eux-mêmes », sans savoir ce qu’est une supply-chain attack, d’autres ont envoyé des smileys un peu passifs-agressifs, mais une large majorité de la communauté des professionnels de la sécurité a été solidaire et compréhensive.

Ne jamais gâcher une bonne crise… Nous avons amélioré notre temps de réaction : 48h pour couvrir l’inventaire complet, la rotation des tokens, le forensic et l’opération de communication, n’est pas un échec en soi. Mais si on devait faire face à une autre crise, cette timeline fondrait à 24 h, je pense, le vrai défi ici, est principalement d’éviter que d’autres supply chain attacks ne puissent se produire.

Pour revenir à la question « à quel point est-ce grave » ? La réponse est que cet incident constitue un véritable stress-test pour notre système de réseau distribué et crowdsourcé. Par conception, il devrait être résilient à ce type d’événement, et cette épreuve du feu devrait nous le prouver. De ce que l’on sait à ce stade : la séparation stricte des privilèges, les tokens AWS scopés, et la révocation rapide de l’accès principal de l’employé parti signifient que l’attaquant a fini dans une impasse. La résilience du consensus du réseau est liée majoritairement à sa taille et son architecture plus qu’à son code en soi. 

Les experts en sécurité ne m’ont pas semblé soucieux, car ils comprennent que nous n’avons pas échoué dans notre mission, ni pris de raccourcis en matière de sécurité. Les clients peuvent se demander ce qui s’est passé, mais nous pouvons leur expliquer ce qui s’est passé. Les prospects peuvent être effrayés, mais nous vendons un produit plutôt technique, donc la plupart comprendront une fois la situation exposée. Cet incident n’est pas idéal, évidemment, mais pas fatal non plus, très loin de là.

Mais ceux pour qui nous sommes le plus sincèrement désolés, ce sont nos premiers investisseurs, qu’ils aient concrétisé ou non. Divulguer vos noms et adresses e-mail est un problème que nous allons traiter directement avec vous et les autorités compétentes, et je m’en excuse personnellement. Le système qui, en 2020, rendait les interactions avec nous plus simples n’a jamais été conçu pour être public.

Quiconque a subi un problème comme celui-ci a moins de chances de le revivre, en raison de la douleur qu’il a causée. Nous sortons donc de cette crise plus forts et plus affûtés qu’avant, avec une blessure de guerre et une autre d’ego, ce dernier point étant sans importance. Globalement, il semble que CrowdSec ne soit pas seulement un effet de réseau, mais bien une véritable communauté de professionnels solidaires, ce qui est appréciable.

Méthode de l’attaque

Le 16 septembre, un utilisateur a publié sur pwnforum une archive contenant du code source de l’organisation GitHub de CrowdSec, comme relayé par https://fuitesinfos.fr/article/2026-09-16-crowdsec

Pour situer les faits : une fois que Christophe de https://fuitesinfos.fr/ nous a donné l’information et l’archive, on a pu constater que celle-ci contenait crowdsec-ghsa-273h-gvwr-c3qj, un dépôt qui a été détruit le 27 mai. Le dernier commit présent dans tous les dépôts date du 22 mai 2026 à 01 h 24 UTC, et le timestamp de l’archive est fixé au 22 mai ; ça correspond.

À ce stade, nous suspectons, avec un fort degré de confiance, que le leak est limité au code source de CrowdSecurity (dont 130+ des dépôts sur 300 étaient publics). L’infrastructure ou les bases de données de CrowdSec n’ont pas été accédées ou compromises. Aucun code n’a été altéré, ni dans le logiciel open source, ni dans notre code source privé, ni dans les pipelines de build, c’était de la “lecture uniquement”.

Notre infrastructure AWS est serverless et nous utilisons largement SSM/Secrets Manager, donc le nombre de credentials présents est très faible, mais cela requiert une analyse. La plupart des tokens et secrets avaient été révoqués ou remplacés, mais celui qui était présent et viable a été sondé :

Le dump incluait un secret AWS assertible-zapier-sns-sender, et quelqu’un a tenté de l’utiliser le 17 août 2026 depuis l’IP 23.234.84.102 pour effectuer un GetCallerIdentity et un ListTopics à la fois sur les topics dev et env. Ce rôle AWS était restreint à publier sur un seul topic SNS ; il n’a pas pu aller plus loin.

L’archive .github/.git/config contient l’origine utilisée pour cloner les dépôts :

...
[remote "origin"]
	url = https://oauth2:gho_xxxxxxxxx@github.com/crowdsecurity/.github.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
	remote = origin
	merge = refs/heads/main

Ceci nous indique que le token utilisé pour cloner les dépôts est un token OAuth (gho_xxx) ce qui semble réel car son checksum est correct [2]. La méthodologie est également alignée sur les tactiques du groupe de cybercriminels TeamPCP et sur son malware (Mini) Shai-Hulud.

Cependant, nous ne trouvons aucune trace de ce token OAuth dans le journal d’audit de notre organisation, ni dans les journaux d’audit des membres actuels de notre organisation GitHub. Nous  avons téléchargé ces journaux depuis l’interface web et recherché la version hachée du token (echo -n $token | openssl dgst -sha256 -binary | base64), sans succès.

Nous avons aussi passé au peigne fin la liste des intégrations OAuth actives dans l’organisation (en mode « Accès restreint ») mais elle ne contenait rien de suspect non plus. Aucune des intégrations n’a subi de breach public dans la période concernée.

Si c’était le jeton OAuth d’un utilisateur actif, on s’attendrait à voir une activité associée dans le journal d’activité. D’un autre côté, le journal d’audit de GitHub ne suit que des actions spécifiques [2.1], et seuls les plans entreprise (que nous n’avions pas) conservent l’activité git sur une fenêtre glissante de 7 jours.

[2] https://github.blog/engineering/platform-security/behind-githubs-new-authentication-token-formats/
[2.1] https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization

La vraie complexité derrière cette analyse forensique, réside dans le fait que le token utilisé pour télécharger les dépôts privés n’existait plus quand nous avons eu connaissance de la fuite du code. Il a donc été créé, a vécu, et est mort sans laisser de traces au-delà de son usage. 

À ce stade de l’investigation, nous ne connaissions toujours pas l’origine de la compromission. Après avoir vérifié les tokens des utilisateurs et scanné les packages malveillants, les extensions de VS Code, etc., les machines de tous les développeurs sont officiellement propres. 

Nous avons enquêté sur l’historique Git de nos propres dépôts pour voir si certains packages backdoorés avaient touché nos dépôts à un moment donné, mais ça n’a rien donné de concluant. Bien que certains packages TanStack soient présents, aucun n’est sur la liste backdoorée. Par ailleurs, nous imposons un âge minimum aux packages Node afin d’éviter qu’une compromission récente ne passe sous le radar.

Cependant, une chose qui nous intriguait, c’est que TeamPCP est connu pour ne pas se limiter aux identifiants GitHub, mais aussi pour rechercher d’autres tokens, comme les identifiants AWS, les clés SSH, etc. Alors que GitHub donne très peu de visibilité sur l’activité Git, nous avons une bonne visibilité sur les actions AWS, et rien de suspect ne s’est produit depuis les attaques de supply chain ou depuis que les identifiants du leak ont été sondés.

C’est là que le support de GitHub a été inestimable car ils ont pu retracer le cycle de vie complet du token dont nous n’avions que la trace d’usage et confirmer nos suspicions initiales concernant TanStack.

Avec le token OAuth et un créneau temporel précis pour l’activité, nous les avons contactés afin d’obtenir davantage d’informations. Ils ont pu nous fournir l’activité Git dans la fenêtre de 2 heures du dump. On a alors découvert qu’il s’agissait d’un employé qui venait juste de quitter l’entreprise, mais qui faisait toujours partie de l’organisation GitHub pour des raisons légitimes, et son compte a été utilisé pour dumper les dépôts :

2026-05-22 05:52:32.138 UTC – fetch – crowdsecurity/XYX – <redacted> – 178.249.214.XX

D’après les informations Git dans l’archive leakée, l’IP du cybercriminel se situe à Toronto, Canada, en zone horaire UTC-4. L’ex-employé a été compromis par l’attaque de supply chain TanStack, ce qui correspond à la méthodologie. Son compte a été retiré de l’organisation GitHub le 25 mai 2026, 3 jours après l’incident…

Ceci explique également pourquoi nous n’avons repéré aucune activité liée à AWS ou à l’infrastructure, puisque ses accès avaient déjà été révoqués.

Après avoir identifié la source et poussé davantage l’audit de l’activité Git de l’utilisateur et des comptes existants, nous pouvons confirmer que son accès a été utilisé uniquement pour effectuer les clones Git qui ont mené au leak et qu’aucune altération du code, de l’infrastructure, ou du pipeline de CI/CD n’a eu lieu.

Quelles actions ont été prises pour éviter tout nouvel incident

CrowdSec avait déjà de nombreux mécanismes de sécurité avant cet incident :

• Séparation stricte des privilèges (par exemple, en tant que CEO, je n’ai aucun accès aux comptes bancaires, aux outils d’admin de l’organisation, à la console AWS, etc., et c’est une bonne pratique appliquée à toutes et tous)
• Scoping strict : ce qui s’applique aux droits utilisateurs s’applique tout autant aux apps, accès API, IA, aux routines cloud, et aux scripts, pour éviter d’accorder un droit au-delà de ce qui est strictement nécessaire pour remplir leur rôle
• 2FA sur chaque outil pour tout le monde, avec passkeys et dispositifs physiques (Titan Key)
• Password wallet : évident, mais explicitement obligatoire
• Phrases de sécurité : si un membre clé de l’organisation avec des droits étendus est physiquement compromis (ou sa famille), nous avons convenu de mots spécifiques à glisser dans la conversation pour alerter notre interlocuteur de la compromission
• Audits : qu’ils soient internes, menés par IA, ou externes, ils font partie de notre hygiène
• Logs partout : durant cette crise, nous avons appris que l’archivage plus poussé des actions GitHub nous aurait fait gagner du temps, mais les logs de nos toolchains, composants CI/CD, et AWS étaient très solides. Avoir des traces permet de remonter le fil et de réagir tôt, et après tout, on est CrowdSec, donc plutôt sensibles sur le sujet
• Pentesting : À quelle fréquence les lancer, sous quelle forme, tout ça évolue dans le temps, mais tester les employés de l’entreprise et notre code source fait partie de nos habitudes
• Monitoring de l’âge des packages NPM : pour s’assurer qu’on ne tourne pas sur une version trop récente pour être auditée, ou trop ancienne pour comporter un risque de sécurité.
• Procédures d’onboarding/deboarding : le cycle de vie complet de vie des accréditations d’un employé, création et révocation (ou savoir pourquoi vous avez gardé). La conservation de toutes les traces d’usage une fois qu’il est parti compte encore plus.
• Analyse automatisée du code : chaque commit est scanné automatiquement pour détecter d’éventuelles vulnérabilités ou failles logiques
• Procédures et revues de publication, QA & QC : qu’elles soient automatisées ou manuelles, ce sont des composants classiques de la boîte à outils d’un éditeur
• Formation, et bien plus encore…

Pourtant, rien de tout ça n’a pu empêcher une attaque de chaîne d’approvisionnement, alors qu’est-ce qui aurait pu ?

EDR : Au moment de l’incident, on n’imposait pas d’EDR sur les machines des développeurs, mais on utilise depuis une protection endpoint qui se concentre activement sur les packages malveillants, les extensions, etc. Alors que les attaques de la chaîne d’approvisionnement deviennent le nouveau fléau et que virtuellement n’importe qui peut se retrouver dans le viseur, cette ligne de défense supplémentaire pourrait peut-être aider dans certains cas.

Les postes de travail/laptops des personnes interagissant avec notre code source ou notre infrastructure tournent maintenant sous un EDR pour réduire le risque d’attaques de supply chain, mais une analyse en mémoire et un monitoring runtime pourrait aussi couvrir les 0-days.