Miasma-Wurm kapert Red Hats npm-Pakete

Ein selbstverbreitender Wurm hat die offizielle Build-Kette von Red Hat unterwandert und 32 npm-Pakete vergiftet. Schon beim Installieren greift er nach jedem Cloud-Zugang auf dem Rechner. Eine zweite Welle hat den Trick inzwischen verfeinert.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Ein als Miasma getaufter npm-Wurm hat am 1. Juni 2026 die offizielle Build-Kette von Red Hat unterwandert und 32 Pakete im Scope @redhat-cloud-services mit Schadcode versehen. Schon ein einfaches npm install genügt, damit die Software den Rechner nach Zugangsdaten durchsucht. Brisant macht den Fall die Herkunft: Die manipulierten Versionen liefen durch Red Hats eigene Pipeline und trugen gültige Provenance-Signaturen.

Das Wichtigste in Kürze

• 32 Pakete im Scope @redhat-cloud-services, über 90 manipulierte Versionen, veröffentlicht am 1. Juni 2026
• Der Schadcode startet beim Installieren automatisch und sammelt GitHub-, npm-, AWS-, Azure-, GCP- und Vault-Zugänge
• Eine zweite Welle ab dem 3. Juni traf 57 weitere Pakete, darunter @vapi-ai/server-sdk und ai-sdk-ollama
• Erste Hilfe: Maschine säubern, dann von einem sauberen Gerät alle Zugangsdaten rotieren

Wie kam der Schadcode in offizielle Red-Hat-Pakete?

Den Ausgangspunkt bildeten gestohlene GitHub-Zugangsdaten samt Session-Cookie eines Red-Hat-Mitarbeiters, die laut dem Monitoring-Dienst Whiteintel schon im April und Mai in Infostealer-Logs auftauchten. Über die legitime CI/CD-Pipeline und den OIDC-Publishing-Workflow schoben die Angreifer manipulierte Versionen in die Registry, versehen mit gültigen Signaturen. Die Analyse von Microsoft Threat Intelligence zählt 32 Pakete und mehr als 90 Versionen, alle markiert mit der Kennung „Miasma: The Spreading Blight“.

Was richtet der Wurm auf dem Rechner an?

Beim Installieren startet ein preinstall-Hook einen 4,29 MB großen, stark verschleierten Dropper, der die Bun-Laufzeitumgebung nachlädt und einen Credential-Harvester ausführt. Die Software greift GitHub- und npm-Tokens ab, dazu AWS-, Azure- und GCP-Identitäten, HashiCorp Vault, Kubernetes-Secrets, SSH-Schlüssel und Browser-Daten. Anschließend veröffentlicht der Wurm sich über die erbeuteten npm-Tokens selbst weiter und fälscht dabei die SLSA-Provenance. Eine zweite Welle nutzte am 3. und 4. Juni die Datei binding.gyp als neuen Ausführungsweg, von Snyk als „Phantom Gyp“ geführt, und traf 57 weitere Pakete über 286 Versionen. Beim Widerruf eines hinterlegten Köder-Tokens löscht der Schadcode das Heimatverzeichnis.

Was sollten DACH-Teams jetzt tun?

Für die Aufarbeitung gilt eine feste Reihenfolge, weil der Schadcode das Heimatverzeichnis löscht, sobald er den Entzug seiner Zugänge bemerkt. Erst die Maschine säubern, dann von einem sauberen Gerät rotieren.

1. Abhängigkeiten prüfen: npm ls @redhat-cloud-services, npm ls @vapi-ai/server-sdk und npm ls ai-sdk-ollama ausführen und das Lockfile auf Versionen mit Publikationsdatum 1. Juni oder 3. bis 4. Juni durchsuchen.
2. Persistenz entfernen, bevor Sie etwas rotieren: ~/.claude/settings.json und .vscode/tasks.json auf fremde Einträge kontrollieren, vor allem SessionStart- und folderOpen-Hooks. Das Gerät vom Netz nehmen, die Einträge löschen.
3. GitHub-Spuren sichten: Das Security-Log auf unbekannte Repositories mit der Beschreibung „Miasma: The Spreading Blight“ prüfen, fremde Workflows und Runner entfernen, OIDC-Vertrauensbeziehungen widerrufen. Genau diese OIDC-Lücke nutzte der Red-Hat-Angriff.
4. Eigene Verbreitung ausschließen: Publish-Historie und Audit-Log auf Pakete oder Commits prüfen, die niemand im Team veröffentlicht hat.
5. Erst jetzt rotieren, vom sauberen Gerät: npm-Tokens, GitHub-PATs und SSH-Schlüssel zuerst, danach die Cloud-Zugänge für AWS, GCP und Azure, anschließend Kubernetes und Vault.

Gegen die nächste Welle hilft Vorbeugung mehr als Aufräumen. Feste Versionen mit Integritäts-Hash im Lockfile lassen eine Installation scheitern, sobald ein Paket mit verändertem Inhalt neu erscheint, und das noch bevor Code läuft. npm install --ignore-scripts blockiert zwar die preinstall-Hooks der ersten Welle, nicht aber den node-gyp-Pfad über binding.gyp aus der zweiten. Eng auf eine einzige Aufgabe begrenzte CI-Tokens senken zusätzlich den Wert jeder erbeuteten Zugangsdaten. Die kürzlich ausgerollte npm-2FA-Pflicht beim Veröffentlichen entwertet gestohlene CI-Tokens dauerhaft.

Red Hat betont, keine offiziellen Enterprise-Produkte mit den verseuchten Versionen ausgeliefert zu haben. Betroffen ist der npm-Scope rund um die Frontend-Komponenten der Hybrid Cloud Console. GitHub hat die npm-Tokens mit Schreibzugriff entzogen und den Scope zusätzlich abgesichert.

Vorgebaute Provenance schützt nicht vor einer verseuchten Build-Pipeline. Eine belastbare Lieferkette verbindet Skript-Sperren beim Installieren mit einer Quarantäne-Frist im internen Registry und planmäßiger Token-Rotation.

Mehr Newshunger?

• Betrügerische Anrufe: So warnt Android jetzt vor KI-Betrug
• Oracle WebLogic: Jetzt patchen, sonst droht Vollzugriff
• Knackt YellowKey BitLocker per USB-Stick? Offenbar ja
• 7-Zip: Ein Archiv genügt für die Codeausführung
• FortiClient EMS: Der Schutzserver wird zum Einfallstor
• LangChain: Die KI-Klebeschicht wird zum Angriffsvektor