Aikido Security, StepSecurity, Wiz und OX Security berichten über kompromittierte npm-Pakete im Scope @redhat-cloud-services. Aikido nennt 32 betroffene Pakete und 96 kompromittierte Versionen. StepSecurity beschreibt einen mehrstufigen Credential-Harvester, der bereits bei npm install startet und Zugangsdaten aus Entwicklerumgebungen, CI/CD-Systemen und Cloud-Konten sucht. Für Software-Entwicklung ist der Fall relevant, weil vertrauenswürdige Pakete einer bekannten Enterprise-Marke als Angriffspfad in Build-Pipelines genutzt wurden. Der Vorfall wurde am 1. Juni 2026 öffentlich dokumentiert. Nach Angaben von Aikido wurden die Pakete über GitHub Actions OIDC veröffentlicht. Das spricht gegen einen einfachen Diebstahl eines npm-Publish-Tokens und für eine kompromittierte CI/CD-Kette. Aikido empfiehlt Entwicklern, nach einer Installation betroffener Versionen alle CI-Secrets, Cloud-Zugangsdaten, SSH-Schlüssel und npm-Tokens als kompromittiert zu behandeln.
Sicherheitsfirmen melden Malware in @redhat-cloud-services-Paketen
Die betroffenen Pakete stammen aus dem @redhat-cloud-services-Scope auf npm. StepSecurity meldet, dass die schädlichen Versionen einen preinstall-Hook enthalten. Dieser Hook führt automatisch eine Datei namens index.js aus. Der Start erfolgt vor dem eigentlichen Anwendungscode. Entwickler sehen den Angriff daher nicht erst beim Programmstart, sondern bereits beim Installationsvorgang.
StepSecurity beschreibt die schädliche Datei als ungewöhnlich groß. Die Malware nutzt mehrere Ebenen zur Verschleierung. Aikido und Wiz ordnen die Kampagne als neue Variante der Mini-Shai-Hulud-Angriffsfamilie ein. Wiz verwendet für die Variante den Namen Miasma. Die Malware ist laut den Berichten nicht nur auf lokale Entwicklergeräte ausgerichtet. Sie zielt besonders auf Umgebungen mit weitreichenden Rechten in GitHub Actions, Cloud-Infrastrukturen und Paketregistern.
Aikido schreibt, dass ein kompromittiertes GitHub-Konto eines Red-Hat-Mitarbeiters genutzt worden sein soll. Über sogenannte orphan commits sollen schädliche Workflows in mehrere Repositories gelangt sein. Diese Workflows forderten OIDC-Tokens an und veröffentlichten anschließend manipulierte npm-Versionen. Wiz beschreibt ein ähnliches Muster und verweist auf gültige Provenance-Attestations. Das ist besonders heikel, weil solche Vertrauenssignale eigentlich Manipulationen in der Lieferkette erschweren sollen.
- Betroffene Pakete: Aikido nennt 32 Pakete mit 96 kompromittierten Versionen.
- Angriffspunkt: GitHub Actions OIDC und kompromittierte CI/CD-Workflows.
- Startpunkt: automatische Ausführung über einen npm-preinstall-Hook.
- Ziel: GitHub Actions, AWS, GCP, Azure, Kubernetes, Vault, npm, PyPI, SSH und lokale .env-Dateien.
- Risiko: Weiterverbreitung über gestohlene npm-Tokens und manipulierte Folgepakete.
Credential-Harvester zielt auf GitHub, Cloud-Dienste und npm-Tokens
StepSecurity beschreibt den Payload als mehrstufigen Harvester für Entwicklergeheimnisse. Die Malware sucht unter anderem nach GitHub Actions Secrets, AWS-Zugangsdaten, Google-Cloud-Anmeldedaten, Azure-Service-Principals, Kubernetes-Tokens, HashiCorp-Vault-Tokens, npm-Tokens, CircleCI-Tokens und SSH-Schlüsseln. Aikido nennt zusätzlich PyPI-Publish-Tokens, Docker-Registry-Zugangsdaten, GPG-Schlüssel und .env-Dateien.
Der Angriff ist deshalb gefährlich, weil Entwicklergeräte und CI-Runner oft mehr Rechte besitzen als normale Endgeräte. Ein einzelner kompromittierter Build kann Zugang zu Cloud-Konten, Deployment-Schlüsseln und Paketveröffentlichungen liefern. Aus einem lokalen npm-Installationsvorgang kann dadurch ein Angriff auf Repositories, Cloud-Workloads und weitere Softwarepakete entstehen.
StepSecurity warnt außerdem vor einer Worm-Komponente. Mit gestohlenen npm-Tokens kann die Malware weitere Pakete mit manipulierten Versionen veröffentlichen. StepSecurity nennt dabei auch den npm-Parameter bypass_2fa. Diese Beobachtung ist für Maintainer kritisch, weil Zwei-Faktor-Authentifizierung allein nicht jede Veröffentlichungsroute schützt, sobald ein Angreifer bereits in der Build- oder Publishing-Kette sitzt.
Entwickler sollten Pakete prüfen und Secrets rotieren
Teams mit Abhängigkeiten aus dem Scope @redhat-cloud-services sollten ihre Lockfiles, CI-Protokolle und Paketversionen prüfen. StepSecurity veröffentlichte eine Liste betroffener Pakete und Versionen im GitHub-Repository RedHatInsights/javascript-clients. Dort finden sich unter anderem @redhat-cloud-services/frontend-components, @redhat-cloud-services/rbac-client, @redhat-cloud-services/notifications-client, @redhat-cloud-services/insights-client, @redhat-cloud-services/patch-client und @redhat-cloud-services/types.
Für betroffene Entwickler reicht ein einfaches Paket-Downgrade nicht aus. Die Malware zielte auf Zugangsdaten. Teams sollten daher von einer möglichen Offenlegung ausgehen, sobald eine schädliche Version auf einem Entwicklergerät oder CI-Runner installiert wurde.
- Lockfiles prüfen: package-lock.json, pnpm-lock.yaml und yarn.lock nach betroffenen Versionen durchsuchen.
- Build-Logs sichern: verdächtige npm-install-Läufe, ausgehende Netzwerkverbindungen und neue GitHub-Repositories prüfen.
- Secrets rotieren: GitHub, npm, AWS, GCP, Azure, Kubernetes, Vault, CircleCI, SSH und Docker Registry berücksichtigen.
- Runner neu aufsetzen: potenziell infizierte CI-Runner und Entwicklerumgebungen nicht weiterverwenden.
- Pakete pinnen: saubere Versionen explizit festlegen und automatische Updates vorübergehend enger kontrollieren.
- Publishing prüfen: npm-Provenance, GitHub-Actions-Workflows und OIDC-Berechtigungen kontrollieren.
Red Hat hatte in den geprüften öffentlichen Quellen noch keine ausführliche eigene Stellungnahme zur aktuellen @redhat-cloud-services-Welle veröffentlicht. Die bislang belastbarsten technischen Angaben stammen von unabhängigen Sicherheitsfirmen und den öffentlich gemeldeten GitHub-Issues. Für Unternehmen bleibt der Fall ein weiteres Signal, dass Software-Lieferketten nicht nur über Abhängigkeiten, sondern auch über CI/CD-Identitäten, OIDC-Vertrauen und automatisierte Veröffentlichungen abgesichert werden müssen.