Am 1. Juni 2026 begann ein Angriff, der das Vertrauensmodell der modernen Softwareentwicklung an seiner empfindlichsten Stelle traf: nicht in einer obskuren Hobby-Bibliothek, sondern unter dem offiziellen npm-Namespace @redhat-cloud-services. Innerhalb weniger Stunden trugen 32 Pakete eines der grossen Enterprise-Anbieter einen sich selbst verbreitenden Wurm in die Build-Pipelines tausender Unternehmen. Sicherheitsforscher tauften die Kampagne „Miasma: The Spreading Blight“ - die sich ausbreitende Seuche. Der Name ist treffend, denn anders als bei einer klassischen Schwachstelle gibt es hier kein Patch-Datum, vor dem man sicher war und nach dem man sicher ist. Wer die kompromittierten Versionen installiert hat, hat den Erreger bereits im Haus.

Was genau passiert ist

Der Ausgangspunkt war kein technischer Exploit, sondern ein kompromittiertes GitHub-Konto eines Red-Hat-Mitarbeiters. Mit diesem Zugang schleuste der Angreifer manipulierte GitHub-Actions-Workflows in drei Repositories der RedHatInsights-Organisation ein: frontend-components, javascript-clients und platform-frontend-ai-toolkit. Die Commits umgingen das Code-Review, weil sie ueber kurzlebige Branches mit dem Muster oidc-<hex> eingespielt und sofort wieder entfernt wurden.

Das eigentlich Perfide liegt im Detail. Der Angreifer schrieb den vertrauenswuerdigen CI-Workflow in einen selbstpublizierenden Job um, der mit der Berechtigung id-token: write lief. Dieser Job forderte ueber GitHub Actions ein OIDC-Token an und tauschte es am npm-Publishing-Endpunkt gegen gueltige Publish-Tokens ein. Mit anderen Worten: Der Angriff brauchte keine gestohlenen npm-Passwoerter. Er nutzte exakt den Mechanismus, den die Branche als sicherere Alternative zu langlebigen Tokens empfohlen hatte - das „Trusted Publishing“ ueber OpenID Connect.

Fuer jedes Zielpaket lud der Wurm das legitime Tarball herunter, fuegte einen boesartigen preinstall-Hook hinzu und veroeffentlichte es neu - inklusive gueltiger SLSA-Provenance-Attestierung. SLSA (Supply-chain Levels for Software Artifacts) sollte eigentlich beweisen, dass ein Paket aus einer vertrauenswuerdigen Build-Kette stammt. Hier wurde dieser Beweis selbst zur Tarnung: Die manipulierten Pakete sahen nicht nur echt aus, sie trugen ein kryptografisch gueltiges Echtheitszertifikat.

Der Wurm im Detail: preinstall, Bun und Credential-Diebstahl

Sobald ein Entwickler oder eine CI-Pipeline eine der vergifteten Versionen mit npm install einspielte, lief der preinstall-Hook noch vor der eigentlichen Installation. Er startete eine obfuskierte Payload, die auf dem Bun-JavaScript-Runtime aufsetzte - ein bewusster Schachzug, denn viele Endpoint-Schutzloesungen achten auf node-Prozesse, nicht auf bun.

Die Payload durchsuchte die lokale Umgebung systematisch nach allem, was Zugang verschafft: npm-Tokens, GitHub-Tokens, SSH-Schluessel, Cloud-Credentials und CI/CD-Secrets. Diese Daten wurden exfiltriert. Anschliessend versuchte der Wurm, sich selbst weiterzuverbreiten: Er prüfte, auf welche npm-Pakete das kompromittierte Konto Schreibrechte besass, und republizierte sich ueber jedes erreichbare Paket. Genau dieser Mechanismus macht aus einem einzelnen Vorfall eine Kettenreaktion - ein Paket infiziert einen Maintainer, dessen Tokens infizieren das naechste Paket.

Technisch ist Miasma ein leicht ueberarbeiteter Nachfahre des (Mini-)Shai-Hulud-Wurms, der bereits seit Ende 2025 durch das npm-Oekosystem zieht. Mini Shai-Hulud tauchte im April 2026 zunaechst im SAP-Entwicklerumfeld auf und kompromittierte bis Mai bereits ueber 160 Pakete. Dass der Quellcode dieser Wurm-Familie inzwischen oeffentlich verfuegbar ist, senkt die Einstiegshuerde fuer Nachahmer dramatisch. Miasma ist deshalb kein Einzelfall, sondern ein Symptom einer ganzen Angriffsklasse, die sich gerade verfestigt.

Warum das den deutschen Mittelstand direkt betrifft

Es waere ein Trugschluss zu denken, dies sei ein Problem von Red Hat oder von Grosskonzernen. Die kompromittierten @redhat-cloud-services-Pakete verzeichneten zusammen rund 80.000 Downloads pro Woche. Sie stecken als transitive Abhaengigkeiten in unzaehligen Web-Frontends, internen Tools und Cloud-Anwendungen - oft, ohne dass die Entwickler ueberhaupt wissen, dass diese Bibliotheken in ihrem Abhaengigkeitsbaum liegen. Genau hier liegt das Kernproblem: Eine moderne JavaScript-Anwendung zieht schnell mehrere tausend transitive Pakete. Niemand liest sie alle.

