Une nouvelle attaque informatique a visé GitHub, la plateforme de gestion de code source la plus utilisée au monde. Cette fois, le point d’entrée n’est pas un serveur exposé sur Internet, mais… un simple éditeur de code : Visual Studio Code (VS Code).

Dans cet article, on reprend calmement les faits, on explique comment l’attaque a fonctionné et surtout ce que vous pouvez faire, en tant que développeur ou développeuse, pour limiter les risques.

Ce qui s’est passé : GitHub touché au cœur

Un article publié sur le site spécialisé Tom’s Hardware (actualités tech et dev) a révélé qu’un groupe de hackers, appelé Team PCP, a attaqué environ 3800 dépôts internes de GitHub. Il ne s’agit pas de simples projets publics, mais de dépôts internes utilisés par GitHub lui‑même pour le développement.

Autrement dit : ce sont les coulisses de la plateforme qui ont été visées.

La communication officielle de GitHub

Le 20 mai 2026, GitHub a publié un premier message sur X (ex‑Twitter) pour annoncer :

« Nous enquêtons sur un accès non autorisé aux dépôts internes de GitHub. Bien que nous n’ayons actuellement aucune preuve d’impact sur les informations des clients stockés en dehors de ces dépôts, nous surveillons étroitement notre infrastructure pour détecter toute activité ultérieure. »

Quelques heures plus tard, un second message a apporté des précisions : GitHub a confirmé une compromission d’un appareil d’employé, liée à une extension VS Code empoisonnée.

En résumé, GitHub a :

  • identifié l’appareil compromis,
  • supprimé la version malveillante de l’extension,
  • isolé le point d’accès,
  • lancé une procédure complète de réponse à incident.

Qui sont les hackers derrière l’attaque ?

Le groupe à l’origine de cette opération se fait appeler Team PCP. Il est connu dans le milieu de la cybersécurité pour des attaques visant de grands projets open source et des écosystèmes populaires :

  • projets NPM,
  • Docker et autres projets très utilisés,
  • grandes organisations technologiques.

Leur spécialité : l’infiltration (rentrer discrètement dans un système) puis l’exfiltration (vol et extraction de données sensibles).

Un point d’entrée surprenant : une extension VS Code

L’élément le plus inquiétant dans cette affaire, c’est le vecteur d’attaque. Les pirates ne sont pas passés directement par GitHub, mais par l’environnement de travail d’un employé : son éditeur de code, VS Code.

Qu’est-ce qu’une « extension empoisonnée » ?

VS Code permet d’installer des extensions pour ajouter des fonctionnalités (thèmes, outils de debug, intégrations Git, assistants, etc.). Certaines de ces extensions peuvent, en pratique :

  • lire ou modifier des fichiers locaux,
  • accéder à des variables d’environnement,
  • communiquer avec Internet (API, serveurs, etc.).

Une « extension empoisonnée » est une extension qui semble légitime, mais qui contient du code malveillant caché. Par exemple, ce code peut :

  • voler des clés API,
  • récupérer des tokens GitHub,
  • lire des fichiers sensibles (configuration, secrets, etc.),
  • envoyer ces informations vers un serveur contrôlé par les attaquants.

C’est exactement ce qui s’est produit ici : l’extension installée sur la machine d’un employé de GitHub contenait un tel code.

Comment GitHub a découvert l’attaque ?

Dans ce type de piratage, ce ne sont pas toujours les victimes qui découvrent l’incident en premier. Les groupes de hackers qui volent des données les revendent sur des forums spécialisés (marchés noirs de la cybersécurité) ou s’en vantent pour gagner en notoriété.

Dans cette affaire :

  1. Un groupe revendique un accès ou une fuite de données liées à GitHub sur des forums de vente de données volées.
  2. Les équipes de sécurité et de veille repèrent cette revendication.
  3. GitHub lance alors une enquête interne pour vérifier s’il y a réellement eu intrusion.

