Shai-Hulud-Miasma Variante bedroht Entwickler, Clouds und CI/CD-Pipelines

Ein vertrauenswürdiger Paketname reicht nicht mehr aus, um Software sicher zu machen. Genau das zeigt die neue Shai-Hulud-Welle „Miasma“, die legitime npm-Pakete aus dem Umfeld von Red Hat als Tarnung missbraucht. Der Angriff trifft nicht nur Entwicklerrechner, sondern kann über CI/CD-Pipelines, GitHub, npm und Cloud-Zugänge ganze Software-Lieferketten kompromittieren.

Das JFrog Security Research Team hat eine neue Angriffswelle der Supply-Chain-Malware Shai-Hulud analysiert . Im Fokus stehen 96 manipulierte Paketversionen aus dem npm-Namensraum @redhat-cloud-services. Besonders brisant: Die Angreifer setzten nicht auf klassische Typosquatting-Pakete mit ähnlich klingenden Namen, sondern missbrauchten echte, vertrauenswürdige und bereits etablierte Komponenten.

Im Schadcode selbst wird die Kampagne als „Miasma: The Spreading Blight“ bezeichnet. Der Name ist Programm: Die Malware ist darauf ausgelegt, sich weiterzuverbreiten, Zugangsdaten zu stehlen und Entwicklerumgebungen als Sprungbrett in nachgelagerte Systeme zu nutzen.

Der Angriff beginnt, bevor Entwickler das Paket überhaupt verwenden

Der zentrale Schwachpunkt liegt in einem Mechanismus, der im npm-Ökosystem häufig unterschätzt wird: Lifecycle-Hooks. Diese Skripte können bereits während der Installation eines Pakets ausgeführt werden, also noch bevor eine Anwendung das Paket aktiv importiert oder nutzt.

Im untersuchten Fall wurde ein preinstall-Skript in ein Paket eingebettet, das eigentlich nur Typdefinitionen enthält. Genau das macht den Fund auffällig. Solche Pakete benötigen normalerweise keinen Installer und sollten keinen ausführbaren Code beim Setup starten.

Noch raffinierter ist eine zweite Variante des Angriffs. Dabei nutzen die Angreifer eine binding.gyp-Datei, um gängige Sicherheitsprüfungen zu umgehen. Findet npm eine solche Datei, aber keine sichtbaren Lifecycle-Skripte, kann automatisch der Befehl node-gyp rebuild ausgeführt werden. Innerhalb der Konfigurationsdatei lässt sich über die Syntax <!(…) ein Shell-Befehl verstecken. Für viele Scanner sieht das wie ein harmloser nativer Build-Prozess aus. Tatsächlich startet im Hintergrund der Schadcode.

Shai-Hulud-Miasma stiehlt GitHub-, npm- und Cloud-Zugangsdaten

Nach der Installation aktiviert die Malware einen stark verschleierten Loader. Dieser entschlüsselt zwei AES-128-GCM-Blobs: einen kleinen Bun-Bootstrapper und die eigentliche Schadnutzlast. Falls die JavaScript-Laufzeit Bun nicht vorhanden ist, lädt die Malware sie direkt von GitHub nach. Anschließend wird die Nutzlast aus einer temporären Datei ausgeführt.

Die Malware sucht gezielt nach sensiblen Zugangsdaten. Dazu gehören unter anderem:

• GitHub-Token
• npm-Token
• AWS-, Azure- und Google-Cloud-Zugangsdaten
• Kubernetes-Secrets
• SSH-Schlüssel
• Passwortmanager-Daten
• Secrets aus CI/CD-Umgebungen

In Cloud-Umgebungen geht Shai-Hulud noch weiter. Die Malware fragt aktiv interne Metadaten-Schnittstellen und Secret-Stores der Cloud-Anbieter ab. Damit zielt der Angriff nicht nur auf lokale Entwicklerrechner, sondern auf die gesamte Infrastruktur, die rund um moderne Softwareentwicklung entsteht.

Besonders gefährlich für CI/CD-Pipelines

Ein kritischer Teil des Angriffs betrifft automatisierte Build- und Deployment-Prozesse. In GitHub-Actions-Umgebungen kann die Malware einen OIDC-Token anfordern. Dadurch kann sie sich gegenüber der npm-Registry als legitimer Build ausgeben.

Das zeigt ein zentrales Problem moderner Software-Lieferketten: Build-Provenance kann belegen, wo ein Paket gebaut wurde. Sie garantiert aber nicht, dass die Build-Umgebung selbst sauber war.

Für Unternehmen ist das ein Warnsignal. Wer nur prüft, ob ein Paket aus einer vertrauenswürdigen Pipeline stammt, übersieht möglicherweise den entscheidenden Punkt: Die Pipeline selbst kann bereits kompromittiert sein.

Tarnung über legitime Domain: Kein Hinweis auf kompromittiertes Anthropic-System

