Miasma-Supply-Chain-Angriff: Schadcode in npm-Paketen von @redhat-cloud-services entdeckt

Am 1. Juni 2026 entdeckten Forschende Schadcode in mindestens 32 Paket-Releases, die unter dem npm-Namespace @redhat-cloud-services veröffentlicht wurden. Dabei handelt es sich um Frontend-Komponenten und API-Clients, die die Red Hat Hybrid Cloud Console antreiben. Die kompromittierten Releases enthalten ein preinstall-Skript, das unmittelbar nach der Installation eines Pakets eine verschleierte Payload ausführt. Diese sammelt Entwickler- und Cloud-Zugangsdaten und versucht, sich auf weitere Pakete auszubreiten, die das Opfer veröffentlichen kann. Die betroffenen Pakete kommen zusammen auf durchschnittlich rund 80.000 Downloads pro Woche. Die Reichweite geht somit weit über die Pipelines von Red Hat hinaus.

Die Kampagne erhielt den Namen Miasma. Ihre Payload ist eine leicht überarbeitete Variante des (Mini) Shai-Hulud-Wurms, den TeamPCP Anfang des Jahres als Open Source veröffentlicht hat. Wenn Sie ein @redhat-cloud-services-Paket installiert oder ein davon abhängiges Projekt erstellt haben, behandeln Sie dies als aktiven Sicherheitsvorfall und gehen Sie davon aus, dass alle Geheimnisse, auf die die betroffenen Rechner zugreifen konnten, offengelegt wurden.

Kurz zusammengefasst

• Was: Schadcode (sich selbst verbreitender Wurm und Zugangsdaten-Dieb) in veröffentlichten npm-Releases.

• Namespace: @redhat-cloud-services (Frontend-Komponenten und API-Clients der Red Hat Hybrid Cloud Console).

• Umfang: Mindestens 32 Paket-Releases im Namespace, zusammen rund 80.000 Downloads pro Woche. In zwei Wellen veröffentlicht.

• CVE: Keine zugewiesen. Erfasst über Snyk-Advisories. Snyk bewertet die führende Advisory mit 9,3 (Kritisch, CVSS v4.0); der Exploit-Reifegrad ist „Attacked“.

• Ursache: Über ein kompromittiertes GitHub-Konto eines Red-Hat-Mitarbeiters wurden schädliche verwaiste Commits eingespielt. Diese forderten ein OIDC-Token zum Veröffentlichen auf npm an und veröffentlichten Pakete mit gültiger SLSA-Provenienz.

• Status: Die meisten schädlichen Versionen waren innerhalb weniger Stunden nach Bekanntwerden von npm zurückgezogen worden; während der Analyse waren noch einige wenige verfügbar. Die Untersuchung läuft weiter.

• Maßnahmen: Wechseln Sie auf andere Versionen, installieren Sie mit deaktivierten Skripten neu und rotieren Sie alle Zugangsdaten, auf die eine betroffene Workstation oder ein CI-Runner zugreifen konnte.

Was ist passiert?

Die Pakete im Namespace @redhat-cloud-services sind Buildzeit-Abhängigkeiten der Hybrid Cloud Console: gemeinsam genutzte React-Komponenten (@redhat-cloud-services/frontend-components, frontend-components-utilities, frontend-components-notifications), generierte API-Clients (rbac-client, host-inventory-client, compliance-client und rund zwei Dutzend weitere) sowie unterstützende Tools. Mehrere davon verzeichnen selbst erhebliche Zugriffe. Zur schnellen Plausibilitätsprüfung des gemeldeten Umfangs zeigt die npm-Downloads-API, dass die größten Pakete, etwa @redhat-cloud-services/types, mehrere Zehntausend Downloads pro Woche erreichen:

1# https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes
2curl -s "https://api.npmjs.org/downloads/point/last-week/@redhat-cloud-services%2Ftypes"
3# {"downloads":15060, ... }

Die Summe der Downloads der betroffenen Pakete in der letzten vollständigen Woche (25. bis 31. Mai 2026) liegt bei rund 79.000 und entspricht damit der für diesen Vorfall genannten Zahl von etwa 80.000. Die nicht autorisierten Änderungen wurden erstmals am 1. Juni 2026 entdeckt.

