Am 18. Mai 2026 schleusten unbekannte Angreifer innerhalb von nur sechs Stunden Schadcode in 5.561 GitHub-Repositories ein. Der Angriff ist einer der größten automatisierten Supply-Chain-Angriffe auf die Open-Source-Entwicklungsinfrastruktur, der bisher dokumentiert wurde.

Was ist passiert?

Zwischen 11:36 und 17:48 UTC haben die Angreifer eine Reihe von Wegwerf-Accounts auf GitHub mit zufällig generierten achtstelligen Nutzernamen erstellt. Mit diesen Accounts schoben sie 5.718 manipulierte Commits in 5.561 Repositories. Die Commit-Autoren wurden als build-bot, auto-ci, ci-bot und pipeline-bot gefälscht. Die Commit-Nachrichten lauteten harmlos klingende Texte wie „ci: add build optimization step“ oder „chore: optimize pipeline runtime“, also exakt das, was ein automatisches CI-System routinemäßig erzeugen würde.
Entdeckt wurde die Kampagne vom Sicherheitsunternehmen SafeDep, das beim Scan des npm-Pakets @tiledesk/tiledesk-server eine base64-kodierte Bash-Payload in einer GitHub-Actions-Workflow-Datei fand. Tiledesk ist eine Open-Source-Live-Chat-Plattform, die seit 2019 mit Hunderten von Versionen im npm-Registry veröffentlicht wird. Beim Vergleich der infizierten Version 2.18.12 mit der sauberen 2.18.5 hatte sich nur eine einzige Datei geändert: eine GitHub-Actions-Workflow-Datei. Der Anwendungscode war identisch geblieben.

Wie funktionierte der Angriff?

Der Angreifer kompromittierte das GitHub-Repository von Tiledesk, nicht den npm-Account direkt. Der legitime Maintainer bemerkte die Manipulation nicht und veröffentlichte zwischen dem 19. und 21. Mai 2026 aus dem vergifteten Repository heraus sieben infizierte Versionen (@tiledesk/tiledesk-server 2.18.6 bis 2.18.12) in das öffentliche npm-Registry. Dieses Muster ist besonders heimtückisch: Die Paketsignatur und der Veröffentlichungsweg wirkten völlig legitim, weil der echte Maintainer selbst der Veröffentlicher war.
Die Angreifer nutzten kompromittierte Personal Access Tokens (PATs) oder Deploy Keys, um die Commits in die Repositories zu schieben. Sicherheitsforscher von Hudson Rock stellten fest, dass die betroffenen Zugangsdaten ausschließlich aus Infostealer-Daten stammen. Ein Infostealer ist Schadsoftware, die gespeicherte Passwörter und Tokens vom infizierten Entwickler-Rechner abgreift und an Angreifer weiterleitet.

Die eingeschleuste Payload kam in zwei Varianten:

• SysDiag (Massenvariante): Fügt einen neuen Workflow ein, der bei jedem Push und Pull-Request ausführt. Damit wird die Payload automatisch aktiviert, sobald jemand im Repository arbeitet.
• Optimize-Build (Zielvariante): Ersetzt bestehende Workflows durch einen schlafenden Backdoor, der nur per manuellem workflow_dispatch-Aufruf über die GitHub-API ausgelöst wird. Diese Variante wurde bei Tiledesk eingesetzt.

Was wurde gestohlen?

Sobald ein Entwickler in einem infizierten Repository arbeitet und ein CI-Lauf ausgelöst wird, exfiltriert die Payload alle erreichbaren Zugangsdaten an den C2-Server 216.126.225.129:8443. Konkret:

• AWS-Zugangsdaten (Access Keys, Session Tokens via AWS IMDSv2)
• Google-Cloud-Tokens (via gcloud auth print-access-token und GCP-Metadata-Endpoint)
• Azure-Zugangsdaten (via Azure IMDS)
• SSH-Private-Keys, Docker-Konfigurationen, Kubernetes-Config-Dateien
• npm-Credentials (.npmrc), Vault-Tokens, Terraform-Credentials
• GitHub-Actions-OIDC-Tokens (ermöglicht Cloud-Identity-Impersonation ohne statische Credentials)
• Alle CI-Umgebungsvariablen sowie Source-Code-Scans nach über 30 geheimen Mustern (API-Keys, Datenbankverbindungen, JWTs, PEM-Private-Keys)

Dieser Vorfall ist vom auf CYROS bereits veröffentlichten GitHub-Angriff vom 20. Mai 2026 zu unterscheiden. Jener Beitrag behandelt den Angriff der Gruppe TeamPCP über eine manipulierte VS Code Extension auf GitHub-interne Repositories. Megalodon ist ein separater Angriff, der öffentliche Repositories auf GitHub trifft und einen anderen Angriffsvektor nutzt, nämlich GitHub-Actions-Workflows in Entwickler-Repos. Eine formale Verbindung zwischen Megalodon und TeamPCP ist laut Sicherheitsforschern nicht belegt.

GitHub-Actions-Workflows werden von Entwicklungsteams häufig als rein technische CI-Konfiguration betrachtet und selten wie Anwendungscode geprüft. Genau diese Lücke haben die Angreifer ausgenutzt. Wer heute ein npm-Paket oder eine Open-Source-Bibliothek einbindet, importiert indirekt auch deren CI-Konfiguration. Ist diese kompromittiert, werden Cloud-Credentials und SSH-Keys aus der eigenen Pipeline gestohlen, ohne dass die eigene Codebasis betroffen ist.
Repositories ohne Branch-Protection-Regeln sind besonders gefährdet: Die Angreifer konnten direkt in den Default-Branch pushen, ohne dass ein Review-Prozess einsetzte.