Für ein mittelständisches Unternehmen, das selbst Software entwickelt oder entwickeln lässt, ist die Build-Pipeline damit zu einem der attraktivsten Angriffsziele überhaupt geworden. Denn dort liegen die Schlüssel zum gesamten Reich: Deployment-Credentials, Cloud-Zugänge, Signaturschlüssel. Ein erfolgreicher Angriff auf die Pipeline ist kein Diebstahl einzelner Daten - er ist die Übernahme der Produktionsmaschine, die Ihre Kunden mit Software versorgt. Wer professionelle Softwareentwicklung betreibt oder einkauft, muss die Lieferkette dieser Software heute genauso ernst nehmen wie die physische Sicherheit seiner Server.

Sofortmassnahmen: Was jetzt zu tun ist

Wenn Sie npm in Ihrer Entwicklung einsetzen, sollten Sie ohne Verzoegerung folgende Schritte gehen:

1. Pruefen, ob betroffene Versionen im Einsatz sind. Durchsuchen Sie Ihre package-lock.json und Ihre Build-Logs nach Paketen aus dem @redhat-cloud-services-Scope. Achten Sie auf Versionen, die zwischen dem 1. und 3. Juni 2026 veroeffentlicht wurden. Auch der Folge-Vorfall um @vapi-ai/server-sdk (3. Juni) gehoert auf die Pruefliste.

2. Lifecycle-Skripte abschalten. Setzen Sie fuer Installationen npm install --ignore-scripts oder global npm config set ignore-scripts true. Das verhindert, dass preinstall- und postinstall-Hooks unkontrolliert Code ausfuehren - der wichtigste Einzelhebel gegen diese Angriffsklasse.

3. Alle potenziell exponierten Geheimnisse rotieren. Tauschen Sie npm-Publish-Tokens, GitHub-Actions-Tokens, SSH-Schluessel sowie Cloud- und CI-Credentials aus, die auf betroffenen Runnern oder Entwickler-Rechnern lagen. Solange Sie nicht ausschliessen koennen, dass ein Token abgeflossen ist, muss es als kompromittiert gelten.

4. CI/CD-Berechtigungen einschnueren. Pruefen Sie, welche Workflows id-token: write besitzen, und reduzieren Sie diese Rechte auf das absolute Minimum. Trusted Publishing ist nicht per se falsch - aber jeder Workflow mit Publish-Recht ist ein potenzieller Brandherd.

Mittelfristig: die Lieferkette zur kontrollierten Zone machen

Die eigentliche Lehre aus Miasma ist strukturell. Drei Schichten muessen abgesichert werden: die Source-Schicht (welche Pakete ueberhaupt ins Unternehmen gelangen duerfen), die Build-Schicht (die Build-Umgebung darf keinen beliebigen Code ausfuehren und keine unnoetigen Secrets sehen) und die Runtime-Schicht (Überwachung auf unerwartete Netzwerkverbindungen).

Konkret bewaehrt haben sich: ein privates Artefakt-Repository (etwa Nexus oder Artifactory) als Proxy, das nur geprüfte Paketversionen durchlässt; eine Karenzzeit von 7 bis 14 Tagen, bevor neue Paketversionen produktiv übernommen werden - die meisten dieser Wurm-Wellen werden innerhalb weniger Tage entdeckt und zurückgezogen; sowie ein durchgängig gepflegtes Software Bill of Materials (SBOM), das jede direkte und transitive Abhängigkeit maschinenlesbar inventarisiert. Ohne ein solches Inventar lässt sich nach einem Vorfall nicht einmal beantworten, ob man betroffen ist.

Diese Massnahmen sind kein reines Entwicklerthema mehr. Mit dem Cyber Resilience Act und den Anforderungen aus NIS2 wird die Nachweisbarkeit der Software-Lieferkette zur regulatorischen Pflicht. Wer hier strukturiert vorgeht, erfuellt zwei Ziele gleichzeitig - er reduziert sein Risiko und seine Compliance-Last. Eine fundierte Informationssicherheits-Strategie betrachtet die Build-Pipeline deshalb heute als kritisches System, nicht als technisches Hinterzimmer.

Fazit

Miasma zeigt, dass die naechste Generation von Angriffen nicht mehr die Tuer aufbricht, sondern den Lieferweg vergiftet. Gueltige Signaturen, offizielle Namespaces und etablierte Sicherheitsmechanismen wie OIDC und SLSA bieten keinen Schutz mehr, wenn der Angreifer sie selbst bedient. Fuer den Mittelstand bedeutet das: Die Frage ist nicht mehr, ob man eine kompromittierte Abhaengigkeit einschleppt, sondern wie schnell man es bemerkt und wie wirksam man den Schaden begrenzt.

Wenn Sie unsicher sind, wie robust Ihre Build-Pipeline und Ihr Umgang mit Abhaengigkeiten aufgestellt sind, unterstuetzen wir Sie bei der Analyse und Absicherung. Ein Blick auf unsere Leistungen zeigt, wie wir sichere Entwicklung und Betrieb zusammendenken - sprechen Sie uns ueber das Kontaktformular an, bevor aus einer Abhaengigkeit ein Vorfall wird.