Miasma: The Spreading Blight — wenn ein vertrauenswürdiger npm-Namespace zur Lieferkette für einen Cloud-Identitäts-Wurm wird

TL;DR — die 90-Sekunden-Zusammenfassung

Was ist passiert?

Am 01.06.2026 wurden 32 Pakete im npm-Scope @redhat-cloud-services mit einem Credential-Stealing-Wurm kompromittiert (JFrog analysierte 31 bösartige Versionen; aggregierte Zählungen nennen bis zu 96 Versionen). Die Kampagne „Miasma: The Spreading Blight“ ist eine Variante des von TeamPCP open-sourcten Mini-Shai-Hulud. Patient Zero: ein kompromittierter Red-Hat-Mitarbeiter-GitHub-Account, der Orphan-Commits an zwei RedHatInsights-Repos pushte (Review-Bypass); die Veröffentlichung lief über GitHub-Actions-OIDC-Trusted-Publishing. Reichweite: ~80.000 (Wiz) bis ~116.991 (aggregiert) wöchentliche Downloads. Red Hat bestätigt den Vorfall und hat die Pakete aus npm entfernt.

Wie schwer?

Kritisch (operative Einschätzung — kein CVE/CVSS für diese Vorfallsklasse). Automatische Ausführung über preinstall vor jedem Anwendungscode, breiter Credential-Sweep (GitHub/AWS/GCP/Azure/Kubernetes/Vault/npm/SSH/Docker/GPG/.env), Persistenz auf Linux und macOS, Hooks in KI-Entwickler-Tools — und ein destruktiver Dead-Man-Switch, der bei Token-Entzug das Home-Verzeichnis löschen kann.

Welche Pakete / Versionen?

32 Pakete im @redhat-cloud-services-Scope, jeweils eine einzelne bösartige Patch-Version (u. a. frontend-components 7.7.2, rbac-client 9.0.3, host-inventory-client 5.0.3, sowie die drei MCP-Pakete hcc-pf-mcp 0.6.1, hcc-feo-mcp 0.3.1, hcc-kessel-mcp 0.3.1). Vollständige IOC-Liste in der Detection-Sektion.

Bin ich als Moselwal-Kunde betroffen?

Betroffen sind Sie, wenn ein Build, ein CI-Lauf oder eine Entwickler-Workstation seit dem 01.06.2026 eine der gelisteten Versionen installiert hat — direkt oder transitiv. Die Red-Hat-Insights-/Cloud-Services-Frontend-Pakete stecken in vielen OpenShift-/RHEL-nahen Frontends und Plugins. Prüfung: npm ls @redhat-cloud-services bzw. ein Lockfile-Grep über den Bestand.

Sofort-Mitigation?

Reihenfolge ist sicherheitskritisch: (1) betroffene Maschine vom Netz isolieren, (2) Persistenz entfernen (kitty-monitor / gh-token-monitor), (3) erst danach alle Credentials rotieren. Token-Entzug vor Persistenz-Entfernung kann den Dead-Man-Switch auslösen. In CI-Pipelines als Stopgap npm ci --ignore-scripts.

Kritikalität?

Siehe Hero-Badge critical (operative Einschätzung, kein offizieller CVSS). Aktive In-the-wild-Verteilung am Disclosure-Tag, destruktiver Payload — oberes Ende des Handlungsdrucks.

 

Was ist passiert

Am 1. Juni 2026 haben mehrere Forschungsteams unabhängig voneinander eine Kompromittierung im npm-Scope @redhat-cloud-services gemeldet. Wiz Research identifizierte mindestens 32 Paket-Releases mit unautorisierten Modifikationen, die nicht zu den zugehörigen Quell-Repositories passen; Aikido und JFrog bestätigten das Bild über mehr als 30 Pakete. Die betroffenen Pakete sind keine Typosquats, sondern die echten, vertrauenswürdigen Pakete unter einem offiziellen, breit genutzten Namespace — Frontend-Komponenten, API-Clients und Entwickler-Tooling aus dem Red-Hat-Cloud-Services-/Insights-Umfeld.

