Die Lektion in Sachen Lieferkette, die hinter Shai-Hulud und Megalodon steckt

Die Kurzfassung

Was: Shai-Hulud und Megalodon waren Angriffe auf die Software-Lieferkette im Jahr 2026, die auf die Systeme abzielten, denen Entwickler am meisten vertrauen: Paketregister, GitHub-Actions-Workflows, CI/CD-Runner, Provenienz-Pipelines und Cloud-Identitätsverbünde.

Auswirkungen: „Mini Shai-Hulud“ kompromittierte npm- und PyPI-Pakete, darunter auch Pakete im Zusammenhang mit TanStack, Mistral AI, Guardrails AI, UiPath und OpenSearch, und war der erste umfassend dokumentierte Angriff, bei dem Malware mit gültiger SLSA-Build-Level-3-Herkunft verbreitet wurde (CVE-2026-45321, CVSS 9,6). Megalodon speiste später innerhalb von etwa sechs Stunden 5.718 bösartige Commits in 5.561 GitHub-Repositorys ein und installierte Backdoors in GitHub-Actions-Workflows, um Cloud-Anmeldedaten, SSH-Schlüssel, GitHub-Token, OIDC-Token-Daten und Geheimnisse im Quellcode zu stehlen.

Status: Diese Kampagnen sind zwar keine aktuellen Nachrichten mehr, doch die daraus gezogene Lehre ist nach wie vor aktuell. Offengelegte Anmeldedaten, inaktive, manipulierte Arbeitsabläufe, kompromittierte Paketversionen oder zu weit gefasste CI/CD-Vertrauensrichtlinien, die nicht bereinigt wurden, können nach wie vor Risiken für nachgelagerte Systeme darstellen.

Schweregrad: Erhebliche Auswirkungen auf die Lieferkette. Es handelt sich hierbei nicht um ein einzelnes anfälliges Paket oder eine einzelne CVE, die man durch einen Patch beheben und dann hinter sich lassen kann. Es handelt sich um ein wiederholbares Angriffsmuster, das auf die Systeme abzielt, mit denen Software entwickelt und veröffentlicht wird.

Warum dies für die Paketaufnahme von Bedeutung ist: Megalodon nutzte die Lücke zwischen Quellcode und Veröffentlichung aus. Der Angreifer musste das npm-Konto nicht kompromittieren, da ein legitimer Betreuer unwissentlich aus einer manipulierten Quelle veröffentlichen konnte. Genau diese Lücke soll SecureChain schließen, indem es neue Paketversionen bereits bei der Aufnahme analysiert – einschließlich Quellcode-Diffs, Build-Time-Hooks, verschleierter Payloads, versteckter Ausführungswege und Exfiltrationsverhalten –, bevor eine Version nachgelagert als vertrauenswürdig eingestuft wird.

Erledigen Sie dies jetzt: Überprüfen Sie die GitHub-Actions-Workflows, suchen Sie nach Megalodon-Indikatoren, ändern Sie alle Geheimnisse, die verdächtigen CI-Runner ausgesetzt sind, überprüfen Sie die Aufnahme betroffener Pakete und verschärfen Sie die OIDC-Vertrauensrichtlinien.

Bin ich betroffen?

Sie sind möglicherweise betroffen, wenn Ihre Organisation:

• Nutzt GitHub Actions für Builds, Tests, Releases, die Veröffentlichung von Paketen oder die Bereitstellung
• Ermöglicht es Workflows, ein ID-Token anzufordern: write
• Speichert Anmeldedaten für Cloud, Registry, SSH, Docker, Kubernetes, Terraform oder Vault in CI/CD
• Verwendet npm- oder PyPI-Pakete aus öffentlichen Registern ohne zusätzliche Einlasskontrollen
• Installierte betroffene Mini-Shai-Hulud-Pakete während des Sicherheitsfensters im Mai 2026
• Installierte Versionen von @tiledesk/tiledesk-server 2.18.6 bis 2.18.12
• Ermöglicht direkte Pushes in Standard-Branches
• Erfordert keine Überprüfung bei Änderungen an .github/workflows
• Betrachtet die Herkunft, die Signatur oder einen bekannten Paket-Herausgeber als Nachweis dafür, dass eine Abhängigkeit sicher ist

Ein schneller Einstieg ist die Suche in Repositories nach den bekannten Namen der Megalodon-Workflows und der C2-Adresse:

grep -R "SysDiag\|Optimize-Build\|216\.126\.225\.129" .github/workflows/ 2>/dev/null

Suchen Sie anschließend in den Workflows nach verschlüsselten Shell-Befehlen:

grep -R "base64 -d.*bash\|base64.*| *bash" .github/workflows/ 2>/dev/null

Sollte eine der beiden Suchanfragen unerwartete Ergebnisse liefern, überprüfen Sie den Repository-Verlauf und die CI-Protokolle, bevor Sie Dateien löschen oder Anmeldedaten austauschen. Die Protokolle können erforderlich sein, um nachvollziehen zu können, welche Vorgänge wann ausgeführt wurden und welche Geheimnisse offengelegt wurden.

Was Shai-Hulud und Megalodon sind

Shai-Hulud ist die Bezeichnung für eine Familie sich selbst verbreitender Supply-Chain-Angriffe auf Entwickler-Ökosysteme, insbesondere npm und PyPI.