Die schädlichen Releases wurden am 1. Juni in zwei Wellen veröffentlicht. Als die Advisories bekannt gegeben wurden, hatte npm die meisten schädlichen Versionen zurückgezogen; während der Analyse waren noch einige wenige verfügbar.

Technische Details

Der Installations-Trigger

Jedes kompromittierte Release fügt einen Installations-Hook hinzu. npm führt preinstall-Skripte automatisch während npm install aus, noch bevor Ihr eigener Code ausgeführt wird. Es reicht also bereits, die Abhängigkeit aufzulösen, um die Payload auszulösen:

1{
2  "scripts": {
3    "preinstall": "node index.js"
4  }
5}

Die aufgerufene index.js ist eine ungewöhnlich große, stark verschleierte JavaScript-Datei. Der Autor nutzte eval() und eine ROT-basierte Zeichenfolgendekodierung, um die Logik zu verbergen – ein Vorgehen, das bereits bei früheren Shai-Hulud-Varianten zu beobachten war. Entschlüsselt zeigt sich eine mehrstufige Payload zum Sammeln von Zugangsdaten und zur Verbreitung des Wurms.

Was die Payload bewirkt

Der funktionale Kern entspricht dem (Mini) Shai-Hulud-Framework, allerdings wurden die kosmetischen Elemente mit Bezug zur griechischen Mythologie anstelle der ursprünglichen Dune-Thematik verwendet (etwa die Verwendung von spartan). Neu erstellte Repositories der Angreifer tragen die Beschreibung Miasma: The Spreading Blight – ein nützlicher Hinweis für die Suche.

Bei der Ausführung führt die Payload Folgendes aus:

• Sammelt Geheimnisse und Zugangsdaten aus der lokalen Umgebung und dem CI-Kontext: Umgebungsvariablen, ~/.npmrc-Token, SSH-Schlüssel, GitHub-Token und CI/CD-Geheimnisse.

• Ermittelt Cloud-Identitäten. Die bemerkenswerte Neuerung dieser Variante sind zwei neue Sammler für GCP und Azure. Sie ermitteln alle Identitäten, die der infizierte Host annehmen kann, nicht nur statische Geheimnisse. Frühere Varianten konzentrierten sich auf das Auslesen von Zugangsdaten. Diese Variante zielt darauf ab, die Cloud-Control-Plane selbst zu kartieren und zu erreichen.

• Verbreitet sich selbst. Der Wurm fragt die Registry nach weiteren Paketen ab, die die kompromittierte Identität veröffentlichen kann, und veröffentlicht sie mit derselben Payload erneut. So wird aus einem kompromittierten Maintainer ein Wurm.

Ursache: kompromittiertes Konto, gültige Provenienz

Bei diesem Detail lohnt es sich, genauer hinzuschauen. Der Schadcode gelangte nicht über Typosquatting oder eine manipulierte transitive Abhängigkeit in die Pakete. Die Belege deuten darauf hin, dass das GitHub-Konto eines Red-Hat-Mitarbeiters kompromittiert und dazu verwendet wurde, schädliche verwaiste Commits direkt in zwei RedHatInsights-Repositories einzuspielen – unter Umgehung der Codeprüfung.

Diese Commits fügten einen minimalen GitHub-Actions-Workflow hinzu, der:

1. bei einem Push auf jeden Branch ausgelöst wurde.

2. über id-token: write ein GitHub-OIDC-Identitätstoken anforderte.

3. eine verschleierte Payload (_index.js) ausführte, die die Pakete auf npm veröffentlichte.

Da die Veröffentlichung im Actions-Kontext eines legitimen Repositorys erfolgte, wurden die Releases mit gültigen SLSA-Provenienzbescheinigungen ausgeliefert. Die Provenienz war technisch korrekt: Das Paket wurde tatsächlich vom Workflow dieses Repositorys erstellt. Sie konnte jedoch nicht zeigen, dass der Workflow selbst nicht autorisiert war. Dieselbe Schwachstelle nutzte TeamPCP wenige Wochen zuvor gegen TanStack aus: Gefälschte, aber gültige Provenienz ermöglichte es schädlichen Paketen, eine oberflächliche Prüfung zu bestehen. Auch der Token-Diebstahl auf Runner-Seite bei der Kompromittierung der Trivy-GitHub-Action weist Parallelen auf. Die Überprüfung der Provenienz ist notwendig, reicht allein aber nicht aus.