Der entscheidende Punkt für die Einordnung ist die Initialkompromittierung. Nach Analysen von OX Security war Patient Zero ein kompromittierter Red-Hat-Mitarbeiter-GitHub-Account, der bösartige Orphan-Commits an zwei RedHatInsights-Repositories pushte und damit das Code-Review umging. Die anschließende Veröffentlichung der Pakete lief über GitHub-Actions-OIDC-Trusted-Publishing — der Wurm fordert in GitHub-Actions-Umgebungen über ACTIONS_ID_TOKEN_REQUEST_TOKEN/ACTIONS_ID_TOKEN_REQUEST_URL ein OIDC-Token für registry.npmjs.org an, tauscht es bei der npm-Registry und publiziert unter der so erhaltenen Identität, inklusive Sigstore-Signatur. Das heißt: nicht ein einzelner Maintainer hat sein Passwort verloren, sondern die Build- und Identitäts-Schicht selbst wurde unterwandert. Genau das macht die Pakete für klassische Provenance-Prüfungen so tückisch — Provenance belegt, wo gebaut wurde, nicht, dass die Build-Umgebung sauber war.

Red Hat hat den Vorfall öffentlich bestätigt: man sei sich der Berichte zu npm-Paketen im eigenen Entwicklungs-Tooling-Ökosystem bewusst, habe sofort eine Untersuchung eingeleitet und die Pakete aus dem npm-Registry entfernt; die Kompromittierung sei auf internes Entwicklungs-Tooling begrenzt gewesen. Der erste Commit mit dem String „Miasma: The Spreading Blight“ datiert laut OX Security bereits auf den 29. Mai 2026 — die Variante war also entweder seit einigen Tagen aktiv oder wurde ab dann getestet, bevor die breite Welle am 1. Juni sichtbar wurde.

Jedes kompromittierte Paket deklariert in seiner package.json einen preinstall-Hook, der bei jeder Installation automatisch node index.js ausführt — bevor irgendein Anwendungscode läuft. JFrog hebt ein starkes Eigen-Signal hervor: das analysierte Sample war @redhat-cloud-services/types 3.6.1, ein reines Typ-Paket — und ein Typ-Paket hat normalerweise keinen Grund, vor der Installation einen JavaScript-Installer laufen zu lassen. Die index.js ist ein 4,2 MB großes Obfuskat: die erste Stufe rekonstruiert JavaScript aus einem großen numerischen Zeichen-Array, wendet eine ROT-artige Transformation an und evaluiert das Ergebnis; danach entschlüsselt sie zwei AES-128-GCM-Blobs (einen kleinen Bun-Bootstrapper unter /tmp/b*.js und das eigentliche Payload unter /tmp/p*.js, mit Bun ausgeführt und anschließend gelöscht). Fehlt Bun, lädt der Bootstrapper es aus den GitHub-Releases nach (bun-v1.3.13). Neu in dieser Welle: laut Wiz erzeugt der Wurm pro Infektion ein eindeutig verschlüsseltes Payload, was Detection und Versions-Tracking deutlich erschwert.

Technische Einordnung

Strukturell ist Miasma ein Lehrstück darüber, was passiert, wenn die Installations-Phase selbst zur Angriffsfläche wird. Der preinstall-Hook läuft mit den Rechten des installierenden Nutzers, ohne Sandbox, vor jedem geprüften Anwendungscode. Auf einer Workstation ist das der angemeldete Mensch mit SSH-Keys, Cloud-Profilen und Token-Caches; auf einem CI-Runner der Build-Identitäts-Kontext mit OIDC-Token, Registry-Credentials und Secret-Store-Zugriff. Der Wurm nutzt beides.

Der Credential-Sweep ist breit und systematisch. Auf der CI-Seite zielt er auf GitHub-Actions-Secrets inklusive GITHUB_TOKEN und ACTIONS_RUNTIME_TOKEN — und liest GitHub-Actions-Secrets laut JFrog direkt aus dem Laufzeit-Prozessspeicher, womit das Log-Masking umgangen wird. Für Cloud-Credentials sammelt er AWS-Access-Keys und Session-Token, GCP Application-Default-Credentials und Service-Account-Key-Dateien sowie Azure-Service-Principal- und Managed-Identity-Token. Dazu kommen HashiCorp-Vault-Token, Kubernetes-Service-Account-Token und kubeconfig-Dateien, npm- und PyPI-Publish-Token, SSH-Private-Keys, Docker-Registry-Credentials, GPG-Keys und jede .env-Datei im Dateisystem. Wo die Berechtigungen es zulassen, fragt der Wurm aktiv die Secret-Stores ab: AWS Secrets Manager, SSM Parameter Store, Azure Key Vault und GCP Secret Manager.