Der ursprüngliche Wurm tauchte im September 2025 auf, als Unit 42 einen sich selbst replizierenden npm-Wurm dokumentierte, der Anmeldedaten sammelte und diese zur weiteren Verbreitung nutzte. Im November folgte eine weiter verbreitete Variante namens Shai-Hulud 2.0. Bis zum Frühjahr 2026 hatte der als „TeamPCP“ identifizierte Angreifer monatelang Backdoors in hochvertrauenswürdige Entwickler- und Sicherheitstools eingebaut.

„Mini Shai-Hulud“, die Angriffswelle vom Mai 2026, legte die Messlatte noch höher. Dabei wurden nicht nur schädliche Pakete über offensichtlich verdächtige Konten veröffentlicht. Es wurden auch legitime Build-Pipelines kompromittiert und dazu genutzt, schädliche Pakete zu erstellen, die mit gültigen Herkunftsbescheinigungen versehen waren.

Megalodon griff eine andere Ebene an. Anstatt sich auf die Veröffentlichung von Paketen zu konzentrieren, schleuste es massenhaft GitHub-Actions-Workflows in Tausende von Repositorys ein. Diese Workflows liefen in CI-Runner und stahlen die Geheimnisse, die CI/CD-Systeme von Natur aus enthalten: Cloud-Anmeldedaten, GitHub-Token, SSH-Schlüssel, Daten zu OIDC-Token-Anfragen, Docker-Anmeldedaten, Kubernetes-Konfigurationen, Terraform-Anmeldedaten, Vault-Token und Geheimnisse im Quellcode.

Beide Kampagnen zeigen gemeinsam denselben Trend. Angreifer versuchen nicht mehr nur, das von Ihnen installierte Paket zu manipulieren. Sie versuchen vielmehr, das System zu manipulieren, das es erstellt, signiert, veröffentlicht und bereitstellt.

Welle Eins: Mini-Shai-Hulud und das SLSA-Problem

Der herausragende Moment von „Mini Shai-Hulud“ ereignete sich am 11. Mai 2026 um 19:20 Uhr UTC, als innerhalb eines Zeitfensters von sechs Minuten 84 bösartige Artefakte in 42 Paketen im Namensraum @tanstack veröffentlicht wurden. Die Pakete schienen aus der echten Release-Pipeline von TanStack zu stammen und verwendeten dessen echte OIDC-Identität.

Das liegt daran, dass sie es tatsächlich getan haben.

Der Mechanismus, dem die Kennung CVE-2026-45321 (CVSS 9,6) zugewiesen wurde, verband drei bekannte Schwachstellen von GitHub Actions zu einem einzigen Angriffspfad:

1. Ein „pull_request_target“-Trigger, der auch dann mit Schreibzugriff ausgeführt wird, wenn der auslösende Pull-Request aus einem Fork stammt, und so den Einstieg ermöglicht.
2. Cache-Poisoning bei GitHub Actions, mit dem eine veränderte Abhängigkeit in den legitimen Build eingeschleust wird.
3. Entwendung eines aktiven OIDC-Tokens aus dem Speicher des Runner-Prozesses, das zum Abrufen eines gültigen Sigstore-Signaturzertifikats verwendet wird.

Mit einem echten Signaturzertifikat aus einer echten Pipeline erzeugte der Wurm gültige SLSA-Herkunftsbescheinigungen der Stufe 3 für die schädlichen Pakete.

Das ist der Punkt, der die Sichtweise der Teams auf die Herkunft verändern dürfte.

Das bedeutet nicht, dass SLSA bei seiner eigentlichen Aufgabe versagt hat. Es bedeutet vielmehr, dass viele Teams der Provenienz eine Frage stellen, die sie nicht beantworten kann. Die Provenienz kann aufzeigen, woher ein Artefakt stammt und ob es gemäß dem erwarteten Prozess erstellt wurde. In diesem Fall traf diese Garantie technisch gesehen zu, da die bösartigen Pakete tatsächlich über die erwartete Pipeline erstellt wurden. Das Problem bestand darin, dass die Pipeline selbst kompromittiert worden war.

SLSA bestätigt die Integrität des Builds. Es beweist jedoch nicht, dass der in den Build eingegebene Code sicher war, dass der Workflow nicht manipuliert wurde oder dass die Umgebung des Betreuers stromaufwärts nicht kompromittiert worden war. Diese Unterscheidung ist keineswegs rein theoretisch: Bei der Nachahmerwelle vom 1. Juni gegen den Namespace @redhat-cloud-services wurden bösartige Pakete ausgeliefert, die jeweils eine gültige npm-Provenienz aufwiesen und über GitHub Actions OIDC von einem kompromittierten Mitarbeiterkonto aus veröffentlicht wurden. Die Provenienz hat genau das getan, was sie verspricht. Sie verspricht nur nicht das, was die Teams annehmen.