Auswirkungsanalyse

Die direkten Downloadzahlen unterschätzen das tatsächliche Ausmaß der Gefährdung. Diese Pakete sind Buildzeit-Abhängigkeiten einer Enterprise-Konsole. Die meisten Installationen erfolgen daher auf Entwickler-Workstations und CI-Runnern – genau den Umgebungen mit besonders vielen langlebigen Cloud-Zugangsdaten, Registry-Token und GitHub-PATs. Das Wurmverhalten verschärft die Lage zusätzlich: Ein einzelner Entwickler, der eine betroffene Version installiert hat und Veröffentlichungsrechte für andere Pakete besitzt, kann die nächste Welle auslösen.

Sie sind möglicherweise betroffen, wenn seit der ersten schädlichen Veröffentlichung am 1. Juni 2026 eines der folgenden Ereignisse eingetreten ist:

• Auf einer Workstation oder einem CI-Runner wurde ein npm install / npm ci ausgeführt, bei dem eine betroffene Version von @redhat-cloud-services aufgelöst wurde.

• Ein Build wurde in einer Cloud-Umgebung ausgeführt, in der der Runner GCP-, AWS- oder Azure-Identitäten hatte – insbesondere angesichts der neuen Sammler für Cloud-Identitäten.

Für einen Angriff ist keine besondere Konfiguration auf Ihrer Seite erforderlich. Der preinstall-Hook wird standardmäßig ausgeführt. Voraussetzung ist lediglich, dass Sie eine betroffene Version installiert haben.

Erkennung

1. Finden Sie betroffene Versionen in Ihren Lockfiles. Durchsuchen Sie package-lock.json / pnpm-lock.yaml / yarn.lock nach dem Namespace:

1grep -r "@redhat-cloud-services" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

Vergleichen Sie die aufgelösten Versionen mit den Snyk-Advisories im Abschnitt „Referenzen“. Die führende Snyk-Advisory weist für @redhat-cloud-services/frontend-components die Versionen <=7.7.2 als betroffen aus. Die Versionsgrenzen unterscheiden sich je nach Paket; prüfen Sie daher jede Advisory.

2. Führen Sie einen Scan mit Snyk durch. Die Snyk-Datenbank enthält bereits Advisories zu den schädlichen Releases, sodass ein standardmäßiger Test sie erkennt:

1snyk test --file=package-lock.json

Für Unternehmen helfen die Erkennung von Assets und die risikobasierte Priorisierung dabei, jedes Projekt und jeden Runner zu finden, auf dem eine betroffene Version installiert wurde. Anschließend lässt sich die Behebung danach priorisieren, wie stark die jeweilige Umgebung Zugangsdaten offenlegen kann, statt jeder Installation gleichermaßen nachzugehen.

3. Suchen Sie nach Spuren einer Kompromittierung. Die Payload kann bereits ausgeführt worden sein, auch wenn Sie das Paket entfernt haben. Achten Sie auf:

• neue, unerwartete Repositories in Ihrer GitHub-Organisation, insbesondere solche mit der Beschreibung Miasma: The Spreading Blight.

• nicht erkannte GitHub-Actions-Workflows, vor allem minimale Workflows, die id-token: write anfordern und bei einem Push auf jeden Branch ausgelöst werden.

• neu erstellte persönliche Zugriffstoken, Deploy-Schlüssel oder npm-Token, die Sie nicht angelegt haben.

• ungewöhnliche Zugriffe von Build-Runnern auf Metadaten zu GCP- und Azure-Identitäten.

Behebung

Die Reihenfolge ist wichtig. Da diese Malware-Familie dafür bekannt ist, Persistenzmechanismen einzurichten und bei einigen Varianten destruktive Trigger zu setzen, bereinigen Sie den Host, bevor Sie mit dem Widerruf der Token beginnen, nach denen die Malware sucht.

