Miasma Supply-Chain-Angriff: Vom TeamPCP-Toolkit zum Wurm, der Microsoft und Red Hat traf

Diese Commits waren keine Bagatelle. Im Repository RedHatInsights/javascript-clients injizierten die Angreifer einen bösartigen GitHub-Actions-Workflow, der OIDC-Identitätstoken anforderte und eine verschleierte Nutzlast ausführte . Diese Nutzlast veröffentlichte 32 trojanisierte Paketversionen unter dem offiziellen npm-Scope @redhat-cloud-services, jede einzelne mit der Kampagnenmarkierung „Miasma: The Spreading Blight“ . Da die Pakete die legitime CI/CD-Pipeline von Red Hat durchliefen und valide OIDC-Veröffentlichungs-Workflows nutzten, trugen sie authentische SLSA-Provenienzsignaturen – für standardmäßige Sicherheitsprüfungen wären sie damit als verifiziert durchgegangen .

Die schädlichen Pakete verzeichneten durchschnittlich rund 80.000 wöchentliche Downloads . In dem Moment, in dem ein Entwickler

npm install

Das neuartigste Verhalten des Wurms war allerdings nicht nur der Diebstahl von Zugangsdaten, sondern die Ausnutzung von KI-Coding-Tools. Varianten von Miasma platzierten schädliche Regeldateien für Claude Code, Cursor, Gemini CLI und GitHub Copilot. Diese Dateien werden automatisch ausgeführt, sobald ein Entwickler das kompromittierte Repository klont und in seiner IDE öffnet . Im Klartext: Das bloße Lesen des Codes – ganz ohne Installation eines Pakets – konnte die Schadroutine auslösen.

Am 5. Juni 2026 erreichte der Wurm Microsoft. Ein schädlicher Commit mit dem Titel „Switched DataConverter to OrchestrationContext [skip ci]“ landete im Repository Azure/durabletask, wobei die Metadaten so manipuliert waren, dass das Commit-Datum auf den 9. März 2020 gesetzt wurde – ein Versuch, keinen Verdacht zu erregen . Dieser Commit war der Brückenkopf. Von dort aus verbreitete sich der Wurm auf 73 Repositories in vier Microsoft-GitHub-Organisationen: Azure, Azure-Samples, Microsoft und MicrosoftDocs . Betroffen waren zentrale Infrastrukturprojekte wie azure-functions-host und die gesamte Durable-Task-Familie für .NET, Go, Java, JavaScript, MSSQL und Python .

Der Ursprung: TeamPCP und die Open-Source-Freigabe von Mini Shai-Hulud

Um Miasma zu verstehen, muss man die Entscheidung von TeamPCP verstehen, ihre Waffe als Open Source zu veröffentlichen.

TeamPCP (auch bekannt als Replicating Marauder, TGR-CRI-1135 und UNC6780) ist eine Gruppierung, die 2025 und Anfang 2026 eine Familie sich selbst verbreitender Supply-Chain-Würmer perfektionierte. Ihre Aktivitäten erreichten am 11. Mai 2026 einen Höhepunkt, als sie 373 schädliche Paketversionen in 172 npm- und PyPI-Paketen veröffentlichten, die zusammen über 518 Millionen Downloads erreichten . Diese Kampagne demonstrierte die Fähigkeit des Wurms, OIDC-Token aus dem Speicher von GitHub-Actions-Runnern zu extrahieren, gültige Signaturzertifikate zu erhalten und schädliche Pakete mit bestandenen Provenienz-Prüfungen zu erzeugen .

Dann, am 12. Mai 2026, veröffentlichte TeamPCP den vollständigen Quellcode von Mini Shai-Hulud auf GitHub unter einer MIT-Lizenz . Parallel dazu kündigte die Gruppe in den BreachForums einen Wettbewerb an und lobte 1.000 US-Dollar in Monero für den größten Supply-Chain-Angriff mit ihrem Framework aus . Die Botschaft war eindeutig: Das Toolkit war nun Allgemeingut.

Innerhalb von fünf Tagen hatte ein einzelner npm-Nutzer vier schädliche Pakete veröffentlicht, darunter einen nahezu wortgetreuen Klon des Shai-Hulud-Wurms. OX Security analysierte den Klon und stellte fest, dass er „fast ohne jede Änderung“ übernommen wurde und sich nur durch den eigenen Command-and-Control-Endpunkt und privaten Schlüssel des Angreifers unterschied . Die Industrialisierung von Supply-Chain-Angriffen hatte begonnen – und die Verteidiger wussten es noch nicht.

Siebzehn Tage nach der Open-Source-Veröffentlichung traf Miasma Red Hat. Der Code der Schadsoftware ist eine strukturelle Variante von Mini Shai-Hulud, wobei die ursprünglichen, an den Roman „Dune“ angelehnten Referenzen durch ein Branding aus der griechischen Mythologie ersetzt wurden . Die Vorgehensweise – Ausführung über preinstall-Skripte, verschleierte JavaScript-Nutzlasten, Diebstahl von Zugangsdaten und Selbstverbreitung über CI/CD – ist jedoch im Wesentlichen identisch .

