Des milliers de messages identiques, postés en quelques minutes sur des centaines de dépôts. Chacun affiche un titre alarmant, un faux identifiant de vulnérabilité et un lien de téléchargement qui ne mène pas où il prétend. Depuis le 26 mars, une campagne de phishing d’une ampleur inhabituelle cible les développeurs directement à l’intérieur de GitHub, en détournant un mécanisme que la plateforme n’a jamais conçu comme un canal de sécurité : les Discussions.
Le piège se cache dans les notifications
Le principe repose sur un abus systématique de la section Discussions de GitHub. Les attaquants y publient de fausses alertes de sécurité concernant Visual Studio Code, l’éditeur de code utilisé par des dizaines de millions de développeurs dans le monde. Les titres imitent les véritables bulletins de vulnérabilité : « Severe Vulnerability, Immediate Update Required », « Critical Exploit, Urgent Action Needed ». Chaque message cite des identifiants CVE inventés de toutes pièces et presse le lecteur d’installer une version prétendument corrigée de l’extension concernée.
La société de sécurité applicative Socket, qui a publié le rapport technique initial, décrit une opération coordonnée et non un incident isolé. Les messages apparaissent par milliers en l’espace de quelques minutes, postés depuis des comptes fraîchement créés ou inactifs depuis des mois. Pour renforcer la crédibilité, les auteurs usurpent l’identité de mainteneurs de projets ou de chercheurs en sécurité connus.
Le détail décisif tient au système de notifications de GitHub. Quand une Discussion est ouverte sur un dépôt, les participants et les utilisateurs qui suivent le projet reçoivent un e-mail. L’alerte atterrit dans leur boîte de réception comme si elle venait directement de la plateforme, pas d’un obscur forum. BleepingComputer, qui a corroboré l’analyse de Socket, souligne que cette mécanique amplifie la portée bien au-delà de GitHub lui-même.
Google Drive comme faux tampon de confiance
Les liens inclus dans chaque fausse alerte redirigent vers Google Drive, où se trouverait la version corrigée de l’extension VS Code. Le choix n’est pas anodin. Google Drive est un service de confiance que beaucoup de développeurs utilisent au quotidien. Un développeur pressé, qui vient de recevoir une notification urgente dans sa messagerie et reconnaît un domaine Google, peut cliquer sans vérifier davantage.
Sauf que les mises à jour légitimes de VS Code ne transitent jamais par un service de partage de fichiers. Elles passent par le Marketplace officiel de Microsoft ou par les canaux intégrés à l’éditeur. Ce décalage est le premier signal d’alerte, mais dans l’urgence fabriquée par les attaquants, il passe souvent inaperçu.
Une chaîne de redirection en plusieurs étapes
Ce qui se passe après le clic révèle un dispositif plus sophistiqué qu’un simple lien piégé. L’analyse de Socket détaille une chaîne de redirection en cascade. Le point d’entrée Google redirige différemment selon que le navigateur possède ou non un cookie Google (ce qui est le cas de la quasi-totalité des développeurs connectés à leur compte). Les requêtes avec cookie sont renvoyées vers un domaine externe contrôlé par les attaquants, tandis que les requêtes sans cookie, typiques des robots d’analyse, reçoivent une page de fingerprinting directe.
Sur le domaine final, un script JavaScript obfusqué entre en action. Il collecte le fuseau horaire de la victime, son user agent, son système d’exploitation, la présence éventuelle d’un webdriver (un indicateur d’automatisation) et le hash de l’URL pour le suivi. Toutes ces données sont empaquetées et transmises silencieusement par une requête POST vers l’infrastructure de commande et contrôle. Le script utilise des techniques d’évasion comme des filtres CSS hue-rotate, des vérifications d’iframe et des chaînes de caractères mélangées dans des tableaux pour compliquer l’analyse.
Windows Report précise que les chercheurs n’ont pas réussi à capturer le malware de second niveau, ce qui suggère qu’il n’est distribué qu’à des cibles soigneusement sélectionnées après le filtrage initial. L’approche est celle d’un Traffic Distribution System, un système de tri du trafic qui permet aux attaquants de rester sous le radar tout en concentrant leurs efforts sur les victimes les plus intéressantes.
Les développeurs comme cible stratégique
Cette campagne s’inscrit dans une tendance plus large. En mars 2025, une opération de phishing avait ciblé 12 000 dépôts GitHub avec de fausses alertes de sécurité conçues pour pousser les développeurs à autoriser une application OAuth malveillante, selon BleepingComputer. En juin 2024, le groupe GitLoker avait détourné le système de commentaires et de pull requests de GitHub pour spammer les notifications avec des liens de phishing.
Le point commun de ces attaques : elles ne cherchent pas à exploiter une faille logicielle. Elles exploitent la confiance que les développeurs placent dans leur propre plateforme de travail. Un bulletin de sécurité sur GitHub ressemble à un bulletin de sécurité légitime. Un e-mail de notification GitHub est, techniquement, un vrai e-mail de GitHub. Le social engineering ne cible pas une faille humaine abstraite. Il cible un réflexe professionnel : quand une alerte de sécurité critique tombe, on applique le correctif d’abord, on pose des questions ensuite.
Les développeurs occupent une position stratégique dans la chaîne d’approvisionnement logicielle. Compromettre leur poste de travail, c’est potentiellement accéder aux clés SSH, aux tokens d’API, aux secrets de déploiement et aux dépôts privés de leurs employeurs. Un seul développeur piégé peut ouvrir la porte à une intrusion dans toute l’infrastructure d’une entreprise.
Comment vérifier avant d’agir
Face à ce type de campagne, Socket et BleepingComputer recommandent plusieurs réflexes. Premier point : ne jamais télécharger une extension VS Code depuis un service de partage de fichiers. Les mises à jour passent par le Marketplace officiel ou par l’éditeur lui-même. Deuxième point : vérifier tout identifiant CVE mentionné dans une alerte en le recherchant dans la base nationale des vulnérabilités (NVD) du NIST, dans le catalogue des vulnérabilités exploitées de la CISA, ou sur le site du programme CVE de MITRE. Si l’identifiant n’existe pas dans ces bases, l’alerte est fausse.
Troisième signal d’alerte : les mentions massives d’utilisateurs sans rapport avec le projet et les comptes récemment créés qui postent des avis de sécurité. Un véritable mainteneur publie ses avis dans les canaux officiels du projet, pas dans une Discussion ouverte taguant des dizaines d’inconnus.
GitHub n’a pas encore communiqué publiquement sur les mesures prises pour endiguer cette campagne. Socket indique que les posts devraient rapidement être supprimés, mais que le volume et l’automatisation du spam rendent le nettoyage difficile. En attendant, les développeurs qui ont cliqué sur ces liens feraient bien de vérifier leur système et de renouveler leurs tokens et clés d’accès. La prochaine campagne pourrait ne pas se contenter de collecter des données de reconnaissance.