C’est à partir de là que GitHub a retracé le chemin de l’attaque jusqu’à l’extension VS Code compromise installée sur l’ordinateur d’un employé.

Pourquoi cette attaque est particulièrement grave ?

Plusieurs éléments rendent cette attaque préoccupante pour l’écosystème du développement :

1. Le ciblage d’outils de développement

Les pirates ne se contentent plus d’attaquer des serveurs ou des sites web visibles. Ils ciblent désormais les outils de travail quotidiens des développeurs : éditeurs de code, gestionnaires de paquets, extensions, etc.

Si votre éditeur de code est compromis, tout votre environnement de développement peut l’être aussi : projets locaux, dépôts privés, secrets, accès à des plateformes cloud, etc.

2. L’accès aux dépôts internes

Un appareil d’employé GitHub donne potentiellement accès à des dépôts internes sensibles :

  • code source de fonctionnalités non publiées,
  • outils internes de gestion de la plateforme,
  • scripts d’infrastructure et d’automatisation.

Un tel accès peut, à terme, permettre d’insérer du code malveillant, de préparer d’autres attaques ou de mieux comprendre l’architecture interne pour la cibler.

3. L’impact sur tout l’écosystème

GitHub est au cœur de l’écosystème logiciel mondial. Même si GitHub assure ne pas avoir trouvé de preuve d’impact direct sur les dépôts des clients, le simple fait que des dépôts internes aient été touchés est un signal d’alarme pour toute la communauté.

De nombreux développeurs se posent déjà la question de leur dépendance à GitHub et de la sécurité globale de leurs outils.

Ce que vous pouvez faire pour vous protéger

Vous n’êtes pas obligé d’être une grande entreprise pour être concerné. En tant que développeur ou développeuse, votre poste de travail est une cible potentielle. Voici quelques bonnes pratiques simples à mettre en place.

1. Soyez très sélectif avec vos extensions VS Code

  • Limitez le nombre d’extensions : installez uniquement ce dont vous avez réellement besoin.
  • Vérifiez la réputation : nombre de téléchargements, notes, commentaires, ancienneté.
  • Privilégiez les éditeurs connus ou les organisations reconnues.
  • Mettez régulièrement à jour vos extensions pour bénéficier de correctifs.

2. Protégez vos identifiants et tokens

  • Utilisez un gestionnaire de mots de passe plutôt que des fichiers texte.
  • Stockez vos tokens GitHub et clés API dans un gestionnaire de secrets, pas en clair dans le code.
  • Révoquez immédiatement un token dès que vous suspectez un problème.

3. Séparez vos environnements

  • Évitez de mélanger projets personnels et professionnels sur la même machine lorsque c’est possible.
  • Pour les projets sensibles, privilégiez un environnement dédié (machine, VM ou conteneur).
  • Limitez les droits de votre compte : principe du moindre privilège.

4. Surveillez l’actualité sécurité

  • Suivez les annonces officielles de vos outils principaux (GitHub, VS Code, NPM, Docker…).
  • Abonnez-vous à quelques sources fiables (blogs de sécurité, comptes officiels).
  • Appliquez rapidement les recommandations lorsqu’une faille est annoncée.

Vers une prise de conscience des développeurs

Cette attaque montre que :

  • nos outils de développement (éditeurs, extensions, registres de paquets) sont devenus des cibles stratégiques ;
  • la chaîne d’outillage d’un développeur est aussi importante à sécuriser que les serveurs de production ;
  • même des géants comme GitHub peuvent être touchés via un simple poste de travail.

Sans céder à la panique, il est temps d’adopter des réflexes de base en cybersécurité dans notre quotidien de dev : installer moins, vérifier plus, mettre à jour souvent, et traiter nos environnements de développement comme des actifs critiques.

En restant informés et en appliquant quelques bonnes pratiques, nous pouvons réduire significativement le risque… même face à des groupes organisés comme Team PCP.