CrowdSec attribue le vol de 300 dépôts GitHub à une dépendance TanStack malveillante

Des attaquants ont accédé à du code privé par l’intermédiaire d’une dépendance logicielle

L’entreprise française de cybersécurité CrowdSec a confirmé que des attaquants avaient exfiltré le code source d’environ 300 de ses dépôts GitHub, dont quelque 170 dépôts privés.

L’entreprise a appris la semaine dernière que le vol avait eu lieu en mai 2026. Son enquête a établi un lien entre l’intrusion et la campagne visant la chaîne d’approvisionnement logicielle de TanStack, attribuée à TeamPCP, qui a distribué 84 artefacts malveillants au moyen de 42 packages TanStack.

CrowdSec estime qu’un malware distribué par l’intermédiaire d’un package compromis a récupéré une clé API capable de lire son code privé. Cet identifiant aurait permis aux attaquants de copier des dépôts publics et privés, sans qu’une compromission distincte de l’infrastructure de production principale de CrowdSec soit nécessaire.

Le code privé dérobé concernait la console SaaS de CrowdSec, certaines routines AWS Cloud, des connecteurs et des composants d’automatisation. Selon le récit de l’enquête publié par CrowdSec, les enquêteurs n’ont trouvé aucun élément indiquant que des identifiants clients ou d’autres informations liées aux clients avaient été exposés.

Pour l’heure, l’entreprise évalue l’impact direct comme interne.

Le chemin présumé entre l’installation du package et l’accès à GitHub

CrowdSec a utilisé un package TanStack en mai 2026, lorsque les artefacts malveillants étaient actifs. Selon l’hypothèse de travail de l’entreprise, du code exécuté depuis la dépendance compromise a récupéré une clé API dans son environnement de développement.

Une clé API disposant d’autorisations de lecture des dépôts peut offrir à un attaquant agissant sur la chaîne d’approvisionnement un accès direct au code propriétaire. Plutôt que d’exploiter chaque dépôt séparément, l’attaquant peut utiliser l’identifiant de confiance pour énumérer et télécharger tous les projets accessibles à cette identité.

Cela semble expliquer l’ampleur du vol : environ 300 dépôts ont été concernés, dont plus de la moitié étaient privés. Les informations disponibles ne permettent pas d’établir si chaque dépôt a été téléchargé dans son intégralité ou si les attaquants ont sélectionné certains fichiers dans certains projets.

Plusieurs détails techniques restent inconnus. CrowdSec n’a pas identifié le package TanStack exact ni la version utilisée, et n’a pas publié les autorisations précises de la clé API, les événements d’audit GitHub pertinents ou d’autres indicateurs de compromission. Aucun nom de fichier malveillant, aucune empreinte, aucun domaine ni aucune adresse réseau n’a été communiqué.

L’entreprise a décrit la période d’exposition probable comme une courte fenêtre en mai 2026. Dès qu’elle a identifié le risque, elle a renouvelé tous les tokens et identifiants susceptibles d’avoir été concernés.

Ce que contenaient les dépôts dérobés

Les dépôts privés comprenaient du code prenant en charge quatre domaines importants des activités de CrowdSec :

• La console SaaS de CrowdSec ;
• Certaines routines AWS Cloud ;
• Les connecteurs utilisés pour relier des systèmes ou des services ;
• Les fonctionnalités d’automatisation internes.

Il ne s’agit pas d’une divulgation confirmée de bases de données clients, de mots de passe, de tokens d’accès ou de données de production. CrowdSec a recherché dans les éléments concernés et dans son environnement d’éventuels identifiants, clés API, tokens et autres secrets susceptibles de faciliter un déplacement latéral. L’entreprise a indiqué que ces recherches n’avaient pas permis d’identifier de tels éléments à ce stade.

Cette distinction est importante, mais l’exposition de code source entraîne malgré tout des travaux de sécurisation. Les attaquants peuvent examiner du code propriétaire à la recherche de faiblesses d’implémentation, d’interfaces non documentées, d’hypothèses liées au cloud, de conventions de nommage internes et d’une logique susceptible de faciliter de futures tentatives d’intrusion. Même lorsque les secrets ne sont pas intégrés volontairement, des fragments de configuration, des jeux de données de test, l’historique des commits et des scripts d’automatisation peuvent révéler des détails opérationnels.

CrowdSec estime que le code copié ne peut pas être facilement exécuté en dehors de son environnement d’origine. Reproduire les services de l’entreprise nécessiterait son réseau, ses données, ses outils et son infrastructure de support. Le fournisseur a également indiqué que le code SaaS faisait l’objet d’audits réguliers et qu’une grande partie des éléments divulgués avait été sensiblement modifiée au cours des quatre mois précédents.

Ces facteurs peuvent réduire l’exploitabilité immédiate. Ils ne rendent pas le vol négligeable pour autant.

Aucun accès non autorisé aux données clients n’a été identifié