Der Wurm verbreitete sich über 404 schädliche Versionen auf 172 npm-Pakete sowie zwei PyPI-Pakete und erreichte damit Ökosysteme, die mit TanStack, Mistral AI, Guardrails AI, UiPath und OpenSearch verbunden sind. Die 2,3 MB große, verschleierte Nutzlast durchsuchte mehr als 100 Dateipfade nach geheimen Daten und installierte Persistenz-Hooks, die einen Neustart überstehen, in Entwicklertools wie Claude Code und Visual Studio Code. Öffentlichen Berichten zufolge wurden die betroffenen Pakete insgesamt mehr als 518 Millionen Mal heruntergeladen [genaue Zahl vor der Veröffentlichung überprüfen; die Quellen unterscheiden sich darin, ob es sich um kumulative oder wöchentliche Zahlen handelt], weshalb es sich hierbei um ein Problem mit nachgelagerten Abhängigkeiten für jede Organisation handelte, die während des Zeitfensters aus öffentlichen Registern bezogen hat – und nicht nur um einen Vorfall auf Seiten der Paketbetreuer.

Einen Tag später, am 12. Mai, stellte TeamPCP das gesamte Shai-Hulud-Framework auf GitHub unter einer MIT-Lizenz als Open Source zur Verfügung – Berichten zufolge zusammen mit einem Wettbewerb, bei dem 1.000 US-Dollar in Monero für den größten damit durchgeführten Supply-Chain-Angriff ausgelobt wurden. Eine über Monate hinweg verfeinerte Funktion wurde so zu etwas, das jeder kompetente Angreifer bis zum Wochenende forken konnte.

Eine „grüne“ Herkunftsprüfung ist kein Sicherheitsurteil. Sie ist ein Anhaltspunkt bei einer umfassenderen Vertrauensentscheidung.

Welle 2: Megalodon und die CI/CD-Revolution

Sechs Tage nach dieser Open-Source-Veröffentlichung erschien „Megalodon“.

Zwischen 11:36 und 17:48 UTC am 18. Mai 2026 wurden im Rahmen der Kampagne 5.718 bösartige Commits in 5.561 GitHub-Repositorys hochgeladen. Der Angreifer nutzte Wegwerf-Konten mit zufällig generierten, achtstelligen Benutzernamen (rkb8el9r, bhlru9nr und ähnliche) sowie gefälschte Autorenidentitäten im Bot-Stil:

• Build-Bot
• auto-ci
• ci-bot
• Pipeline-Bot

Die Commit-Meldungen wurden so gestaltet, dass sie wie routinemäßige Wartungsarbeiten aussahen:

• ci: Schritt zur Build-Optimierung hinzufügen
• Aufgabe: Laufzeit der Pipeline optimieren
• ähnliche Änderungen zum Thema CI, die man leicht übersehen kann

Der Angreifer wollte den Anwendungscode nicht als bösartig erscheinen lassen. Der Angreifer wollte die Änderungen an der Pipeline als langweilig erscheinen lassen.

Megalodon setzte zwei Varianten des GitHub-Actions-Workflows ein, die beide die Befehle „id-token: write“ und „actions: read“ aufriefen, jeweils eine Base64-dekodierte Bash-Payload ausführten und beide an denselben C2-Server unter der Adresse 216.126.225.129:8443 berichteten.

SysDiag war die ressourcenintensive Variante. Es fügte einen Workflow hinzu, der bei jedem Push- und Pull-Request ausgelöst wurde, wodurch die Häufigkeit der Ausführung und der Datenerfassung maximiert wurde.

„Optimize-Build“ war die unauffällige Variante. Da sie „workflow_dispatch“ nutzte, konnte der Workflow inaktiv bleiben, bis er manuell über die GitHub-API ausgelöst wurde. Das macht sie als Hintertür besonders nützlich: keine ständigen fehlgeschlagenen Builds, keine offensichtlichen Störungen und kein unmittelbarer Grund für einen Betreuer, darauf aufmerksam zu werden.