Die neue Note dieser Welle sind laut Wiz die zusätzlichen Sammler für GCP- und Azure-Cloud-Identitäten. Frühere Versionen extrahierten primär Secrets; diese Variante sammelt zusätzlich alle Identitäten, auf die die infizierte Maschine Zugriff hat. Der Fokus verschiebt sich vom Secret-Diebstahl zum Zugriff auf die Cloud selbst.

Bemerkenswert für unseren Kontext ist eine Tarn-Technik: der Exfiltrations-Verkehr wird nach api.anthropic.com/v1/api verschleiert — eine legitim aussehende Domain, die sich in den Netz-Logs von Organisationen einfügt, die Anthropic-Dienste nutzen. Der Pfad /v1/api ist keine gültige Anthropic-Route (ein GET liefert ein Anthropic-typisches 404 not_found_error); die Angreifer haben ihn rein zur Camouflage gewählt. Wir halten ausdrücklich fest: das ist eine Missbrauchs-Tarnung des Domain-Namens, kein Hinweis auf eine Kompromittierung bei Anthropic.

Über die reine Sammlung hinaus zeigt der Wurm aktive Tradecraft. Er prüft vor dem Losschlagen auf Endpoint-Schutz (CrowdStrike, SentinelOne, Carbon Black, StepSecurity Harden-Runner) und vermeidet die Ausführung auf russischsprachigen Systemen — ein Muster, das auch aus den GlassWorm-Kampagnen bekannt ist. Auf CI-Runnern versucht er eine Privilege-Escalation, indem er einen Container startet, der das Host-Verzeichnis /etc/sudoers.d einbindet und dem Runner passwortloses sudo gewährt. Auf GitHub manipuliert er Actions: er committet Workflows über die createCommitOnBranch-Mutation, sodass die Änderung als verifizierter, signierter Commit erscheint, wandelt JavaScript-Actions in Composite-Actions um, die Bun installieren und das Payload ausführen, und injiziert Workflows, die Repository-Secrets als Build-Artefakte exponieren. Die npm-Weiterverbreitung ist eine kleine, wirksame Mutation: scripts.preinstall auf bun run index.js, dependencies.bun auf ^1.3.13, Patch-Version um eins erhöht, neu publiziert. Genau diese Mutation ist die „spreading blight“ — ein gestohlenes npm-Publish-Token wird zum Startpunkt der nächsten Welle.

Zur Persistenz nutzt der Wurm ein GitHub-Dead-Drop-Modell: öffentliche Repos mit der Beschreibung Miasma: The Spreading Blight (Repo-Name nach <adjektiv>-<nomen>-<zahl>-Muster), gestohlene Credentials als results/results-*.json. Enthält ein Commit ein Token, trägt er den Drohmarker IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner. Er installiert kitty-monitor.service (Linux) bzw. com.user.kitty-monitor.plist (macOS), injiziert Hooks in KI-Entwickler-Tools (Claude, Codex, Gemini, Copilot, Kiro, opencode) und fügt VS-Code-Folder-Open-Tasks hinzu. Und er installiert einen destruktiven gh-token-monitor: wird ein gestohlenes GitHub-Token entzogen, bevor die Persistenz entfernt ist, kann er destruktive Kommandos ausführen — bis hin zum Löschen des Home-Verzeichnisses. Daraus folgt die einzige nicht verhandelbare Reihenfolge: erst isolieren und Persistenz entfernen, dann Token entziehen.

Wer ist betroffen

Der unangenehme Teil ist die Transitivität. Die Red-Hat-Cloud-Services-Frontend-Komponenten landen als indirekte Abhängigkeit in größeren Frontends und Plugins — niemand installiert @redhat-cloud-services/frontend-components-utilities bewusst, es kommt mit. Ein npm ls über den gesamten Bestand ist deshalb aussagekräftiger als die Erinnerung daran, was man „direkt benutzt“. Die drei MCP-Pakete (hcc-pf-mcp, hcc-feo-mcp, hcc-kessel-mcp) sind ein eigener Trigger für alle, die MCP-Server in ihre Agent-Setups einbinden.

Auswirkungen und Sofortmaßnahmen

