if ( !emtpy($headline_subheadline ) ) : ?>
Les protections de sécurité sur GitHub n’ont pas été violées, mais les protections individuelles des clients l’ont été, et les agents de codage autonomes ont joué un rôle.
endif; ?>
Une société de recherche en sécurité a rapporté lundi avoir identifié des violations de 42 référentiels GitHub tiers dans lesquels les attaquants avaient déployé des blobs de charge utile suffisamment volumineux « pour échapper aux recherches GitHub et aux chemins API normalement utilisés pour trouver ce type de compromission ».
Le rapport de JFrog Security Research indique que les référentiels victimes contenaient des crochets d’exécution pour les assistants de codage d’IA et les IDE, ainsi que des wrappers polymorphes pouvant atteindre 13,7 Mo qui « tous décodés vers la même charge utile cachée de l’éditeur CI. Le référentiel appartenant à l’attaquant de la campagne fonctionne également comme un récepteur de données crypté actif, recevant des enveloppes d’instantanés, et l’attaque a exploité un nouveau camouflage : un module complémentaire natif compilé qui ne contient aucune charge utile propre et décrypte à la place un fichier. nommé au moment de l’exécution pour révéler le vrai.”
JFrog a déclaré que l’enquête a également révélé des détournements de comptes, des délais de validation falsifiés, des branches de publication de courte durée et des informations d’identification NPM exposées. Les artefacts Shellpanel dans le même cluster propriétaire piraté relient cette infrastructure victime GitHub à l’exploitation des actions GitHub précédemment signalée des systèmes cPanel accessibles sur Internet.
« Le 21 octobre, nos scanners nous ont alertés des packages shai-hulud trouvés dans l’écosystème npm », a écrit JFrog. « L’analyse de SafeDep du 22 octobre a d’abord documenté le côté npm/package de cette activité et décodé. SafeDep a décrit la charge utile comme étant de la famille Miasma tout en notant explicitement l’incertitude quant à sa lignée. »
SafeDep pensait à l’origine que les packages de la campagne qu’il avait découvert, baptisée testmetest, n’étaient qu’un test effectué par l’acteur menaçant, mais cette semaine a découvert les compromissions des dépôts existants avec du contenu malveillant.
L’article de JFrog s’est également concentré sur les implications de la chaîne NPM.
« La chaîne npm fournit le lien vers l’opération plus large. Les versions malveillantes de testmetest utilisaient une extension de commande pour s’exécuter lors de l’installation, même si les packages ne déclaraient pas de script d’installation conventionnel », indique le message. « Le chargeur a appliqué une transformation César par build à un tableau de codes de caractères, a déchiffré une étape AES-128-GCM et a localisé ou téléchargé Bun 1.2.18. En fonction de la build, la charge utile déchiffrée a été redirigée vers ou écrite vers un serveur temporaire. .b-*répertoire et supprimé après exécution. La charge utile NPM complète a collecté les informations d’identification, les référentiels empoisonnés et la configuration CI, et s’est propagée via les registres de packages.
Ces référentiels contrôlés par les attaquants ont servi de sources de projets de couverture pour les packages npm correspondants, a déclaré JFrog.
« Des versions malveillantes ont livré le ver npm, qui a volé les informations d’identification GitHub et npm qui pourraient donner accès à des référentiels tiers. Dans les référentiels piratés, la campagne a laissé des espaces réservés aux tests de fumée ou des charges utiles armées », ont écrit les chercheurs. « Décoder les fichiers armés exposés par les éditeurs conçus pour s’exécuter via les actions GitHub et utiliser des jetons npm ou des publications fiables pour produire d’autres versions de testmetest malveillantes, alimentant ainsi la livraison des packages dans la compromission du référentiel. »
Recommandations défensives
Le message de JFrog recommandait diverses tactiques défensives pour détecter et atténuer ces attaques, notamment que les RSSI « devraient considérer l’installation d’une version complète du ver comme une compromission de l’hôte ». Il a également suggéré aux utilisateurs de révoquer et de faire pivoter tous les identifiants GitHub, GitLab, npm, PyPI, RubyGems, cloud, SSH, Vault, Kubernetes et des fournisseurs d’IA, ainsi que d’auditer « tous les référentiels accessibles aux identités concernées pour , , json, , , hooks d’exécution inattendus ou Makefile et validations.
JFrog a également suggéré que les entreprises énumèrent directement les arborescences des référentiels et que le service informatique ne devrait pas s’appuyer sur la recherche de code GitHub ou sur l’API de contenu, en raison du problème de taille du wrapper.
« Supprimez les branches non autorisées, désactivez les flux de travail malveillants et supprimez les faux artefacts nommés . Block et l’infrastructure malveillante associée au niveau des contrôles du réseau » et « recherchez les journaux et les coureurs d’actions GitHub pour , ipscan, CVE-2026-41940, les requêtes spécifiques à l’architecture et les analyses inhabituellement larges des coureurs hébergés ou auto-hébergés », a suggéré JFrog. Et. Bien sûr, cherchez .
Cible hautement prioritaire
La popularité des référentiels GitHub va probablement continuer à en faire une cible prioritaire pour les attaquants.
Aman Mahapatra, directeur de la stratégie de la société de conseil en technologie Tribeca Softech, basée à New York, a déclaré que les détails de cette attaque prédisent probablement l’évolution de nouvelles attaques axées sur l’IA dans un avenir immédiat.
«Pendant une décennie, le modèle de menace de la chaîne d’approvisionnement supposait qu’un code malveillant s’exécutait lorsque vous installiez ou exécutiez quelque chose», a-t-il déclaré. « Cette campagne installe un hook Claude Code SessionStart, des paramètres Gemini, une configuration et des règles Cursor MCP et des tâches d’ouverture de dossier VS Code, de sorte que la charge utile s’exécute lorsqu’un développeur ouvre simplement le référentiel dans son outil. C’est le nouveau. »
« Les attaquants ont déplacé le déclencheur de l’exécution de code vers l’ouverture d’un dossier, ont créé des logiciels malveillants qui se cachent des bacs à sable dès leur conception et ont transformé le dernier correctif de l’industrie en cible suivante », a déclaré Mahapatra. « La défense de la chaîne d’approvisionnement, construite autour de l’analyse au moment de l’installation, protège désormais le mauvais moment. »
Il s’est dit particulièrement préoccupé par la tactique de taille des fichiers utilisée par les attaquants.
« Les wrappers de 13 Mo ajoutent une astuce plus grossière. Ils dépassent ce que les index de recherche de code GitHub et ce que renvoie l’API de contenu, c’est pourquoi les premières analyses ont trouvé les hooks et ont conclu que les fichiers de charge utile étaient vides », a déclaré Mahapatra. « L’attaquant a lu la documentation de vos outils de détection et a complété le fichier au-delà de ses limites. »
Frank Dickson, analyste principal chez Dickson Research, s’est dit également impressionné par l’utilisation par l’attaquant d’un module complémentaire natif.
« Il ne transporte aucune charge utile propre et refuse de s’exécuter dans des systèmes CI, des conteneurs, de petites machines virtuelles ou sous un débogueur », a-t-il déclaré. « Sous Windows, il s’arrête également si Wireshark ou Process Monitor est en cours d’exécution. Les scanners voient un espace réservé mais l’ordinateur portable du développeur obtient la réalité. »
Dickson a déclaré que l’élément de risque lié à l’IA existe, mais qu’il s’agit d’une exposition secondaire qui ne pose problème qu’une fois que les attaquants ont volé les informations d’identification actives. Pourtant, la situation est pire à cause des efforts des agents.
« Les fichiers implantés sont des crochets d’exécution pour Claude, Gemini, Cursor et VS Code. L’ouverture d’un projet dans un outil pris en charge peut exécuter la charge utile. Une action de routine du développeur devient le détonateur. L’ordinateur portable d’un développeur détient les clés du royaume si vous voulez : les jetons GitHub, les jetons npm, les clés cloud et les informations d’identification du fournisseur d’IA. Les attaquants ont trouvé une nouvelle façon de les demander », a déclaré Dickson. « Pour être honnête, ces hooks sont des fonctionnalités, pas des défauts. La cause première ici est le vol d’informations d’identification, pas les outils d’IA. Néanmoins, une fonctionnalité qui exécute du code lorsqu’un dossier s’ouvre mérite le même examen minutieux qu’un script de construction. «
