Megalodon machte GitHub Actions zur Hintertür für 5.561 Repositorys

Eine automatisierte Kampagne pushte 5.718 Commits in 5.561 GitHub-Repositorys innerhalb von sechs Stunden an einem Montag im Mai. Die Commits sahen aus wie gewöhnliche CI-Wartung („ci: add build optimization step“, „build: improve ci performance“, „chore: optimize pipeline runtime“) und kamen von Autoren mit unauffälligen Namen: build-bot, auto-ci, pipeline-bot. Als der Vormittag des 18. Mai vorbei war, hatte jedes dieser Repositorys eine Workflow-Datei mit einem base64-kodierten Bash-Payload darin.

Die Kampagne heißt Megalodon. Das Forschungsteam von SafeDep machte sie am 21. Mai öffentlich, nachdem es die Commits auseinandergenommen und der Artefaktspur bis zu einem einzigen Command-and-Control-Server unter 216.126.225.129:8443 gefolgt war. Das Interessante ist nicht, dass GitHub angegriffen wurde. Das Interessante ist, dass der Angreifer GitHub gar nicht kompromittieren musste. Er nutzte GitHub Actions, das CI/CD-System, das genau die Code-Integrität sichern soll, als Liefervehikel für die Hintertür.

Zwei Workflows, einer massiv, einer schlafend

Megalodon arbeitete in zwei Modi. Die Massen-Variante fügte eine neue Workflow-Datei namens SysDiag hinzu, die bei jedem Push und jedem Pull Request ansprang und alles abgriff, was durchlief. Die zielgerichtete Variante, Optimize-Build, ging geduldiger vor: Sie ersetzte einen bestehenden Workflow durch einen workflow_dispatch-Trigger, der schläft, bis jemand ihn manuell aufruft. Eine schlafende Hintertür im CI-Verzeichnis eines Projekts fällt viel schwerer auf als ein neuer Workflow namens SysDiag, weil die meisten Maintainer eine Datei, die sie selbst einmal geschrieben haben, nicht prüfen.

Sobald der Workflow läuft, liest der Payload alles, was er in der CI-Umgebung erreichen kann. CI-Umgebungsvariablen. AWS-Zugriffsschlüssel, geheime Schlüssel, Session-Tokens. GCP-Zugriffstokens. Private SSH-Schlüssel. .npmrc-Anmeldedaten. Docker-Konfigurationen. Kubernetes-Konfigurationen. GitHub-Actions-OIDC-Tokens, mit denen der Angreifer den Workflow selbst gegenüber jedem Cloud-Konto imitieren kann, für das er autorisiert war. Vor dem Beenden durchsucht der Payload den Quellcode des Repositorys nach mehr als dreißig verschiedenen Geheimnis-Mustern (API-Schlüssel, Passwörter, Zertifikatsfragmente), falls ein Mensch eines hineinkopiert hatte. Die Metadaten-Endpunkte von AWS IMDSv2, GCP und Azure werden ebenfalls abgefragt, um die Maschinenidentität in der Cloud zu erlangen.

Eine Pipeline, die ihre eigene Hintertür ausliefert

Das schwerwiegendste Opfer bisher ist Tiledesk, eine Open-Source-Plattform für Customer Engagement, deren neun GitHub-Repositorys getroffen wurden. Zwischen dem 19. und 21. Mai veröffentlichte Tiledesk sein tiledesk-server-Paket auf npm mit eingebauter Hintertür. Die Versionen 2.18.6 bis 2.18.12 von @tiledesk/tiledesk-server tragen jetzt den Payload-Code, installiert von jedem Entwickler, der in diesem Zeitfenster npm install ausgeführt hat. Genau für diesen Hebel wurde Megalodon gebaut: ein Open-Source-Projekt mit einer Hintertür zu versehen, damit dessen Release-Pipeline Hintertüren in Hunderte abhängige Projekte einbaut.

Black-Iron-Project verlor acht Repositorys. Hunderte kleinerer Projekte (Einzelentwickler-Konten, Universitäts-Cluster, vergessene Sandboxes) bekamen ein oder zwei ab. Der Angreifer schien nicht auszuwählen. Das Muster war Breite statt Präzision: Wegwerf-Konten mit zufälligen achtstelligen Benutzernamen pushten Minute für Minute identische Commit-Nachrichten. Der C2-Server protokollierte still, was zurückkam.

Warum CI-Dateien das Audit überlebten

Dieser Angriff funktionierte aus demselben Grund, aus dem er sich für den Rest von 2026 wiederholen wird. CI/CD-Pipelines beruhen per Design auf Vertrauen. Ein Entwickler, der einer seltsamen Binary im Download misstraut, führt eine Workflow-Datei, die letzte Woche in seinem Repository erschien, bedenkenlos aus, weil Workflow-Dateien genau das sind: Code, den die Plattform laufen lassen soll. Audit-Logs existieren, aber die wenigsten Teams lesen sie. Die neuen Commits kommen unter Namen wie build-bot und ci-bot. Die Diffs sind klein. Der base64-String am Ende des Workflows ist mit Absicht undurchsichtig.

Das defensive Drehbuch ist einfach und unbefriedigend. Jedes Geheimnis rotieren, das zwischen dem 18. Mai und heute ein Repository berührt hat. Das Verzeichnis .github/workflows jedes verwalteten Projekts prüfen. Commits inspizieren, deren Autor-E-Mail zu keinem bekannten Teammitglied gehört. Jeden base64-Blob in einer Actions-Datei als schuldig betrachten, bis er dekodiert ist. Organisationen, die Tiledesk einsetzen, sollten auf 2.18.5 zurückgehen oder auf einen sauberen Release warten. Wer OIDC-Vertrauen zwischen Actions und einem Cloud-Anbieter hat, sollte diese Vertrauensbeziehung widerrufen und neu ausstellen.

Megalodon ist die erste Kampagne dieser Größenordnung, die den CI-Workflow selbst als weiches Ziel behandelt. Sie wird nicht die letzte sein. Die Lehre, die der Angriff hinterlässt, kennen Entwickler in leiserer Form schon: Der Teil der Pipeline, den du nicht liest, ist der Teil, den der Angreifer für dich schreibt.

Mehr davon

Eine KI hat einen funktionierenden Zero-Day-Exploit geschrieben — Google fing ihn ab

Eine vergiftete VS-Code-Erweiterung stahl 3.800 interne GitHub-Repositories

Ein Login-Fehler ließ 70 Millionen cPanel-Webseiten für jedermann offen stehen

Ein Scan von 380.000 mit KI gebauten Apps findet Tausende ohne jede Authentifizierung