Entscheidend ist, dass Forscher Miasma nicht eindeutig TeamPCP selbst zuordnen können. Die Cloud Security Alliance weist ausdrücklich darauf hin, dass „Nachahmer, die dieselbe öffentlich zugängliche Codebasis verwenden, nicht ausgeschlossen werden können“ . Unit 42 von Palo Alto Networks bekräftigt, dass „die Zuordnung unsicher bleibt“, da die öffentliche Freigabe des Quellcodes es jedem fähigen Akteur erlaubt, denselben Angriff zu replizieren . Diese Mehrdeutigkeit ist keine Fußnote – sie ist ein bewusstes Merkmal der Open-Source-Strategie, die darauf abzielt, das Ökosystem mit Rauschen zu fluten und Zuordnungsbemühungen zu überfordern .

Die Welle der Nachahmer: Phantom Gyp und die Ausweitung auf andere Ökosysteme

Das öffentlich gemachte Framework ermöglichte nicht nur Miasma, sondern löste eine sofortige Welle von Nachahmer-Aktivitäten aus.

Am 3. Juni 2026 tauchte eine neue Variante namens Phantom Gyp auf, die 57 weitere npm-Pakete erreichte, darunter @vapi-ai/server-sdk und ai-sdk-ollama . Diese Variante nutzte eine manipulierte binding.gyp-Datei, um Schadcode während der Paketinstallation auszuführen, und umging so den nun verstärkt überwachten postinstall-Ausführungspfad . Forscher von OpenSourceMalware bestätigten, dass dies der erste bestätigte Einsatz des TeamPCP-Frameworks in freier Wildbahn war, auch wenn TeamPCP sich nie dazu bekannte .

Bis zum 8. Juni berichtete das SANS Internet Storm Center, dass die breitere Angreiferpopulation das öffentliche Mini-Shai-Hulud-Framework nun aktiv nutzte und mehrere unabhängige Akteure ihre eigenen Kampagnen starteten . Die Schadsoftware hatte sich über npm hinaus ausgebreitet: Forscher identifizierten eine Ruby-Variante, die offenbar von einer KI übersetzt worden war – ein grober, aber funktionsfähiger Port, der nicht Teil des ursprünglich veröffentlichten Codes war . Die Geschwindigkeit der Anpassung, von npm auf mehrere Ökosysteme, zeigte, wie grundlegend sich die Angriffsfläche verändert hatte.

Die Reaktion der Unternehmen: Schnell, disruptiv und politisch

Die Reaktion auf Miasma war ungewöhnlich schnell und ungewöhnlich öffentlich, was sowohl das Ausmaß der Kompromittierung als auch die Beteiligung großer Plattformbetreiber widerspiegelt.

Die Reaktion von GitHub erfolgte umgehend. Die Plattform deaktivierte mehr als 70 Repositories im Besitz von Microsoft innerhalb von etwa 105 Minuten nach der Entdeckung am 5. Juni 2026 . Die deaktivierten Repositories umfassten die Organisationen Azure, Azure-Samples, Microsoft und MicrosoftDocs . Innerhalb weniger Tage wurden alle Repositories wiederhergestellt und für sauber erklärt, auch wenn einige betroffene Microsoft-CI/CD-Pipelines während der Abschaltung gestört wurden .

Microsoft veröffentlichte am 2. Juni 2026 eine detaillierte technische Analyse durch sein Threat-Intelligence-Team, die die gesamte Angriffskette von der anfänglichen Red-Hat-Kompromittierung bis zur Ausnutzung der CI/CD abdeckte . Microsoft unternahm zudem den höchst ungewöhnlichen Schritt, 73 seiner eigenen Repositories zu entfernen, und teilte BleepingComputer mit, dass die Entscheidung aus Sorge getroffen wurde, die Repos könnten „potenziell schädliche Inhalte“ verteilen . Die Störung der internen CI/CD-Workflows von Microsoft zeigte, dass selbst der Plattformbetreiber nicht gegen die nachgelagerten Konsequenzen eines Supply-Chain-Wurms immun war.

Red Hat veröffentlichte am 1. Juni 2026 die Sicherheitsmeldung RHSB-2026-006, bestätigte die Kompromittierung und erklärte, dass der Vorfall auf interne Entwicklungswerkzeuge beschränkt war und keine Auswirkungen auf Red Hat Enterprise Linux oder OpenShift-Produkte hatte . Das Unternehmen zog alle betroffenen npm-Paketversionen zurück und alarmierte nachgelagerte Anwender.