Zur Exfiltration nutzt die Malware eine besonders perfide Tarnung. Der Datenverkehr sieht so aus, als würde er an api.anthropic.com gehen. Dabei handelt es sich um einen legitimen Host. Der konkret angesprochene Pfad /v1/api existiert jedoch nicht und liefert lediglich einen 404-Fehler.

Damit nutzen die Angreifer den vertrauenswürdigen Domainnamen als Nebelkerze in Netzwerk-Logs. Wichtig ist: Daraus ergibt sich kein Hinweis darauf, dass Anthropic selbst kompromittiert wurde. Vielmehr missbraucht die Malware die Glaubwürdigkeit einer bekannten Domain, um verdächtigen Datenverkehr unauffälliger wirken zu lassen.

Wurmartige Selbstverbreitung über npm und GitHub

Shai-Hulud-Miasma bleibt nicht bei einem einzelnen infizierten System stehen. Findet die Malware npm-Token mit Veröffentlichungsrechten, injiziert sie sich in weitere Pakete. Anschließend erhöht sie die Patch-Version und veröffentlicht die manipulierten Pakete erneut.

Auf GitHub manipuliert die Malware außerdem Actions-Workflows und legt öffentliche Repositories mit der Beschreibung „Miasma: The Spreading Blight“ als Datenablage an. Dadurch entsteht ein Angriffsmuster, das an einen Wurm erinnert: Ein kompromittiertes Entwicklerkonto kann zum Ausgangspunkt für weitere infizierte Pakete, Repositories und Build-Prozesse werden.

Dead-Man-Switch: Token-Widerruf kann destruktive Aktionen auslösen

Der gefährlichste Teil der Kampagne ist ein sogenannter Dead-Man-Switch. Die Malware verankert sich dauerhaft über Systemdienste wie kitty-monitor unter Linux und macOS. Zusätzlich manipuliert sie Konfigurationsdateien von Entwicklerwerkzeugen und KI-Assistenten wie Claude, GitHub Copilot oder Gemini.

Besonders heikel: Ein destruktiver Token-Monitor kann reagieren, wenn ein gestohlener GitHub-Token ungültig gemacht wird. In diesem Fall kann ein hinterlegter Handler zerstörerische Befehle ausführen, im Extremfall bis hin zur Löschung des Benutzerverzeichnisses.

Das bedeutet: Wer kompromittierte Token vorschnell widerruft, riskiert zusätzlichen Schaden. Die richtige Reihenfolge bei der Bereinigung ist deshalb entscheidend.

Was Unternehmen jetzt tun sollten

Bei einem möglichen Shai-Hulud-Miasma-Befall sollten Unternehmen nicht sofort mit der Token-Rotation beginnen. Zuerst müssen betroffene Entwicklerrechner und CI/CD-Runner isoliert werden. Danach sollten Persistenzmechanismen entfernt und forensische Spuren gesichert werden.

Erst anschließend sollten Teams von einem nachweislich sauberen System aus sämtliche Zugangsdaten rotieren. Dazu gehören GitHub-Token, npm-Token, Cloud-Credentials, Kubernetes-Secrets, SSH-Schlüssel und alle weiteren im Build- oder Entwicklerkontext genutzten Secrets.

Zusätzlich empfiehlt sich:

• betroffene Pakete konsequent deinstallieren
• Lockfiles aus vertrauenswürdigen Quellen neu erzeugen
• CI/CD-Umgebungen vorübergehend mit npm ci –ignore-scripts betreiben
• npm-Lifecycle-Skripte systematisch prüfen
• binding.gyp-Dateien und native Build-Konfigurationen kontrollieren
• frisch veröffentlichte Paketversionen besonders kritisch bewerten
• unerwartete Downloads zusätzlicher Laufzeiten oder Binärdateien blockieren
• ausgehende Verbindungen auch zu vertrauenswürdigen Domains kontextbasiert analysieren

Fazit: Vertrauen in Paketnamen reicht nicht mehr

Der Fall Shai-Hulud-Miasma zeigt, wie gefährlich moderne Supply-Chain-Angriffe geworden sind. Die Angreifer missbrauchen nicht nur offene Paketquellen, sondern gezielt das Vertrauen in legitime Namensräume, bekannte Organisationen und automatisierte Build-Prozesse.

Für Unternehmen bedeutet das: Entwicklerrechner und CI/CD-Pipelines dürfen nicht länger als neutrale Durchgangsstationen betrachtet werden. Sie sind längst ein zentrales Angriffsziel. Der gute Ruf eines Pakets, einer Registry oder eines Namensraums ist kein Sicherheitsgarant mehr. Entscheidend ist, was ein Paket während der Installation tatsächlich ausführt, welche Berechtigungen es erhält und welche Systeme es danach erreichen kann. Shai-Hulud-Miasma macht deutlich: Der nächste Supply-Chain-Angriff kommt möglicherweise wieder über genau den Kanal, dem Teams bisher am meisten vertraut haben.