Die Auswirkung ist nicht „ein kompromittiertes Paket“, sondern „ein kompromittierter Identitäts-Perimeter“. Wer eine der Versionen auf einer Maschine mit Cloud-Zugriff installiert hat, muss davon ausgehen, dass die dort erreichbaren GitHub-, AWS-, GCP-, Azure-, Kubernetes- und Vault-Credentials abgeflossen sind — und in dieser Welle zusätzlich die Cloud-Identitäten selbst. Das hebt den Vorfall von „Secret-Rotation“ auf „Identitäts- und Berechtigungs-Review“. Der Wurm-Charakter verschärft das: ein abgeflossenes npm-Publish-Token ist ein potenzieller Startpunkt für die nächste Welle bei einem anderen Maintainer. Und der destruktive gh-token-monitor macht aus der Standard-Reaktion „Token sofort entziehen“ eine potenzielle Selbstschädigung, wenn sie in der falschen Reihenfolge erfolgt.

Operational Decision Block

• Sofort und in dieser Reihenfolge handeln, wenn eine gelistete Version auf einer Maschine mit Cloud-/CI-Credentials installiert wurde: (1) Maschine vom Netz isolieren, (2) Persistenz (kitty-monitor, gh-token-monitor) entfernen, (3) erst danach Credentials rotieren, (4) Runner/Workstation aus sauberem Image neu bauen.
• Kontrolliert im Wartungsfenster, wenn der Scope nur in einer hermetischen Build-Stufe ohne erreichbare Credentials vorkam und Lockfiles die bösartigen Versionen nie gezogen haben: Lockfile-Audit, Pin auf saubere Versionen, kein Credential-Reset nötig.
• Kein akuter Druck, wenn kein @redhat-cloud-services-Paket im Dependency-Baum liegt: Scope-Grep zur Bestätigung, Install-Script-Disziplin als Vorsorge prüfen.

Reihenfolge im Detail. Erstens, Inventur: npm ls @redhat-cloud-services und ein Grep über alle Lockfiles gegen die IOC-Versionsliste (Detection-Sektion). Zweitens, Isolation vor allem anderen: jede getroffene Maschine vom Netz nehmen, bevor irgendein Token angefasst wird — der Dead-Man-Switch macht die Reihenfolge nicht verhandelbar. Drittens, Persistenz entfernen: kitty-monitor- und gh-token-monitor-Dateien löschen; injizierte Hooks in .claude/settings.json, .vscode/tasks.json und ~/.config/index.js prüfen. Viertens, Pakete entfernen und Lockfiles aus vertrauenswürdigen Metadaten regenerieren, auf saubere Versionen pinnen. Fünftens, Credentials rotieren — erst jetzt: alle exponierten GitHub-, npm-, AWS-/GCP-/Azure-, Kubernetes-Service-Account-, SSH-, Vault- und Docker-Credentials, nachdem die Persistenz bestätigt entfernt ist. Sechstens, Runner und Workstations aus sauberen Images neu bauen. Stopgap für CI:npm ci --ignore-scripts, bis der Bestand sauber ist.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Detection / Prüfung

Die Detection hat zwei Ebenen: „habe ich eine bösartige Version installiert“ (Lockfile-/Inventar-Frage) und „läuft auf der Maschine bereits Persistenz oder Exfiltration“ (Endpoint-/Netz-Frage). Beide prüfen.

Indicators of Compromise (Stand 01.06.2026, verifiziert gegen die JFrog-IOC-Sektion):

• Kampagnen-Marker / Dead-Drop-Repos: Beschreibung Miasma: The Spreading Blight; Ergebnis-Dateien results/results-*.json; Token-Drohmarker IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner; Commit-Messages chore: update dependencies [skip ci], fix: ci.
• Netz-IOCs:api.anthropic.com/v1/api (Port 443, Pfad liefert 404 — Camouflage); api.github.com/search/commits?q=firedalazer (kitty-monitor-C2); GCP-User-Agent google-api-nodejs-client/7.0.0 gl-node/20.11.0 gccl/7.0.0.
• File-Hashes (SHA-256, Sample types 3.6.1):7069e28a5806db4ab0273639667d203f5e31b401d403af7e36d9f360c1f6d655 (Paket-Metadaten), b86c5ae9e95bd841a595440faa3eb6317441e746f241ae8fd641ab59ed1d1966 (Install-Loader).
• Loader-/Bun-Artefakte:/tmp/p*.js, /tmp/b-*/bun, /tmp/b-*/b.zip, /tmp/.bun_ran.
• kitty-monitor-Persistenz:~/.config/systemd/user/kitty-monitor.service, ~/.local/share/kitty/cat.py, ~/Library/LaunchAgents/com.user.kitty-monitor.plist, /var/tmp/.gh_update_state.
• gh-token-monitor-Persistenz (Dead-Man-Switch):~/.config/gh-token-monitor/token, ~/.config/gh-token-monitor/handler, ~/.local/bin/gh-token-monitor.sh.
• Injizierte Hooks:.claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .github/setup.js, ~/.config/index.js.