1. Beenden Sie die Installation schädlicher Versionen. Fixieren oder überschreiben Sie Ihre Abhängigkeiten mit bekannten sicheren Releases oder entfernen Sie die betroffenen Pakete vorübergehend. Prüfen Sie anschließend, ob Ihr Lockfile keine gekennzeichnete Version mehr auflöst.

2. Installieren Sie mit deaktivierten Skripten neu. Wenn Sie einen potenziell betroffenen Abhängigkeitsbaum neu erstellen, blockieren Sie Installationsskripte, damit eine verbliebene schädliche Version nicht erneut ausgeführt werden kann:

1rm -rf node_modules
2npm install --ignore-scripts

Sie können dies als Standard für eine Umgebung festlegen:

1npm config set ignore-scripts true

(Aktivieren Sie Skripte nur für Pakete wieder, die tatsächlich Build-Schritte benötigen.)

3. Entfernen Sie Persistenzmechanismen. Prüfen und bereinigen Sie alle von Angreifern hinterlassenen Hooks, bevor Sie Zugangsdaten ändern. Prüfen Sie Editor- und Agent-Konfigurationen wie .claude/settings.json und .vscode/tasks.json.

4. Rotieren Sie alle erreichbaren Zugangsdaten. Gehen Sie davon aus, dass alle Geheimnisse offengelegt wurden, auf die ein betroffener Rechner zugreifen konnte, und rotieren Sie sie in der Reihenfolge ihrer Priorität: npm-Token, GitHub-PATs und SSH-Schlüssel, danach Cloud-Zugangsdaten. Achten Sie angesichts der neuen Sammler besonders auf Cloud-Identitäten wie GCP, AWS und Azure, einschließlich aller Rollen, die ein CI-Runner annehmen konnte, und nicht nur auf statische Schlüssel.

5. Bereinigen Sie GitHub. Löschen Sie nicht autorisierte Repositories und Workflows, prüfen Sie aktuelle Actions-Ausführungen auf das oben beschriebene OIDC-Veröffentlichungsmuster und stellen Sie sicher, dass unter Ihren Konten keine unerwarteten Pakete veröffentlicht wurden.

6. Sichern Sie Ihre Pipeline ab. Ergreifen Sie künftig folgende Maßnahmen: Erzwingen Sie Codeprüfungen für geschützte Branches, damit verwaiste Commits keine Veröffentlichungen auslösen können. Beschränken Sie das Vertrauen in OIDC auf bestimmte Branches und Workflows statt auf ganze Repositories. Verlangen Sie für npm 2FA mit Veröffentlichungsschutz und kombinieren Sie die Überprüfung der Provenienz mit Verhaltensprüfungen, statt allein auf Bescheinigungen zu vertrauen. Eine Zulassungsliste für Abhängigkeiten, die SBOM-Erstellung und eine Wartezeit vor der Übernahme neuer Releases verringern das Zeitfenster, auf das sich solche Angriffe stützen. Weitere Empfehlungen finden Sie in den 10 Best Practices für npm-Sicherheit und den 8 Tipps zum Absichern Ihrer CI/CD-Pipeline von Snyk.

Zeitachse

• 1. Juni 2026: Schädliche Releases in einer ersten Welle im Namespace @redhat-cloud-services veröffentlicht.

• 1. Juni 2026 (ca. 13:00 Uhr UTC): Kompromittierung öffentlich bekannt gegeben; die meisten schädlichen Versionen zurückgezogen, zwei noch verfügbar.

• 1. Juni 2026 (ca. 14:00 Uhr UTC): Ursache veröffentlicht: kompromittiertes Mitarbeiterkonto, per OIDC veröffentlichte Pakete mit gültiger SLSA-Provenienz.

• 1. Juni 2026 (ca. 14:20–15:00 Uhr UTC): Eine zweite Welle schädlicher Commits entdeckt und in die Abdeckung aufgenommen. Zudem wurden Details zu den neuen Sammlern für GCP- und Azure-Identitäten in der Payload bekannt.

• 2. Juni 2026: Neu entdeckte kompromittierte Versionen bestehender Pakete hinzugefügt.

• Andauernd: Snyk-Advisories zu den betroffenen Paketen sind verfügbar. Die Untersuchung wird fortgesetzt.