Megalodon a transformé GitHub Actions en porte dérobée pour 5 561 dépôts

Une campagne automatisée a poussé 5 718 commits dans 5 561 dépôts GitHub en six heures un lundi de mai. Les commits ressemblaient à de la maintenance CI ordinaire (« ci: add build optimization step », « build: improve ci performance », « chore: optimize pipeline runtime ») et venaient d’auteurs aux noms anodins : build-bot, auto-ci, pipeline-bot. À la fin de la matinée du 18 mai, chacun de ces dépôts hébergeait un fichier de workflow contenant un payload bash encodé en base64.

La campagne s’appelle Megalodon. L’équipe de recherche de SafeDep l’a révélée le 21 mai, après avoir décortiqué les commits et remonté la piste jusqu’à un unique serveur de commande et contrôle à 216.126.225.129:8443. Ce qui est intéressant, ce n’est pas que GitHub ait été attaqué. C’est que l’attaquant n’a pas eu besoin de compromettre GitHub. Il a utilisé GitHub Actions, le système CI/CD conçu précisément pour garantir l’intégrité du code, comme véhicule de livraison de la porte dérobée.

Deux workflows, l’un massif, l’autre dormant

Megalodon a fonctionné selon deux modes. La variante massive ajoutait un nouveau fichier de workflow nommé SysDiag qui se déclenchait à chaque push et chaque pull request, capturant tout ce qui passait par lui. La variante ciblée, Optimize-Build, faisait quelque chose de plus patient : elle remplaçait un workflow existant par un déclencheur workflow_dispatch, qui reste dormant jusqu’à ce que quelqu’un l’invoque manuellement. Une porte dérobée dormant dans le répertoire CI d’un projet est bien plus difficile à repérer qu’un workflow inédit nommé SysDiag, parce que la plupart des mainteneurs n’auditent pas un fichier qu’ils ont eux-mêmes écrit.

Lorsque le workflow s’exécute, le payload lit tout ce qu’il peut atteindre dans l’environnement CI. Les variables d’environnement CI. Les clés d’accès, clés secrètes et jetons de session AWS. Les jetons d’accès GCP. Les clés SSH privées. Les identifiants .npmrc. Les configurations Docker. Les configurations Kubernetes. Les jetons OIDC de GitHub Actions, qui permettent à l’attaquant d’usurper le workflow lui-même auprès de tout compte cloud auquel il était autorisé. Avant de sortir, le payload effectue un grep dans le code du dépôt pour repérer plus de trente motifs de secrets distincts (clés d’API, mots de passe, fragments de certificats) au cas où un humain en aurait collé un. Les endpoints de métadonnées AWS IMDSv2, GCP et Azure sont également interrogés pour obtenir l’identité machine dans le cloud.

Un pipeline qui expédie sa propre porte dérobée

La victime la plus grave à ce jour est Tiledesk, une plateforme open source d’engagement client dont les neuf dépôts GitHub ont été touchés. Entre le 19 et le 21 mai, Tiledesk a publié son paquet tiledesk-server sur npm avec la porte dérobée intégrée. Les versions 2.18.6 à 2.18.12 de @tiledesk/tiledesk-server contiennent désormais le code du payload, installé par chaque développeur qui a exécuté npm install pendant cette fenêtre. C’est le levier pour lequel Megalodon a été conçu : implanter une porte dérobée dans un projet open source pour que son pipeline de release implante à son tour des portes dérobées dans des centaines de projets dépendants.

Black-Iron-Project a vu huit dépôts touchés. Des centaines de projets plus petits (comptes de développeurs individuels, clusters universitaires, sandboxes abandonnés) en ont reçu un ou deux chacun. L’attaquant n’a pas semblé sélectionner ses cibles. Le motif était la couverture large : des comptes jetables aux pseudonymes aléatoires de huit caractères poussant des messages de commit identiques minute après minute. Le serveur C2 enregistrait en silence ce qui revenait.

Pourquoi les fichiers CI ont survécu à l’audit

Cette attaque a marché pour la même raison qu’elle se répétera tout au long de 2026. Les pipelines CI/CD reposent sur la confiance par construction. Un développeur méfiant face à un binaire étrange dans un téléchargement exécutera sans hésiter un fichier de workflow arrivé dans son dépôt la semaine dernière, parce que c’est exactement ce que sont les fichiers de workflow : du code que la plateforme est censée exécuter. Les journaux d’audit existent, mais peu d’équipes les lisent. Les nouveaux commits arrivent sous des noms comme build-bot et ci-bot. Les diffs sont petits. La chaîne base64 en bas du workflow est opaque exprès.

Le manuel défensif est simple et peu réjouissant. Faire tourner chaque secret ayant transité par un dépôt entre le 18 mai et aujourd’hui. Auditer le répertoire .github/workflows de chaque projet sous gestion. Inspecter les commits dont l’email de l’auteur ne correspond à aucun membre connu de l’équipe. Considérer toute chaîne base64 dans un fichier Actions comme coupable jusqu’à décodage. Les organisations qui utilisent Tiledesk doivent revenir à 2.18.5 ou attendre une release propre. Toute personne ayant une confiance OIDC entre Actions et un fournisseur cloud doit révoquer et réémettre cette relation de confiance.

Megalodon est la première campagne à cette échelle qui traite le workflow CI lui-même comme la cible molle. Ce ne sera pas la dernière. La leçon que livre l’attaque, les développeurs l’ont déjà entendue plus bas : la partie du pipeline que vous ne lisez pas est la partie que l’attaquant écrit pour vous.