GitHub piraté via VS Code
environ 3 800 dépôts internes exfiltrés.

Le 18 mai 2026, GitHub détecte puis contient la compromission d’un poste utilisé par l’un de ses salariés. Le point d’entrée n’est pas une faille directe de GitHub.com : l’ordinateur a reçu une version empoisonnée d’une extension pour Visual Studio Code publiée par un tiers. À partir de cette machine de développement, l’attaquant a obtenu des accès suffisants pour exfiltrer des dépôts internes de GitHub.

Deux jours plus tard, GitHub confirme publiquement l’incident. L’entreprise indique que l’affirmation de l’attaquant portant sur environ 3 800 dépôts est « directionnellement cohérente » avec les premiers résultats de son enquête. Cette formulation est importante : GitHub ne valide pas chaque élément avancé par les pirates, mais reconnaît un ordre de grandeur proche de 3 800 dépôts internes exfiltrés.

Il ne s’agit donc pas de milliers de dépôts privés appartenant aux clients de GitHub. Les dépôts concernés sont des dépôts internes de l’entreprise, contenant du code propriétaire et des éléments de configuration. GitHub précise n’avoir trouvé aucune preuve d’un impact sur les informations clients stockées en dehors de ses propres dépôts internes, notamment les entreprises, organisations et dépôts de ses utilisateurs.

Cette distinction corrige une ambiguïté fréquente dans les titres publiés au moment de l’attaque. GitHub a bien subi une cyberattaque majeure et des milliers de dépôts non publics ont bien été copiés, mais les éléments confirmés ne permettent pas d’affirmer que 3 800 dépôts privés de clients auraient été volés.

L’extension identifiée est Nx Console, un outil destiné à intégrer l’écosystème Nx dans Visual Studio Code et les éditeurs compatibles. La version malveillante porte le numéro 18.95.0. Le projet Nx a publié un post-mortem détaillé et une alerte de sécurité classée critique.

Le 18 mai, la version 18.95.0 a été publiée sur Visual Studio Marketplace à 12 h 30 UTC. L’avis de sécurité indique qu’elle y est restée disponible environ dix-huit minutes. Sur Open VSX, utilisé notamment par plusieurs éditeurs compatibles avec l’écosystème VS Code, l’exposition a duré environ trente-six minutes, jusqu’à 13 h 09 UTC.

Une fenêtre de quelques dizaines de minutes paraît courte. Elle suffit pourtant lorsqu’une extension déjà installée est configurée pour se mettre à jour automatiquement. L’utilisateur n’a pas nécessairement recherché une nouvelle extension douteuse : une version compromise peut arriver comme une mise à jour normale d’un outil auquel il faisait déjà confiance.

Nx indique que les chiffres bruts des marketplaces faisaient état de 28 installations de la version compromise sur Visual Studio Marketplace et de 41 téléchargements depuis 21 adresses IP uniques sur Open VSX. Le projet avertit toutefois que ses propres données suggèrent un nombre d’utilisateurs potentiellement affectés supérieur.

Le correctif est clair : la version 18.95.0 est compromise, tandis que les versions 18.100.0 et ultérieures sont annoncées comme sûres par Nx. Les utilisateurs qui avaient Nx Console avec les mises à jour automatiques activées pendant la fenêtre d’exposition doivent considérer leur poste comme potentiellement compromis.

Le piratage de GitHub ne peut pas être compris en regardant uniquement l’extension VS Code. Le post-mortem de Nx montre une succession de compromissions dans la chaîne d’approvisionnement logicielle.

Le 11 mai 2026, l’ordinateur d’un contributeur Nx résout un paquet malveillant, @tanstack/zod-adapter 1.166.15, au cours d’une installation avec pnpm. Cet épisode appartient à une compromission plus large de paquets de l’écosystème TanStack. Le logiciel malveillant vole alors un jeton OAuth de GitHub CLI présent sur la machine.

Pendant les sept jours qui suivent, l’attaquant dispose d’un accès lui permettant d’agir dans les dépôts concernés. Le 18 mai, il utilise cette position pour publier Nx Console 18.95.0 sous l’identité d’un contributeur légitime. L’extension contaminée devient alors un nouveau vecteur de vol d’identifiants.

Le mécanisme est typique d’une attaque de supply chain : l’attaquant ne cherche pas nécessairement à forcer la porte de chaque victime. Il compromet un composant placé en amont et profite de la confiance déjà accordée à ce composant pour atteindre les utilisateurs en aval.

Cette architecture explique pourquoi les environnements de développement sont devenus des cibles prioritaires. Un poste de développeur peut contenir des jetons GitHub, des identifiants npm, des clés SSH, des secrets cloud, des variables d’environnement et des accès à des outils de déploiement. Compromettre une seule machine peut ouvrir plusieurs systèmes.

GitHub parle d’exfiltration de ses dépôts internes. Le Centre canadien pour la cybersécurité, dans son alerte du 29 mai, décrit environ 3 800 dépôts contenant du code source propriétaire et des données de configuration internes.

GitHub a immédiatement isolé le poste compromis, retiré la version malveillante et engagé sa procédure de réponse à incident. L’entreprise a également entrepris une rotation de secrets et de clés. Le 26 mai, elle a demandé aux administrateurs de GitHub Enterprise Server de remplacer les clés publiques GPG utilisées pour vérifier la signature des mises à jour.

Cette rotation ne signifie pas que GitHub a annoncé la distribution de binaires Enterprise Server falsifiés. Au contraire, l’entreprise précise que tous les binaires qu’elle héberge sont valides. La rotation a été décidée par précaution compte tenu des dépôts attaqués et du niveau d’exposition potentiel.

