GhostAction : des comptes de développeurs piratés pour voler les clés des serveurs

Début octobre 2026, plus de 30 000 projets hébergés sur GitHub ont reçu un script malveillant, ajouté avec les comptes de leurs propres développeurs. Son but : récupérer les clés qui ouvrent les serveurs, les bases de données et les comptes cloud. Aucune faille n’a été nécessaire : des accès volés ont suffi.

Ce qui s’est passé

GitHub est la plateforme où des millions de développeurs, et beaucoup d’agences web, stockent le code des sites et des applications. On peut y ajouter des scripts d’automatisation qui se lancent à chaque modification du code, par exemple pour mettre en ligne la nouvelle version. Pour cela, ces scripts utilisent des « secrets » : mots de passe de serveurs, clés d’accès au cloud, accès FTP ou base de données.

Selon la société GitGuardian, une campagne baptisée GhostAction, connue depuis septembre 2025, a fortement accéléré les 8 et 9 octobre : environ 1 900 comptes de développeurs ont servi à viser plus de 30 000 projets et 3 174 secrets (The Hacker News, 15 octobre 2026). GitHub empêche ce script de s’exécuter depuis le 9 octobre.

Lors de la vague de septembre, les secrets les plus visés étaient des accès aux serveurs, puis des clés cloud, des accès aux bases de données et des accès FTP (GitGuardian). Autrement dit, exactement ce qu’une agence web utilise pour mettre à jour le site d’une PME.

Comment l’attaque a fonctionné

Les attaquants n’ont pas cassé GitHub. Ils se sont connectés avec des accès de développeurs déjà volés, par exemple récupérés par des logiciels espions installés sur leurs ordinateurs, puis revendus.

Avec ces accès, ils ont ajouté dans chaque projet un script déguisé en contrôle de sécurité. À la modification suivante du code, ce script lisait les secrets du projet, fouillait aussi l’historique du code à la recherche de clés oubliées, puis envoyait le tout vers un serveur pirate. Tout se passait chez GitHub, sous l’identité réelle du développeur : rien de suspect à voir côté entreprise.

Deux constats de GitGuardian aggravent le tableau. Une partie des victimes avait déjà été touchée lors des vagues précédentes : les attaquants misent sur des clés jamais changées. Et les mêmes comptes volés ont servi à plusieurs groupes différents.

Ce qu’on ne sait pas encore

  • Qui est derrière la campagne.
  • Combien de secrets ont réellement été volés en octobre, et ce qui en a été fait.
  • Comment chaque compte a été volé au départ.

Ce que ça change pour une PME

Vous n’utilisez pas GitHub ? Votre agence web ou votre prestataire informatique, peut-être. Vos clés y sont alors aussi.

  1. Demandez à votre prestataire où sont stockées les clés de votre site, de votre hébergement et de vos bases de données, et qui y a accès.
  2. Faites changer ces clés régulièrement, et toujours à la fin d’un contrat ou au départ d’une personne.
  3. Exigez la double authentification pour tous ceux qui peuvent modifier votre code ou votre site.
  4. En cas de fuite, ne vous contentez pas de changer les clés volées : il faut aussi fermer l’accès qui a permis le vol, sinon il resservira.

Le regard de l’auditeur

Quatre questions à vous poser, ou à poser à votre prestataire. Elles s’inspirent de ce que vérifie un auditeur ISO 27001 :

  1. Avons-nous la liste des clés et mots de passe qui donnent accès à notre site et à nos serveurs, avec la date de leur dernier changement ?
  2. Qui peut modifier le code de notre site, et cette personne utilise-t-elle la double authentification ?
  3. Une modification des scripts de mise en ligne est-elle relue par quelqu’un d’autre avant d’être acceptée ?
  4. Notre contrat avec notre prestataire prévoit-il qu’il nous prévienne et change nos clés s’il subit une fuite ?

Pour les pros : notre analyse technique (mode opératoire, MITRE ATT&CK, questions d’audit ISO 27001).

Cet article prolonge notre bulletin de veille du 16 octobre 2026.

Analyse préparée avec l’aide d’une intelligence artificielle à partir de sources publiques, sous la responsabilité de KyNeo. Malgré nos contrôles, des erreurs peuvent subsister : en cas de doute, référez-vous aux sources citées. Les informations non confirmées sont signalées comme telles.