Betroffene Pakete und bösartige Versionen (32 Pakete, IOC-Liste):

@redhat-cloud-services/chrome 2.3.1
@redhat-cloud-services/compliance-client 4.0.3
@redhat-cloud-services/config-manager-client 5.0.4
@redhat-cloud-services/entitlements-client 4.0.11
@redhat-cloud-services/eslint-config-redhat-cloud-services 3.2.1
@redhat-cloud-services/frontend-components 7.7.2
@redhat-cloud-services/frontend-components-advisor-components 3.8.2
@redhat-cloud-services/frontend-components-config 6.11.3
@redhat-cloud-services/frontend-components-config-utilities 4.11.2
@redhat-cloud-services/frontend-components-notifications 6.9.2
@redhat-cloud-services/frontend-components-remediations 4.9.2
@redhat-cloud-services/frontend-components-testing 1.2.1
@redhat-cloud-services/frontend-components-translations 4.4.1
@redhat-cloud-services/frontend-components-utilities 7.4.1
@redhat-cloud-services/hcc-feo-mcp 0.3.1
@redhat-cloud-services/hcc-kessel-mcp 0.3.1
@redhat-cloud-services/hcc-pf-mcp 0.6.1
@redhat-cloud-services/host-inventory-client 5.0.3
@redhat-cloud-services/insights-client 4.0.4
@redhat-cloud-services/integrations-client 6.0.4
@redhat-cloud-services/javascript-clients-shared 2.0.8
@redhat-cloud-services/notifications-client 6.1.4
@redhat-cloud-services/patch-client 4.0.4
@redhat-cloud-services/quickstarts-client 4.0.11
@redhat-cloud-services/rbac-client 9.0.3
@redhat-cloud-services/remediations-client 4.0.4
@redhat-cloud-services/rule-components 4.7.2
@redhat-cloud-services/sources-client 3.0.10
@redhat-cloud-services/topological-inventory-client 3.0.10
@redhat-cloud-services/tsc-transform-imports 1.2.2
@redhat-cloud-services/types 3.6.1
@redhat-cloud-services/vulnerabilities-client 2.1.8

Prüf-Snippets (Copy/Paste):

# 1) Ist der Scope überhaupt im Baum?
npm ls @redhat-cloud-services 2>/dev/null || true

# 2) Persistenz-Artefakte auf der Maschine?
systemctl --user list-units 'kitty-monitor*' 2>/dev/null
ls -la ~/Library/LaunchAgents/com.user.kitty-monitor.plist 2>/dev/null
ls -la /tmp/p*.js 2>/dev/null
grep -RIl 'Miasma' ~/.config ~/.claude ~/.vscode 2>/dev/null

# 3) CI-seitig: Hooks deaktivieren (Stopgap)
npm ci --ignore-scripts

Auf GitHub-Org-Ebene: Audit-Log auf neu angelegte Repos mit Beschreibung Miasma: The Spreading Blight und auf unerwartete Patch-Version-Publishes unter eigenen npm-Scopes prüfen. JFrog erkennt die Pakete über Xray (je Paket eine XRAY-ID).

Betreiberempfehlung

Mittelstand

Für mittelständische Teams ohne dediziertes IR-Team ist die wichtigste Botschaft die Reihenfolge: nicht reflexhaft Token rotieren, sondern erst die Maschine isolieren und die Persistenz entfernen. Praktisch: betroffene Workstation oder Runner vom Netz, kitty-monitor/gh-token-monitor entfernen, dann erst rotieren. Wer keinen reproduzierbaren Build hat, baut die Maschine im Zweifel neu auf — das ist schneller und sicherer als das vollständige Aufräumen eines aktiven Wurms.

Enterprise