Das britische National Cyber Security Centre (NCSC) weitete den Vorfall zu einer breiteren politischen Initiative aus. Am 4. Juni 2026 veröffentlichte das NCSC einen Blogpost, der Organisationen ausdrücklich aufforderte, ihre Open-Source-Abhängigkeiten zu überprüfen und ihr Risiko für Supply-Chain-Angriffe zu reduzieren . Der Zeitpunkt war kein Zufall – der Beitrag bezog sich direkt auf die Miasma-Kampagne als Katalysator . Am 9. Juni 2026 veröffentlichte das NCSC ein aktualisiertes „Cyber Essentials Supply Chain Playbook“ und rief britische Unternehmen dazu auf, die Cyber-Essentials-Zertifizierung zu einer Standardanforderung für Zulieferer zu machen .

Die Leitlinien des NCSC konzentrierten sich auf drei Kategorien: Sichtbarkeit (Prüfung von Paket-Updates, Identifikation unerwarteter Abhängigkeiten und Führen einer Software Bill of Materials), Bewertung (Evaluierung der Sicherheitspraktiken von Zulieferern) und Handeln (Sicherung der Lieferkette als Priorität auf Vorstandsebene) . Die britische Regierung befasste sich zudem offiziell mit der TeamPCP-Kampagne – ein Wandel, bei dem die Sicherheit von Open-Source-Abhängigkeiten nun als Frage der nationalen Cybersicherheitspolitik behandelt wird und nicht mehr nur als individuelle Entwicklerhygiene.

Warum Miasma wichtig ist: Die weitreichenden Implikationen

Der Miasma-Angriff ist nicht der größte Supply-Chain-Vorfall der Geschichte und nicht der raffinierteste. Aber er könnte der lehrreichste sein, um zu verstehen, was als Nächstes kommt.

Erstens: Open-Source-Angriffs-Frameworks haben das Ökosystem bewaffnet. Die Entscheidung von TeamPCP, Mini Shai-Hulud unter einer MIT-Lizenz zu veröffentlichen, ist eine bewusste Strategie: Eine Armee von Nachahmern ausrüsten, ein Zuordnungschaos erzeugen und Verteidiger zwingen, sich gegen eine unbekannte Anzahl unabhängiger Akteure zu wehren, die dasselbe Playbook nutzen . Das ist nicht theoretisch – innerhalb von fünf Tagen nach der Veröffentlichung wurden Nachahmer-Aktivitäten dokumentiert, und die Zuordnung von Miasma selbst bleibt Wochen später ungewiss .

Zweitens: Der npm-preinstall-Hook ist eine systemische Schwachstelle. Der Angriff nutzt wiederholt eine Funktion aus, die für legitime Build-Skripte gedacht ist, aber nur unzureichende Kontrollen für die Ausführung von Lifecycle-Skripten bietet . Das Auftauchen von binding.gyp als zusätzlichem Ausführungsvektor in der Phantom-Gyp-Variante zeigt, dass Angreifer aktiv nach neuen Lifecycles suchen, um sie zu kapern . Registry-weite Einschränkungen für preinstall und andere Lifecycle-Skripte haben jetzt dringende Priorität.

Drittens: KI-Coding-Assistenten sind zu einer Angriffsfläche für die Codeausführung geworden. Miasma ist einer der ersten dokumentierten Supply-Chain-Angriffe, der gezielt Claude Code, Cursor, Copilot und Gemini CLI als Mechanismen zur Nutzlastbereitstellung durch schädliche Regeldateien angreift . Wenn ein Entwickler ein Repo klont und öffnet, können die KI-Tools, die ihm helfen sollen, besseren Code zu schreiben, stattdessen Schadcode ausführen. Dieser Vektor wird sich wahrscheinlich ausweiten, da die KI-gestützte Entwicklung zum Standard-Workflow wird.

Viertens: CI/CD-Pipelines sind jetzt die Ziele mit dem höchsten Wert. Die Fähigkeit des Wurms, OIDC-Token aus dem Runner-Speicher zu extrahieren und Pakete mit gültigen SLSA-Provenienz-Nachweisen zu erzeugen, bedeutet, dass die kryptografische Standardverifikation – der Goldstandard für Lieferkettenintegrität – ausgehebelt werden kann . Wenn Provenienzprüfungen erfolgreich sind, haben Verteidiger kein Signal, um die Kompromittierung zu erkennen. Die Absicherung von CI/CD-Pipelines gegen die Offenlegung von Zugangsdaten ist nicht länger optional.

Schließlich: Staatliche Eingriffe haben das Management von Open-Source-Abhängigkeiten erreicht. Das aktualisierte Playbook des NCSC ist keine unverbindliche Empfehlung, sondern eine konkrete Aufforderung an britische Unternehmen, die Sicherheit der Lieferkette in die Beschaffung einzubetten . Organisationen, die die Überprüfung von Abhängigkeiten als einmalige Prüfung und nicht als kontinuierlichen Prozess behandeln, arbeiten mit einer Sicherheitslage, die der Zeit vor Miasma entspricht.