Faille

Megalodon : plus de 5 500 dépôts GitHub compromis lors d’une cyberattaque

Une vaste attaque visant l’écosystème GitHub a touché 5 561 dépôts en seulement quelques heures. Baptisée Megalodon, l’opération repose sur une technique particulièrement dangereuse : l’injection de workflows GitHub Actions malveillants dans des projets légitimes afin de voler des secrets techniques, des jetons d’accès et des identifiants cloud.

Plus de 5 700 commits malveillants en quelques heures

La campagne aurait généré 5 718 commits malveillants le 18 mai 2026, dans une fenêtre d’environ six heures. L’objectif n’était pas de modifier directement le code applicatif visible par les utilisateurs, mais de compromettre l’environnement de développement et d’intégration continue utilisé par les mainteneurs.

Le problème est critique, car les workflows GitHub Actions servent souvent à compiler, tester, publier ou déployer automatiquement un projet. Lorsqu’un attaquant parvient à y glisser du code malveillant, il peut s’exécuter dans un contexte privilégié, avec accès à des variables d’environnement, des secrets CI/CD, des clés API ou encore des identifiants cloud.

Megalodon cyberattaque

De faux bots GitHub pour masquer l’attaque

Dans cette attaque, les cybercriminels auraient utilisé de faux comptes GitHub aux noms générés aléatoirement, ainsi que de fausses identités imitant des services automatisés comme build-bot, auto-ci, ci-bot ou pipeline-bot. Le but était de donner aux commits l’apparence de modifications techniques ordinaires, comme celles qu’un robot de build ou d’intégration continue pourrait effectuer.

Deux méthodes principales sont évoquées. La première, appelée SysDiag, consistait à ajouter un fichier .github/workflows/ci.yml contenant un script malveillant. La seconde, plus discrète, appelée Optimize-Build, remplaçait des fichiers de workflow existants et utilisait le déclencheur workflow_dispatch. Cette approche permettait de garder le code en sommeil, sans déclencher immédiatement d’alerte visible ou d’échec de build.

Vol massif de secrets et d’identifiants cloud

Une fois activé, le script exécutait une charge utile encodée en Base64. Celle-ci cherchait à récupérer des informations sensibles présentes dans l’environnement du projet : configurations AWS, clés d’accès, profils cloud, variables d’environnement, fichiers Docker, Terraform, historiques de commande, jetons GitHub Actions, clés SSH, secrets npm, PyPI, Slack ou encore liens de bases de données.

Les données volées étaient ensuite envoyées vers un serveur de commande et contrôle associé à la campagne Megalodon. L’adresse mentionnée dans les analyses est 216[.]126[.]225[.]129:8443. Ce point est particulièrement préoccupant, car un simple secret CI/CD récupéré peut parfois permettre d’accéder à des infrastructures cloud, de publier des paquets piégés ou de rebondir vers d’autres dépôts privés.

Tiledesk et npm également touchés

L’un des cas les plus sensibles concerne Tiledesk, une plateforme open source de live chat et de chatbot. Plusieurs dépôts liés au projet auraient été touchés. D’après les analyses publiées, des versions du paquet npm @tiledesk/tiledesk-server, notamment les versions 2.18.6 à 2.18.12, auraient été publiées après compromission d’un workflow, propageant ainsi le risque au-delà de GitHub.

C’est précisément ce qui rend cette attaque dangereuse : elle ne vise pas seulement un dépôt isolé, mais toute la chaîne logicielle. Un mainteneur peut publier une nouvelle version sans se rendre compte qu’un workflow a été modifié en amont. Des développeurs, entreprises ou projets tiers peuvent ensuite installer un paquet contaminé ou déclencher un pipeline compromis.

La supply chain open source devient une cible prioritaire

Le scénario rappelle une tendance de plus en plus fréquente : les attaquants ciblent désormais les outils des développeurs, les dépôts open source et les chaînes CI/CD plutôt que les serveurs finaux uniquement. En compromettant l’endroit où le logiciel est construit, testé ou publié, ils peuvent atteindre indirectement des milliers d’organisations.

Les risques sont importants : vol de clés cloud, compromission de comptes GitHub, publication de paquets piégés, accès à des dépôts privés, exfiltration de code source, rebond vers des environnements de production ou usurpation de workflows légitimes.

Les développeurs appelés à vérifier leurs workflows

Les développeurs et mainteneurs concernés doivent vérifier en priorité les modifications récentes apportées aux fichiers présents dans .github/workflows/, en particulier autour du 18 mai 2026. Les commits provenant d’identités comme build-bot, auto-ci, ci-bot ou pipeline-bot doivent être considérés comme suspects s’ils ne correspondent pas à une activité connue du projet.

Les mesures immédiates recommandées sont claires : supprimer les workflows suspects, révoquer et renouveler les secrets exposés, faire tourner les clés cloud et API, contrôler les accès GitHub, auditer les publications npm récentes et bloquer les connexions vers le serveur de commande identifié.

Megalodon illustre une évolution majeure des cyberattaques : le danger ne vient plus seulement d’un logiciel malveillant téléchargé par l’utilisateur final, mais aussi du processus invisible qui fabrique et publie le logiciel. Quand la chaîne de compilation est compromise, toute la confiance accordée à un projet open source peut être détournée en quelques minutes.

Thomas Lazzaroni Thomas Lazzaroni
Articles similaires