Größere Organisationen sollten den Identitäts-Blast-Radius prüfen: welche Cloud-Identitäten und Berechtigungen hingen an den Maschinen, die seit dem 01.06. gebaut haben? Die neuen GCP-/Azure-Identitäts-Sammler machen aus dem Vorfall einen Anlass für ein Berechtigungs-Review, nicht nur eine Secret-Rotation. Dass GitHub-Actions-Secrets aus dem Prozessspeicher gelesen werden, bedeutet zudem: Log-Masking war als Kontrolle hier wertlos — ein Argument für kurzlebige, scoped OIDC-Federation statt langlebiger Secrets im Runner.

Kubernetes / deklarative Stacks

Wo @redhat-cloud-services-Komponenten in OpenShift-Konsolen-Plugins oder Frontend-Builds stecken, gehört die Prüfung in die Image-Build-Spur: betroffene Layer identifizieren, Base-/App-Image neu bauen, nicht den laufenden Container patchen. Kubernetes-Service-Account-Token und kubeconfigs, die in betroffenen CI-Kontexten erreichbar waren, sind als kompromittiert zu behandeln und nach der Persistenz-Entfernung zu rotieren.

Was wir konkret getan haben — und das Fazit

Wir haben für die von uns betreuten Plattformen zuerst die einfache Frage beantwortet: liegt der @redhat-cloud-services-Scope irgendwo im Dependency-Baum? Über die SBOM-Inventur und einen Lockfile-Grep gegen die IOC-Versionsliste lässt sich das in Minuten pro Stack klären. Für Build-Pipelines haben wir als Sofort-Stopgap --ignore-scripts gesetzt, damit kein preinstall-Hook mehr läuft, bevor der Bestand verifiziert ist.

Methodisch bestätigt Miasma drei Linien, die wir ohnehin fahren. Erstens, Install-Scripts sind kein Implementierungsdetail, sondern Angriffsfläche — Lifecycle-Hooks gehören in CI standardmäßig deaktiviert. Zweitens, Provenance allein reicht nicht: schon die @tanstack-Welle zeigte, dass valide SLSA-attestierte Pakete bösartig sein können, wenn die Pipeline übernommen wird; Miasma bestätigt das über OIDC-Trusted-Publishing. Drittens, Build-Identitäten kurzlebig und scoped halten — ein Runner mit langlebigen Cloud-Keys und npm-Publish-Token ist der maximale Blast-Radius. Den destruktiven Dead-Man-Switch nehmen wir als Anlass, unsere IR-Runbooks zu schärfen: „Isolieren vor Rotieren“ ist ab sofort die dokumentierte Default-Reihenfolge für Wurm-Vorfälle mit Persistenz.

Fazit. Miasma ist keine Lücke in einem Stück Code, sondern die wiederholte Demonstration, dass die npm-Lieferkette selbst zum Verbreitungsmedium geworden ist — diesmal über einen offiziellen, vertrauenswürdigen Namespace, eine übernommene Build-Identität und einen Payload, der Cloud-Identitäten gleich mitnimmt. Die operativ wichtigste Lehre ist unspektakulär und rettet im Ernstfall die Maschine: erst isolieren und Persistenz entfernen, dann rotieren. Die strukturelle Lehre ist die alte, jetzt erneut bestätigte: Install-Scripts deaktivieren, Provenance nicht für Sicherheit halten, Build-Identitäten kurzlebig und scoped halten. Risiko nüchtern: kritisch für jeden, der seit dem 01.06. eine betroffene Version mit Credentials im Zugriff installiert hat; ein reiner Inventar- und Disziplin-Anlass für alle anderen.

Quellen

• JFrog Security Research — Shai-Hulud „Miasma: The Spreading Blight“ Hits Red Hat npm Packages (01.06.2026; Loader-Kette, Bun-Staging, OIDC-Trusted-Publishing, vollständige IOC-/XRAY-Tabelle, File-Hashes)
• Wiz Research — Miasma: Supply Chain Attack Targeting RedHat npm Packages (01.06.2026; Affected-Packages-Tabelle, GCP-/Azure-Identitäts-Sammler)
• Aikido — Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm (01.06.2026)
• The Hacker News — Miasma Supply Chain Attack Compromises Red Hat npm Packages (01.06.2026; Patient Zero, Quellen-Synopse)
• BleepingComputer — Red Hat npm packages compromised to steal developer credentials (01.06.2026; Red-Hat-Statement)