Die von der Payload gesammelten Daten waren umfangreich. Sie erfasste CI-Umgebungsvariablen und /proc/*/environ, AWS-Anmeldedaten aus allen konfigurierten Profilen, Google Cloud-Token, Anmeldedaten für Instanzrollen, die von AWS-IMDSv2- und Azure-IMDS-Endpunkten abgerufen wurden, private SSH-Schlüssel, Docker-, .npmrc-, .netrc-, Kubernetes-, Vault- und Terraform-Anmeldedaten, den Shell-Verlauf, mehr als 30 reguläre Ausdrücke für API-Schlüssel und Verbindungszeichenfolgen sowie – was die schwerwiegendsten Folgen hatte – die URL zur Anforderung des GitHub-Actions-OIDC-Tokens und das Token selbst neben GITHUB_TOKEN, GitLab- und Bitbucket-Tokens.

Warum der Diebstahl bei der OIDC von Bedeutung ist

Viele Unternehmen haben sich im Bereich CI/CD von langfristig gültigen Cloud-Schlüsseln abgewandt und setzen nun auf OIDC-Föderation. Das ist ein Schritt in die richtige Richtung. Anstatt dauerhafte Anmeldedaten für AWS, Google Cloud oder Azure in GitHub Actions zu speichern, fordert der Workflow bei Bedarf kurzlebige Anmeldedaten an.

Megalodon zeigt, wo dieses Modell noch Einschränkungen benötigt.

Wenn ein bösartiger Workflow die Berechtigung „id-token: write“ anfordern kann, kann er die für die Identitätsübernahme einer vertrauenswürdigen Workflow-Identität erforderlichen OIDC-Token-Anforderungsdaten abrufen. Ist die entsprechende Cloud-Vertrauensrichtlinie zu weit gefasst, kann dieser bösartige Workflow kurzlebige Cloud-Zugangsdaten auf dem Rechner des Angreifers generieren.

Das Problem ist nicht, dass OIDC schlecht ist. Das Problem ist, dass das OIDC-Vertrauensverhältnis eng gefasst sein muss. Eine sichere Konfiguration sollte folgende Fragen beantworten:

• Welches Repository genau kann diese Rolle beantragen?
• Welcher Zweig, welches Tag oder welche Umgebung ist zulässig?
• Welcher Arbeitsablauf ist zulässig?
• Wird in diesem Workflow tatsächlich „id-token: write“ benötigt?
• Kann ein neu hinzugefügter Workflow dieselbe Vertrauensstufe übernehmen?
• Kann ein Workflow auf einem Nicht-Release-Zweig Produktionszugangsdaten anfordern?

Wenn die Vertrauensrichtlinie im Grunde besagt: „Dieses Repository ist vertrauenswürdig“, ist der Schadensumfang größer als nötig. OIDC verringert das Risiko langlebiger statischer Geheimnisse. Es löst jedoch nicht das Problem der Ausführung manipulierter Workflows.

Der Fall Tiledesk verdeutlicht das nachgelagerte Risiko

Megalodon war nicht nur ein Problem für den Repository-Betreiber.

Mindestens ein nachgelagertes Paket, @tiledesk/tiledesk-server, wurde in kompromittierter Form in den Versionen 2.18.6 bis 2.18.12 veröffentlicht. Wichtig ist dabei, dass das npm-Konto nicht der Ausgangspunkt des Angriffs war. Der Angreifer manipulierte das Quell-Repository, indem er bösartige GitHub-Actions-Workflow-Dateien einschleuste, und der legitime Betreuer veröffentlichte daraufhin unwissentlich Releases aus dieser manipulierten Quelle.

Deshalb reichten 2FA und die Codesignierung nicht aus. Das Veröffentlichungsereignis wirkte weiterhin legitim, da der Angreifer das npm-Konto zu keinem Zeitpunkt übernehmen musste. Beide Sicherheitsmaßnahmen bestätigten, dass die Veröffentlichung vom echten Betreuer stammte – was auch der Fall war. Die Sicherheitslücke lag bereits zuvor, nämlich zwischen Quellcode und Veröffentlichung.

Auch deshalb ist die Source-Diff-Analyse so wichtig. Ein Detektor, der beim Onboarding eine neue Paketversion mit ihrer Vorgängerversion vergleicht, würde die Änderung von 2.18.5 auf 2.18.6 prüfen, bevor er der neuen Version vertraut. Die eingeschleusten Workflow-Dateien und die Nutzlast fallen eindeutig in die Kategorien, die Alarm auslösen sollten: Ausführungs-Hooks zur Build-Zeit, Ausführungswege im CI/CD-Stil, verschleierte Nutzlasten, versteckte Ausführung, das Sammeln von Anmeldedaten und verdächtige Netzwerkaktivitäten – dieselbe Backdoor-Form wie bei „event-stream“ und „ua-parser-js“.

Genau diese Lücke soll SecureChain schließen. Da SecureChain den Quellcode-Diff analysiert, anstatt dem Veröffentlichungsereignis zu vertrauen, ist das System darauf ausgelegt, das Szenario zu erkennen, bei dem ein Maintainer einen manipulierten Quellcode veröffentlicht – ein Fall, den Signaturprüfung, Provenienzprüfung und die Zwei-Faktor-Authentifizierung (2FA) in Registern alle übersehen –, und dem Sicherheitsteam ein Analyseergebnis, markierte Diff-Abschnitte, eine Begründung sowie eine Bewertung zu liefern, bevor die Version an nachgelagerte Systeme weitergegeben wird.

 

Die gesamte Kaskade sieht wie folgt aus:

1. Ein Repository wird durch gestohlenen oder missbräuchlich genutzten Zugriff verändert.
2. Ein GitHub-Actions-Workflow wird eingefügt oder ersetzt.
3. Der Workflow wird in einer vertrauenswürdigen CI-Umgebung ausgeführt.
4. Geheimnisse werden dem Läufer entlockt.
5. Ein Paket kann aus manipulierten Quelldateien erstellt oder veröffentlicht werden.
6. Endnutzer installieren ein Paket, das auf den ersten Blick legitim erscheint.

Aus Sicht des Verbrauchers ist der Name des Pakets bekannt, der Herausgeber ist seriös und die Veröffentlichung stammt von dem erwarteten Konto. Doch die Quelle und der dahinterstehende Arbeitsablauf waren bereits kompromittiert. „Vertrauenswürdiger Herausgeber“ und „sicheres Paket“ sind nicht dasselbe.

Der Streit um die Urheberschaft – und warum er nichts an Ihrer Reaktion ändert

An dieser Stelle wird die Berichterstattung in den Medien unübersichtlich.

TeamPCP steht in engem Zusammenhang mit den umfassenderen Aktivitäten von Shai-Hulud, darunter frühere Angriffe auf Lieferketten und die Veröffentlichung des Wurm-Frameworks am 12. Mai. In einigen Berichten wird Megalodon direkt mit TeamPCP in Verbindung gebracht.

Bei genauerer Betrachtung zeigt sich, dass Megalodon starke Ähnlichkeiten in der Vorgehensweise mit Aktivitäten im Shai-Hulud-Stil aufweist, eine direkte Zuordnung ist jedoch nicht geklärt. OX Security, das die Megalodon-Nutzlast analysierte, stufte sie als höchstwahrscheinlich nachgemachten Code ein und verwies dabei auf ähnliches Verhalten und einen ähnlichen Stil, jedoch wenig gemeinsamen Code, keine direkten Verbindungen, keine gemeinsamen Identifikationsmerkmale und kein Bekennerschreiben. Megalodon fehlt zudem der öffentliche Verschlüsselungsschlüssel, den TeamPCP für die Teilnahme an seinem eigenen Wettbewerb verlangt; es handelt sich also nicht einmal um eine Wettbewerbsbeitrags. Bei „Mini Shai-Hulud“ gibt es starke Hinweise auf eine Zuordnung zu TeamPCP; bei Megalodon bestehen lediglich indirekte Überschneidungen. Die direkte Zuordnung ist daher mit geringer Sicherheit anzusehen.

Für die Verteidiger sollte diese Unterscheidung keinen Grund zur Verzögerung darstellen. Ganz gleich, ob es sich bei Megalodon um TeamPCP, einen Nachahmer oder einen anderen Akteur handelte, der die Open-Source-Tools nutzte – die Reaktion ist dieselbe: nach kompromittierten Workflows suchen, offengelegte Geheimnisse regelmäßig austauschen, OIDC verschärfen, Änderungen an Workflows einschränken und Entwickler-Endpunkte sowie CI/CD-Identitäten als Teil der Lieferkette behandeln. Man muss sich gegen die Methode wehren, nicht gegen den Markennamen.

Die eigentliche Ursache ist zudem weniger exotisch, als die Namen der Kampagnen vermuten lassen. Hudson Rock verglich die GitHub-Benutzernamen hinter den Commits von „Megalodon“ mit seiner Infostealer-Datenbank und stellte fest, dass 331 von 978 (über ein Drittel) mit Rechnern übereinstimmten, die bereits mit Infostealern infiziert waren, woraus das Unternehmen schloss, dass der Zugriff aus den Protokollen der Infostealer stammte. Die Voraussetzung für Angriffe dieser Art ist in der Regel kein GitHub-Zero-Day. Vielmehr handelt es sich um eine Entwickler-Workstation oder die Umgebung eines Betreuers, die bereits kompromittiert war.

Warum herkömmliche Scanner diese Art von Angriffen übersehen

Die meisten Schwachstellenscanner sind darauf ausgelegt, Fragen wie die folgenden zu beantworten:

• Gibt es für dieses Paket eine bekannte CVE?
• Ist diese Abhängigkeit veraltet?
• Verwendet dieser Container eine anfällige Bibliothek?
• Steht dieses Artefakt in Zusammenhang mit bekannter Malware?

Diese Fragen sind nach wie vor von Bedeutung. Aber Shai-Hulud und Megalodon bewegen sich auf einer anderen Ebene.

Ein manipulierter GitHub-Actions-Workflow ist nicht unbedingt eine anfällige Abhängigkeit. Eine Base64-kodierte Shell-Nutzlast im Verzeichnis „.github/workflows“ erscheint möglicherweise nicht in einer SBOM. Ein gestohlenes OIDC-Token ist kein CVE. Ein bösartiges Paket kann eine gültige Herkunftsangabe aufweisen, wenn der Angreifer die Pipeline kompromittiert hat, die es erzeugt hat. Ein legitimer Betreuer kann eine bösartige Version veröffentlichen, wenn die Quelle, aus der er veröffentlicht, bereits manipuliert wurde.

Bei der Absicherung der Lieferkette darf der Blick nicht nur auf das Endprodukt gerichtet sein. Die Teams benötigen Kontrollmechanismen, die Folgendes überprüfen:

• Verhalten des Pakets vor der Installation
• Änderungen auf Quellcodeebene und Unterschiede zwischen den einzelnen Versionen
• Integrität des Workflows und Hooks zur Ausführung während der Build-Phase
• CI/CD-Berechtigungen und Verhalten der Runner
• Herkunft und Kontext der Überlieferung
• Geltungsbereich der Cloud-Identität
• Offenlegung der Zugangsdaten von Betreuern und Entwicklern
• Signale für Sicherheitslücken und Kompromittierungen nach der Veröffentlichung

Die Registrierungsdatenbank ist nur eine Ebene. Das Build-System steht nun im Mittelpunkt.

Milderung

Betrachten Sie Shai-Hulud und Megalodon als Anlass, den Software-Bereitstellungsprozess zu überprüfen und abzusichern – insbesondere, wenn Sie Ihre CI/CD-Risiken seit Mai 2026 nicht mehr überprüft haben.

1. Durchsuche deine Repositories

GitHub-Repositorys und -Forks nach folgenden Begriffen durchsuchen:

• Bezeichnungen für die SysDiag- und Optimize-Build-Workflows
• die C2-Adresse 216.126.225.129
• Ausführung von „base64 -d | bash“
• Unerwartete Auslöser von „workflow_dispatch“
• Unerklärtes ID-Token: Schreibrechte
• Workflow-Commits von unbekannten, botähnlichen Identitäten
• Direkte Pushes, die .github/workflows geändert haben

Achten Sie besonders auf Änderungen im Arbeitsablauf um den 18. Mai 2026 herum, insbesondere auf Änderungen, bei denen die Pull-Request-Prüfung umgangen wurde.

2. Bekannte Ausgänge blockieren und überprüfen

Blockieren Sie den ausgehenden Datenverkehr von CI-Runner-Instanzen an 216.126.225.129:8443 und überprüfen Sie die historischen Proxy-, Firewall- und Netflow-Protokolle auf Verbindungen von Build-Systemen oder selbst gehosteten Runner-Instanzen. Das Blockieren der IP-Adresse stellt zwar keinen vollständigen Schutz dar, da sich die Infrastruktur schnell ändert, ist jedoch für die nachträgliche Überprüfung und sofortige Bereinigung nützlich.

3. Offen gelegte Geheimnisse rotieren lassen

Wenn ein verdächtiger Workflow ausgeführt wurde, ist davon auszugehen, dass die Runner-Umgebung kompromittiert wurde. Priorisieren Sie die Rotation von GitHub-PATs und fein abgestuften Tokens, Deployment-Schlüsseln, Actions-Geheimnissen, GitHub-App-Anmeldedaten, npm- und PyPI-Veröffentlichungstokens, Docker-Registry-Anmeldedaten, privaten SSH-Schlüsseln, AWS-, Google Cloud- und Azure-Anmeldedaten, Kubernetes-Konfigurationen, Terraform-Anmeldedaten, Vault-Tokens sowie OIDC-Vertrauensbeziehungen, die mit den betroffenen Workflows verknüpft sind.

Eine Warnung, bevor Sie die Zugangsdaten widerrufen: Einige Payloads der Shai-Hulud-Familie enthalten eine zerstörerische Sicherheitsfunktion, die mit dem Widerruf der Zugangsdaten verknüpft ist. Es ist nicht bestätigt, dass dieses Verhalten auch ein Merkmal der Megalodon-Payloads ist. Bei jedem Host, bei dem Sie einen Infektionsverdacht haben, sollten Sie ihn jedoch isolieren und ein Image erstellen sowie die CI-Protokolle, den Verlauf der Workflow-Ausführungen und die Audit-Ereignisse sichern, bevor Sie die Zugangsdaten widerrufen.

4. Bekannte kompromittierte Paketversionen unter Quarantäne stellen

Wenn Sie @tiledesk/tiledesk-server nutzen, überprüfen Sie, ob die Versionen 2.18.6 bis 2.18.12 vorhanden sind. Falls eine dieser Versionen installiert, kompiliert oder bereitgestellt wurde, überprüfen Sie die betroffenen Umgebungen und aktualisieren Sie die während der Kompilierung oder zur Laufzeit verfügbaren Geheimnisse. Fixieren Sie die Version auf die letzte verifizierte fehlerfreie Version, 2.18.5, und überprüfen Sie die Lockfiles.

5. Die OIDC-Vertrauensbeziehung stärken

Gewähren Sie für sensible Cloud-Rollen kein pauschales Vertrauen auf Repository-Ebene. Schränken Sie das OIDC-Vertrauen nach Möglichkeit nach Repository, Branch, Tag, Umgebung, Workflow-Datei, Zielgruppe und Release-Pfad ein. Eine Bedingung wie „sub restricted to repo:org/name:ref:refs/heads/main“ verhindert, dass ein unerwünschter Workflow auf einem Neben-Branch Produktionszugangsdaten generiert.

Überprüfen Sie jeden Workflow, der Folgendes anfordert:

permissions:
id-token: write

Entfernen Sie es, es sei denn, es besteht ein dokumentierter Bedarf im Workflow, ein Token anzufordern.

6. Überprüfung bei Änderungen am Arbeitsablauf vorschreiben

Behandeln Sie .github/workflows als sicherheitsrelevanten Code. Nutzen Sie die CODEOWNERS-Genehmigung für Workflow-Dateien, Zweigschutz, obligatorische Pull-Request-Prüfung, signierte Commits, wo dies angebracht ist, standardmäßige schreibgeschützte Berechtigungen für Actions, an Commit-SHAs statt an veränderbaren Tags angeheftete Actions von Drittanbietern, eingeschränkten Datenausgang der Runner sowie separate Runner für sensible Release-Workflows. Eine Workflow-Datei kann genauso leistungsfähig sein wie Code für die Produktionsbereitstellung. Sie sollte nicht leichter zu ändern sein.

Erkennung

Kein einzelnes Scanner-Ergebnis belegt eine Exposition gegenüber Shai-Hulud oder Megalodon. Die relevanten Nachweise finden sich in der Repository-Historie, in Workflow-Dateien, in CI-Runner-Protokollen, in Netzwerkprotokollen, in GitHub-Audit-Ereignissen, in Cloud-Identitätsprotokollen und in Paket-Lockfiles. Verhaltenssignale sind zudem langlebiger als atomare Indikatoren, da der Betreiber die Infrastruktur regelmäßig wechselt.

Zu den nützlichen Signalen gehören:

• unerwartete Änderungen an .github/workflows
• Ausführung einer Base64-dekodierten Shell innerhalb der CI
• neue oder ungeklärte „workflow_dispatch“-Workflows
• Workflows, die ein ID-Token anfordern: Schreiben ohne triftigen Grund
• Direkte Pushes in Standard-Branches
• unbekannte, bot-ähnliche Autorennamen und gefälschte Commit-Daten
• Ausgehender CI-Runner-Datenverkehr an 216.126.225.129
• neue Deployment-Schlüssel, OAuth-Berechtigungen oder GitHub-App-Installationen
• Ungewöhnliche Annahmen zur Rolle von Cloud-Identitäten aus GitHub Actions
• Veröffentlichungen kurz nach verdächtigen Änderungen am Arbeitsablauf
• unerwartete npm- oder PyPI-Versionen in den Lockfiles aus dem Expositionsfenster

Beispiele für Suchbegriffe auf GitHub:

"216.126.225.129"
"SysDiag"
"Optimize-Build"
"base64 -d | bash"
"id-token: write"

Beispiel für die Suche nach lokalen Workflows:

grep -R "216\.126\.225\.129\|SysDiag\|Optimize-Build\|base64 -d" .github/workflows/ 2>/dev/null

Diese Überprüfungen sind ein erster Schritt, aber kein Freispruch.

Checkliste für priorisierte Sanierungsmaßnahmen

Repositorys überprüfen: Überprüfen Sie die Änderungen an den GitHub-Actions-Workflows, insbesondere im Zeitraum um den 18. Mai 2026.

Suche nach IOCs: Achten Sie auf „SysDiag“, „Optimize-Build“, verdächtige Base64-Ausführung und die gemeldete C2-Adresse.

Protokolle sichern: Bewahren Sie vor der Bereinigung die Protokolle der Workflow-Ausführungen, die GitHub-Audit-Protokolle, die Paket-Lockfiles und die Build-Artefakte auf.

Geheimnisse rotieren: Rotieren Sie Zugangsdaten, die einer verdächtigen Runner-Umgebung ausgesetzt sind.

OIDC straffen: Beschränken Sie die Cloud-Vertrauensrichtlinien auf bestimmte Workflows, Zweige, Tags oder Umgebungen.

Änderungen am Workflow einschränken: Für .github/workflows ist eine Überprüfung des Pull-Requests und die Genehmigung durch die CODEOWNERS erforderlich.

Überprüfung der Paketübernahme: Überprüfen Sie, ob bekanntermaßen kompromittierte Paketversionen in Ihre Umgebung gelangt sind.

CI/CD-Sicherheit verstärken: Aktionen von Drittanbietern an Commit-SHAs binden, den ausgehenden Datenverkehr der Runner einschränken und die Standardberechtigungen für Workflows minimieren.

Entwickler-Endpunkte überprüfen: Behandeln Sie Entwickler-Arbeitsstationen als Teil der Lieferkette, insbesondere wenn Systemadministratoren betroffene Pakete installiert haben oder lokal Zugriffsdaten vorhanden waren.

Warum es hier um mehr geht als nur um eine Kampagne

Das Wichtige an Shai-Hulud und Megalodon ist nicht nur ihre Größe, sondern auch die Richtung, in die sie sich bewegen. Die Angreifer dringen von den gefährdeten Systemen flussaufwärts in die dahinter liegenden vertrauenswürdigen Systeme vor:

• Anmeldedaten des Betreibers
• Entwickler-Endpunkte
• CI/CD-Runner
• GitHub Actions-Workflows
• OIDC-Identitäten
• Automatisierung der Paketveröffentlichung
• Herkunfts- und Signatursysteme
• Rollen bei der Cloud-Bereitstellung

Das verändert die Bedeutung von Open-Source-Sicherheit. Es reicht nicht mehr aus, ein Paket erst dann zu scannen, wenn es bereits in Ihre Umgebung gelangt ist. Sie müssen wissen, woher es stammt, wie es erstellt wurde, ob der Erstellungsprozess vertrauenswürdig war, was sich gegenüber der letzten Version geändert hat, ob das Paket während der Installation oder Erstellung verdächtige Aktivitäten zeigt, ob der Herausgeber oder das Repository kompromittiert wurde und ob die Komponente nach der Bereitstellung weiterhin Sicherheitsupdates erhält.

Genau dieses Problem soll SecureChain lösen. SecureChain bietet Unternehmen eine geprüfte Quelle für Open-Source-Komponenten, einschließlich Malware-Screening, Überprüfung auf Quellcode-Ebene, Herkunftsnachweis und fortlaufender CVE-Behebung über den gesamten Lebenszyklus der Komponenten hinweg. Bei neuen Paketversionen ist das System darauf ausgelegt, die Unterschiede zwischen den Versionen zu analysieren und verdächtige Änderungen zu kennzeichnen, bevor sie in nachgelagerten Prozessen als vertrauenswürdig eingestuft werden. Dazu gehören unter anderem Hooks zur Ausführung während der Build-Phase, verschleierte Payloads, versteckte Ausführungspfade und Exfiltrationsverhalten.

In einem Szenario nach dem „Megalodon“-Prinzip spielt dies eine Rolle, da das Paket möglicherweise vom legitimen Betreuer über das legitime Konto veröffentlicht wurde. Die böswillige Änderung befindet sich nicht an der Grenze zum Repository. Sie befindet sich in dem manipulierten Quellcode, der ins Repository gelangt ist.

Shai-Hulud und Megalodon machen deutlich, dass die Software-Lieferkette nicht nur aus dem Code besteht, den man installiert. Es ist das System, das ihn ausgewählt, erstellt, signiert, veröffentlicht und weiterhin wartet. Dieses System muss nun genauso gesichert werden wie die Produktionsinfrastruktur.

Entdecken Sie SecureChain →

FAQ

Ist Megalodon dasselbe wie Shai-Hulud?

Nein. Shai-Hulud bezeichnet eine Familie sich selbst verbreitender Supply-Chain-Angriffe, insbesondere über npm und PyPI. Megalodon war eine groß angelegte Kampagne zur Einschleusung von Workflows in GitHub Actions am 18. Mai 2026. Beide stehen hinsichtlich des Zeitpunkts und der Vorgehensweise in Zusammenhang, es ist jedoch nicht bestätigt, dass es sich bei Megalodon um dieselbe Operation oder denselben Akteur handelt.

Wurde „Megalodon“ definitiv von TeamPCP umgesetzt?

Nein. TeamPCP steht in engem Zusammenhang mit den Aktivitäten von Shai-Hulud, und Megalodon weist Ähnlichkeiten mit diesem Angriffsstil auf, doch eine direkte Zuordnung ist nicht bestätigt. Die Forscher, die den Megalodon-Code analysiert haben, stufen ihn höchstwahrscheinlich als Nachahmer ein. Verteidiger sollten sich eher auf die Technik als auf die Bezeichnung des Akteurs konzentrieren.

Schützt mich die SLSA-Herkunftsangabe davor?

Nicht an sich. Mini Shai-Hulud hat gezeigt, dass bösartige Pakete eine gültige SLSA-Build-Level-3-Herkunftsangabe enthalten können, wenn der Angreifer die Build-Pipeline kompromittiert. Die Herkunftsangabe hilft dabei, die Herkunft und die Integrität des Builds nachzuweisen. Sie beweist jedoch nicht, dass der Code sicher war.

Schützt OIDC CI/CD vor dem Diebstahl von Anmeldedaten?

OIDC ist sicherer als die Speicherung langlebiger Cloud-Schlüssel in CI, erfordert jedoch nach wie vor eine strenge Eingrenzung des Zugriffsbereichs. Wenn ein böswilliger Workflow „id-token: write“ anfordern kann und die Cloud-Vertrauensrichtlinie zu weit gefasst ist, kann ein Angreifer über die vertrauenswürdige Pipeline-Identität kurzlebige Anmeldedaten generieren.

Warum konnten die Zwei-Faktor-Authentifizierung (2FA) und die Anmeldung den Angriff auf Tiledesk nicht verhindern?

Denn der Angreifer musste das npm-Konto nicht kompromittieren. Megalodon hat das Quell-Repository manipuliert, und der rechtmäßige Betreuer hat aus dieser manipulierten Quelle heraus veröffentlicht. Zwei-Faktor-Authentifizierung und Signierung schützen den Veröffentlichungsvorgang; sie garantieren jedoch nicht, dass die veröffentlichte Quelle unverfälscht war.

Ich betreibe nicht viele GitHub-Repositorys. Bin ich trotzdem gefährdet?

Möglicherweise. Selbst wenn Sie nicht direkt betroffen waren, könnten Ihre vorgelagerten Abhängigkeiten aus kompromittierten Repositories erstellt oder veröffentlicht worden sein. Jede Organisation, die Open-Source-Pakete nutzt, übernimmt ein gewisses Risiko aus den Build-Pipelines, die hinter diesen Paketen stehen.

Was ist die wichtigste langfristige Lösung?

Behandeln Sie CI/CD wie eine Produktionsinfrastruktur. Beschränken Sie Änderungen am Workflow, legen Sie den Umfang von OIDC eng fest, überwachen Sie das Verhalten der Runner, reduzieren Sie die Anzahl der Geheimnisse in CI, überprüfen Sie Pakete vor der Installation und betrachten Sie die Herkunft oder einen bekannten Herausgeber nicht länger als alleiniges Sicherheitsmerkmal.

Quellen

• Cloud Security Alliance – „Shai-Hulud/Megalodon: Ein zweistufiger KI-Angriff auf die Lieferkette von Entwicklern“
• Protos Labs – „Die Shai-Hulud-Kampagne von TeamPCP und die Welle der Nachahmer“
• SafeDep – Analyse der Megalodon-Kampagne (Commit-Datensatz, Tiledesk-Kaskade)
• OX Security – Analyse der Urheberschaft von Nachahmerversionen von „Megalodon“ und „Shai-Hulud“
• StepSecurity – Analyse der Exfiltration von Geheimnissen durch Megalodon GitHub Actions; Analyse von Mini Shai-Hulud / TanStack
• Tenable – Mini Shai-Hulud CVE-2026-45321 – Häufig gestellte Fragen
• Hudson Rock – Ursachenanalyse zum Megalodon-Infostealer
• Unit 42 (Palo Alto Networks) – Erste Meldung zum Shai-Hulud-Wurm, September 2025
• The Hacker News – Berichterstattung über die „Megalodon“- und „Mini Shai-Hulud“-Kampagne
• Socket – Ungültigmachung von npm-Token und Analyse der „Shai-Hulud“-Kampagne