Le 20 mai 2026, GitHub a confirmé avoir été victime d’une intrusion qui s’est soldée par l’exfiltration d’environ 3 800 dépôts internes. L’incident est sérieux, mais le détail qui mérite vraiment qu’on s’y arrête est ailleurs : le point d’entrée n’a été ni une faille zero-day, ni une attaque sophistiquée contre l’infrastructure. C’est une extension Visual Studio Code malveillante, installée par un employé sur son propre poste, qui a ouvert la porte. 🔒
Ce qui s’est passé chez GitHub : les faits
L’attaque a été détectée le 19 mai par l’équipe de sécurité de GitHub, puis confirmée publiquement le 20 mai. Le groupe revendiquant l’opération s’appelle TeamPCP — le même collectif que Google Threat Intelligence Group suit sous le nom d’UNC6780, et qui a déjà été lié à plusieurs attaques récentes sur la chaîne d’approvisionnement logicielle (Checkmarx, SailPoint, Grafana Labs, ainsi que la campagne npm « Mini Shai-Hulud »).
GitHub indique que la compromission s’est limitée à ses dépôts internes : aucun dépôt client, aucune donnée personnelle d’utilisateur n’aurait été affectée. Les ~3 800 dépôts revendiqués par les attaquants sont décrits comme « globalement cohérents » avec l’estimation interne de GitHub. Les données sont actuellement mises en vente sur un forum cybercriminel, avec un prix plancher de 50 000 dollars.
À l’heure où j’écris ces lignes, GitHub n’a pas encore communiqué le nom précis de l’extension VS Code incriminée. C’est un point important : sans cette information, on ne peut pas dire si l’attaque a exploité une extension obscure ou une extension populaire dont le compte éditeur aurait été compromis. Les deux scénarios existent et ont des implications différentes.
L’extension VS Code : un vecteur trop puissant pour un contrôle aussi léger
C’est le cœur du sujet. Une extension VS Code, contrairement à ce qu’on imagine, n’est pas un petit script confiné à l’éditeur. Une fois installée, elle peut typiquement lire et écrire l’intégralité du système de fichiers accessible à l’utilisateur, exécuter des commandes dans le terminal intégré, accéder aux secrets stockés localement (~/.aws/credentials, ~/.ssh/, ~/.kube/config, fichiers .env), intercepter les variables d’environnement, et communiquer avec n’importe quel serveur distant.
C’est l’équivalent fonctionnel de donner un shell à un inconnu sur sa machine de développement. Pour quelqu’un qui travaille sur des projets cloud, cela signifie une exposition directe aux clés AWS, aux service principals Azure, aux tokens GitHub personnels, aux certificats de signature. 🛡️
Le marketplace : modération réactive, pas préventive
Le marketplace VS Code suit le modèle de la plupart des stores : une extension est publiée, elle reste disponible, et la modération intervient principalement après signalement. Trois mécanismes de compromission reviennent régulièrement : le typosquatting (Pretier au lieu de Prettier), la mise à jour silencieuse (une extension légitime pousse une version malveillante après avoir gagné en confiance), et le compte éditeur compromis (phishing d’un développeur reconnu).
Ce n’est pas un problème spécifique à Microsoft ou à VS Code : le même schéma touche npm, PyPI, le Chrome Web Store, le Marketplace JetBrains. Le défi est commun à tous les écosystèmes ouverts, et c’est précisément parce que ces écosystèmes sont ouverts qu’ils ont la valeur qu’on leur connaît. Cela dit, les entreprises gagneraient à regarder ce sujet de plus près plutôt que de laisser leurs développeurs installer librement n’importe quelle extension sur des postes ayant accès à du code propriétaire et à des secrets de production.
Ce qu’un développeur peut faire concrètement
Quelques réflexes simples, qui ne coûtent rien à mettre en place :
- Auditer la liste de ses extensions installées — la plupart d’entre nous en cumulent des dizaines, dont beaucoup ne servent plus.
- Vérifier l’éditeur et le nombre de téléchargements avant d’installer. Une extension à quelques centaines de téléchargements méritent un coup d’œil au repo source.
- Isoler les environnements sensibles : devcontainers, WSL, machines virtuelles dédiées. Si l’extension tourne dans un container, elle ne voit pas le
~/.awsde votre poste hôte. - Ne pas laisser traîner les secrets en clair dans les fichiers de config locaux. Un gestionnaire de secrets (1Password CLI, doppler, vault, …) ferme une bonne partie de la fenêtre.
Et l’IA dans tout ça ?
C’est le sujet du moment, et il serait tentant de l’invoquer ici aussi. La réalité est plus prosaïque : dans cette affaire, l’IA n’a joué aucun rôle. Aucun modèle n’a halluciné une dépendance, aucun agent autonome n’a été détourné. Un humain a installé une extension, et la chaîne s’est cassée à ce maillon là. 🤖
C’est sans doute le vrai enseignement de cet incident : pendant qu’on cherche les nouvelles surfaces d’attaque générées par l’IA, les anciennes — celles qui dépendent d’un clic sur « Install » — restent largement ouvertes. 😉