Pour GitHub Enterprise Cloud, aucune action liée à cette rotation n’était requise. Pour GitHub Enterprise Server, les administrateurs devaient installer la nouvelle clé publique avant de pouvoir vérifier correctement les futures versions signées avec la nouvelle clé.

Au 8 septembre 2026, GitHub maintient publiquement qu’il n’a pas de preuve d’un impact sur les données clients stockées en dehors de ses dépôts internes. Une absence de preuve n’est pas une garantie abstraite que tout risque futur est nul ; c’est l’état confirmé de l’enquête communiqué par l’entreprise.

Une extension d’éditeur n’est pas un simple habillage graphique. Selon ses fonctions et l’environnement dans lequel elle s’exécute, elle peut interagir avec le système de fichiers, les projets ouverts, des processus locaux et des informations d’authentification utilisées par les outils de développement.

Le danger est aggravé par la concentration des secrets sur le poste de travail. Un développeur authentifié à GitHub, à un registre de paquets et à une infrastructure cloud dispose précisément des accès qu’un attaquant cherche à obtenir. Une extension malveillante exécutée dans cet environnement peut transformer la commodité du poste en point de concentration du risque.

Le cas Nx Console montre aussi les limites du raisonnement « l’extension est connue, donc elle est sûre ». Le projet lui-même n’était pas présenté comme malveillant : c’est une version précise, publiée à la suite du vol d’un accès légitime, qui a été contaminée.

Les mécanismes de mise à jour automatique ajoutent une autre difficulté. Ils sont essentiels pour diffuser rapidement des correctifs, mais ils peuvent aussi distribuer une version empoisonnée avant qu’une équipe de sécurité ne détecte l’anomalie. Dans les environnements sensibles, la question n’est donc pas de supprimer toute mise à jour automatique, mais de définir quels composants peuvent évoluer automatiquement et lesquels doivent passer par une validation.

Cette attaque rappelle enfin qu’un dépôt « privé » ne doit jamais être traité comme un coffre-fort à secrets. Les identifiants durables, clés d’API et mots de passe ne devraient pas être stockés en clair dans le code, même lorsque le dépôt n’est pas public.

Les personnes ayant utilisé Nx Console le 18 mai 2026 doivent commencer par vérifier la version installée et l’historique de l’éditeur. Nx recommande de considérer la machine comme compromise si la version 18.95.0 a été installée pendant la fenêtre d’exposition.

Dans ce cas, supprimer l’extension ne suffit pas. Les identifiants qui ont pu être accessibles sur la machine doivent être renouvelés : jetons GitHub, identifiants npm, accès AWS, GCP ou Azure, clés SSH et autres secrets utilisés par les outils de développement. La rotation doit idéalement être réalisée depuis un poste sain.

Le Centre canadien pour la cybersécurité recommande également de rechercher sur macOS le fichier ~/.local/share/kitty/cat.py et les mécanismes de persistance associés, puis d’examiner les systèmes pour d’autres indicateurs de compromission. Une entreprise confrontée à un signal positif doit passer d’un simple nettoyage à une véritable investigation.

Pour prévenir un incident comparable, les organisations peuvent tenir une liste d’extensions autorisées, limiter les droits des jetons, préférer des identifiants à durée de vie courte, séparer les environnements sensibles et surveiller les événements de publication ou d’authentification inhabituels.

Le principe du moindre privilège est particulièrement important. Un jeton utilisé pour lire un dépôt n’a pas besoin de pouvoir publier un paquet ; un compte de développement quotidien n’a pas besoin de disposer en permanence de droits d’administration ; un secret de production n’a pas à rester disponible sur une machine si le travail courant ne l’exige pas.

Pour les entreprises dont le site internet constitue un actif commercial central, cette logique de maîtrise des accès doit aussi faire partie de la maintenance technique. WY-Créations présente son approche des sites internet sur mesure et de leur environnement technique.

Le point le plus instructif de cette affaire n’est pas que GitHub, entreprise spécialisée dans le développement logiciel, puisse être attaquée. C’est la manière dont l’attaquant a progressé : en exploitant les liens de confiance normaux du travail de développement.

Chaque étape prise isolément paraît raisonnable. Installer les dépendances d’un projet est normal. Utiliser GitHub CLI est normal. Publier une extension avec le compte d’un contributeur reconnu est normal. Mettre à jour automatiquement une extension connue est normal. Utiliser un poste authentifié pour accéder à des dépôts internes est normal. L’attaque assemble ces comportements légitimes pour créer une chaîne de compromission.

Cette logique oblige à déplacer la sécurité du seul périmètre réseau vers la chaîne de production logicielle. Les entreprises doivent savoir quelles dépendances elles utilisent, qui peut publier une nouvelle version, quelles preuves sont exigées avant publication et quels secrets sont accessibles au moment de l’exécution.

Le post-mortem de Nx indique avoir renforcé son pipeline de publication, notamment avec une approbation par deux administrateurs pour Nx Console et le recours à des mécanismes de publication de confiance OIDC pour d’autres dépôts. Ce type de mesure réduit la valeur d’un jeton volé : posséder un identifiant ne doit plus suffire à publier seul une version destinée à des milliers d’utilisateurs.

Le sujet concerne aussi les TPE et PME. Une agence, un prestataire informatique ou un développeur indépendant peut détenir les accès de plusieurs sites, hébergements, DNS, dépôts et comptes clients sur une même machine. L’impact d’une compromission dépasse alors largement l’ordinateur infecté.

Une politique simple peut déjà réduire le risque : inventaire des extensions, authentification forte, secrets séparés, droits limités, sauvegardes indépendantes, journaux consultables et procédure écrite de rotation des accès. La sécurité devient alors un processus reproductible plutôt qu’une réaction improvisée après l’incident.