CrowdSec n’a trouvé aucun élément indiquant que les attaquants avaient obtenu des identifiants clients ou d’autres informations liées aux clients. L’entreprise n’a pas non plus signalé que TeamPCP avait utilisé le code dérobé pour accéder à des déploiements clients, à des ressources cloud ou à la plateforme SaaS de production.

L’évaluation actuelle est donc plus limitée que ne pourrait le laisser penser le nombre de dépôts concernés : la propriété intellectuelle de CrowdSec a été exposée, mais aucune compromission de données clients n’a été établie.

Cette conclusion pourrait évoluer si une analyse ultérieure révélait des identifiants ayant échappé aux premières recherches ou détectait une activité suspecte liée aux informations contenues dans le code. Les enquêtes portant sur le code source peuvent prendre du temps, car des secrets peuvent se trouver dans d’anciens commits, des branches archivées, des fichiers générés ou des journaux de compilation, plutôt que dans la version actuelle d’un projet.

CrowdSec a indiqué qu’elle continuerait à surveiller les comportements anormaux. L’entreprise n’a communiqué aucun élément attestant une exploitation ultérieure, une tentative d’extorsion, une publication des dépôts ou des tentatives d’armer des vulnérabilités découvertes dans le code dérobé.

Aucun identifiant CVE, score CVSS ou niveau de gravité officiel ne s’applique à l’incident tel qu’il est décrit. Il ne figure pas non plus dans le catalogue des vulnérabilités exploitées connues de la CISA. Il s’agit d’une compromission de la chaîne d’approvisionnement facilitée par un identifiant, et non d’une vulnérabilité divulguée faisant l’objet d’un correctif du fournisseur et d’un tableau des versions concernées.

Une réponse axée sur les identifiants et le risque de déplacement latéral

La première mesure de confinement prise par CrowdSec a consisté à renouveler tous les tokens et identifiants potentiellement concernés. Cette action était nécessaire, car l’accès initial présumé impliquait une clé API et non une faille logicielle qui aurait pu être corrigée par la seule installation d’une mise à jour.

L’entreprise a également recherché les éléments sensibles susceptibles de permettre à l’attaquant d’aller au-delà de l’accès aux dépôts. Les enquêteurs ont examiné les dépôts compromis ainsi que le code prenant en charge la console SaaS, les routines AWS, les connecteurs et les automatismes.

La réponse en cours comprend notamment :

1. La surveillance des activités inhabituelles associées aux identités et aux environnements concernés ;
2. L’examen des dépôts privés à la recherche de secrets intégrés ou historiques ;
3. L’évaluation des informations qu’un code exposé pourrait révéler sur des moyens d’accès aux systèmes cloud ou de production ;
4. Le maintien des audits du code source de la plateforme SaaS ;
5. La recherche d’éventuels déplacements latéraux à partir de l’identifiant de développement compromis.

CrowdSec n’a pas signalé avoir découvert de déplacement latéral. Toutefois, l’absence d’identifiants détectés dans les fichiers source actuels ne suffit pas à exclure une exposition par l’intermédiaire de l’historique des dépôts ou de systèmes de développement associés.

Ce que les utilisateurs de TanStack et les équipes de développement doivent examiner

Les organisations qui ont utilisé des packages TanStack pendant la fenêtre d’exploitation de mai 2026 doivent vérifier la provenance des packages et examiner l’historique des dépendances, des fichiers de verrouillage, des compilations et des installations. Les noms et versions des packages compromis utilisés par CrowdSec n’ayant pas été divulgués, les défenseurs ne peuvent pas s’appuyer sur un indicateur propre à CrowdSec.

Les équipes doivent recenser les identifiants accessibles aux scripts d’installation des packages, aux agents de compilation, aux postes de travail des développeurs et aux tâches d’intégration continue. Tout token exposé à ces environnements doit être évalué en fonction de ses autorisations et renouvelé dès lors qu’une compromission ne peut pas être exclue.

Les administrateurs GitHub doivent rechercher des opérations inhabituelles d’énumération, de clonage, de téléchargement d’archives ou d’utilisation de l’API impliquant des identités de développement et d’automatisation. Les équipes cloud doivent également vérifier si le code des dépôts ou les systèmes de compilation contenaient des identifiants capables d’accéder à des ressources AWS ou à d’autres infrastructures.

Pour les organisations qui intègrent CrowdSec, rien n’indique actuellement que les identifiants ou les informations clients du fournisseur aient été dérobés. Les clients ne doivent pas considérer l’incident comme la preuve d’une compromission de leurs propres environnements. Ils doivent néanmoins rechercher toute activité d’authentification ou d’utilisation de l’API inattendue si leurs déploiements partageaient des identifiants avec des workflows de développement concernés.

L’incident illustre la portée que peut avoir une dépendance malveillante : un seul package compromis peut hériter des accès disponibles dans l’environnement qui l’exécute. Dans le cas de CrowdSec, le résultat présumé a été la récupération d’une clé API et l’accès à des centaines de dépôts. La question reste de savoir si le code dérobé peut aider TeamPCP — ou une autre partie qui l’obtiendrait — à aller au-delà du vol de propriété intellectuelle.