Ein npm-Paket wird installiert, ein `preinstall`-Skript startet automatisch – und wenige Sekunden später sind GitHub-, Cloud- oder Registry-Zugangsdaten abgeflossen. Das Muster ist bekannt. Der aktuelle Fall um mehrere Pakete im Scope `@redhat-cloud-services` ist trotzdem bemerkenswert. Er zeigt, wie schnell ein kompromittierter Entwicklungs- und Publishing-Prozess zum Lieferkettenproblem für nachgelagerte Teams werden kann. Für Unternehmen lautet die zentrale Frage daher nicht nur: „Haben wir dieses Paket installiert?“ Sondern: „Würden wir überhaupt erkennen, wenn eine vertrauenswürdige CI/CD-Pipeline plötzlich schädliche Artefakte erzeugt?“
StepSecurity berichtete am 1. Juni 2026, dass mehrere npm-Pakete im Namensraum `@redhat-cloud-services` kompromittierte Versionen auslieferten. Der Schadcode lief laut Analyse automatisch bei `npm install` – also noch bevor Anwendungscode startet. The Hacker News und The Register griffen den Vorfall am selben Tag auf und ordneten ihn als neue Mini-Shai-Hulud- beziehungsweise „Miasma“-Welle ein. Ein GitHub-Issue im Repository `RedHatInsights/javascript-clients` dokumentiert die betroffenen Pakete und Versionen öffentlich. Genannt werden dort unter anderem `@redhat-cloud-services/rbac-client`, `sources-client`, `remediations-client`, `frontend-components` und weitere Pakete.
Technisch zählt vor allem der Ausführungspfad. npm-Lifecycle-Skripte wie `preinstall`, `install` und `postinstall` sind legitime Funktionen. Viele Pakete nutzen sie für Build-Schritte oder native Komponenten. Aus Security-Sicht sind sie aber auch ein direkter Codeausführungskanal auf Entwicklerrechnern, CI-Runnern und Build-Containern. StepSecurity beschreibt den Payload als mehrstufigen Credential Harvester. Er suchte unter anderem nach GitHub-Actions-Secrets, AWS-, GCP- und Azure-Zugangsdaten, Kubernetes- und Vault-Material, npm-Tokens sowie CircleCI-Informationen. Auffällig war auch die Größe des Installationscodes: rund 4,2 MB statt weniger Kilobyte, ergänzt um mehrere Obfuskationsschichten.
Besonders heikel ist die Weiterverbreitung. Laut StepSecurity wollte die Malware nicht nur Daten abgreifen, sondern mit gestohlenen npm-Tokens weitere Pakete veröffentlichen. Die Analyse nennt ausdrücklich den npm-Parameter `bypass_2fa`. Für Security-Programme ist das ein wichtiger Hinweis: Zwei-Faktor-Authentifizierung für Maintainer-Konten bleibt notwendig. Sie schützt aber nicht automatisch jede Publishing-Variante, wenn legitime Tokens, OIDC-Flows oder CI/CD-Kontexte missbraucht werden. Belastbarer Schutz entsteht erst durch mehrere Schichten: kurze Token-Laufzeiten, enge Scopes, Review von Release-Jobs, Anomalieerkennung und die Fähigkeit, verdächtige Releases schnell zu stoppen.
Die öffentlich sichtbaren Zahlen sind deutlich, müssen aber sauber eingeordnet werden. Im GitHub-Issue stehen mehr als 30 Paketnamen mit kompromittierten Versionen. The Register nennt mindestens 32 betroffene npm-Package-Releases und verweist auf rund 80.000 Downloads pro Woche für die betroffenen Pakete. Socket zählte laut The Register zum Berichtszeitpunkt 95 betroffene Paketversionen. Das heißt nicht automatisch, dass 80.000 produktive Systeme kompromittiert wurden. Downloads umfassen auch Caches, CI-Läufe, Entwicklerumgebungen und automatisierte Installationen. Die Zahlen zeigen aber die potenzielle Reichweite, wenn ein vertrauenswürdiger Paket-Scope in gängigen Build-Templates steckt. Entscheidend ist zudem die Zeitachse: In automatisierten Builds kann eine kompromittierte Version schon vor der ersten menschlichen Warnmeldung in Artefakte, Container oder Testumgebungen gelangen. Schnelle Nachvollziehbarkeit ist deshalb wichtiger als nachträgliche Vollständigkeit.
Für Unternehmen mit JavaScript-, Cloud- und AI-Stacks ist der Vorfall aus drei Gründen relevant. Erstens hängen moderne AI- und Web-Projekte oft an schnell wachsenden Dependency-Bäumen. Ein einzelnes Frontend-, SDK- oder Hilfspaket kann gleichzeitig in Agenten-Prototypen, internen Portalen, Preview-Deployments und Notebook-Umgebungen auftauchen. Zweitens liegen genau dort häufig besonders wertvolle Secrets: Model-API-Keys, Cloud-Rollen, GitHub-Tokens, Container-Registry-Zugänge oder Kubernetes-Konfigurationen. Drittens lösen Coding-Agenten, Template-Repositories und CI-Orchestrierung Builds zunehmend automatisch aus. Ein kompromittiertes Paket trifft damit nicht nur Entwickler, sondern auch Maschinenidentitäten und automatisierte Workflows.
Die erste Reaktion sollte inventarbasiert sein. Teams sollten Lockfiles, SBOMs, npm-Proxy-Logs, CI-Job-Historien und lokale Developer-Caches auf die im GitHub-Issue genannten Paketnamen und Versionen prüfen. Bei Treffern reicht ein reines Dependency-Update nicht aus. Fällt der Installationszeitpunkt in den betroffenen Zeitraum, müssen Secrets als potenziell kompromittiert gelten. Dazu gehören die Rotation von GitHub-, npm-, Cloud-, Vault-, Kubernetes- und CI/CD-Tokens, die Prüfung ungewöhnlicher GitHub-API-Nutzung, die Suche nach unerwarteten Package-Publishes sowie ein Review neuer oder veränderter Repository-Commits.
Mittelfristig braucht es strengere Leitplanken für Installationsskripte. `npm install --ignore-scripts` ist nicht überall praktikabel. Für besonders sensible CI-Phasen, Analysejobs und Agenten-Sandboxes kann es aber ein sinnvoller Standard sein. Wo Lifecycle-Skripte nötig sind, sollten Teams sie explizit freigeben und über Paket-Policies, interne Mirrors oder Dependency-Firewalls kontrollieren. Wichtig ist außerdem, Release-Pipelines nicht nur danach zu bewerten, ob sie „aus unserem GitHub-Workflow“ stammen. Provenance und OIDC belegen Herkunft und Pfad. Sie beweisen aber nicht automatisch die Gutartigkeit des Inhalts, wenn der legitime Workflow selbst kompromittiert wurde.
Ein weiterer Kontrollpunkt ist Telemetrie in Build-Umgebungen. Ein Paket, das während der Installation plötzlich Cloud-Credential-Dateien liest, GitHub-Actions-Secrets enumeriert, npm-Publish-Endpunkte anspricht oder verschlüsselte Daten an externe Ziele überträgt, sollte auffallen. Endpoint Detection auf Entwicklergeräten, egress-beschränkte CI-Runner, GitHub-Audit-Logs, npm-Registry-Monitoring und Secret-Scanning müssen hier zusammenspielen. Gerade in der AI-Entwicklung ist Netzwerksegmentierung zentral: Ein Prototypen-Runner sollte nicht dieselben Rechte haben wie eine produktive Deployment-Pipeline.
Die Einschränkung: Viele Details können sich noch ändern. Während der öffentlichen Analyse wurden betroffene Versionen laufend ergänzt. Auch Attribution bleibt bei Shai-Hulud-ähnlichen Toolsets schwierig, weil Angriffsbausteine kopiert oder offengelegt werden können. Unternehmen sollten deshalb nicht auf eine perfekte Täterzuschreibung warten. Entscheidend ist, ob eigene Systeme die genannten Pakete installiert, ausgeführt oder weiterveröffentlicht haben.
Das Fazit fällt nüchtern aus: Miasma ist kein völlig neues Angriffsmuster, aber ein aktueller Stresstest für Software-Lieferketten. Wer npm nur als Entwicklerkomfort betrachtet, unterschätzt die Reichweite von Installationsskripten und automatisierten Release-Pipelines. Die angemessene Antwort ist nicht Panik, sondern Disziplin: Abhängigkeiten inventarisieren, betroffene Versionen prüfen, Secrets rotieren, CI/CD-Rechte minimieren, Installationsskripte kontrollieren und verdächtiges Verhalten in Build-Umgebungen sichtbar machen.
Quellen: StepSecurity, „Multiple redhat-cloud-services npm Packages compromised“, 1. Juni 2026; GitHub Issue RedHatInsights/javascript-clients#492; The Hacker News, „Miasma Supply Chain Attack Compromises Red Hat npm Packages with Credential-Stealing Worm“, 1. Juni 2026; The Register, „Shai-Hulud malware infects Red Hat npm package versions downloaded 80K times weekly“, 1. Juni 2026.
