Kritischer npm-Angriff: 31 Red Hat Pakete mit Credential-Stealer verseucht

Am 1. Juni 2026 wurden über 30 offizielle npm-Pakete unter dem @redhat-cloud-services-Namespace kompromittiert. Wer diese Pakete installiert hat, muss umgehend handeln.

Sicherheit#Lieferkettensicherheit#Open Source Security#Incident Response#Cloud Security#npm#Credential Stealer

Sicherheitswarnung Supply Chain Attack

Am 1. Juni 2026 wurden über 30 offizielle npm-Pakete unter dem @redhat-cloud-services-Namespace kompromittiert. Wer diese Pakete installiert hat, muss die betroffene Umgebung sofort als kompromittiert behandeln und kontrolliert reagieren.

Was ist passiert?

Angreifer der Gruppe TeamPCP haben nach vorliegenden Informationen die CI/CD-Pipeline von Red Hat Cloud Services über GitHub-Actions-OIDC-Tokens gekapert und backdoorierte Versionen von 31 weit verbreiteten npm-Paketen veröffentlicht. Die Kampagne trägt den Namen „Miasma: The Spreading Blight“ und basiert auf einer Weiterentwicklung der bekannten Mini-Shai-Hulud-Malware-Familie.

Entscheidend ist: Es handelt sich nicht um Typosquatting. Die Angreifer haben nicht ähnlich klingende Paketnamen missbraucht, sondern den legitimen, verifizierten Namespace direkt übernommen. Genau deshalb ist dieser Vorfall ein Supply-Chain-Angriff auf höchstem Niveau.

Wie funktioniert der Angriff?

Jedes kompromittierte Paket enthält einen preinstall-Hook in der package.json. Schon beim Ausführen von npm install wird automatisch ein rund 4,2 MB großes, obfusziertes Payload gestartet, noch bevor Anwendungscode ausgeführt wird.

Der Loader durchläuft eine mehrstufige Entschlüsselungskette und legt anschließend ein temporäres Bun-basiertes Skript unter /tmp/p*.js ab. Dadurch kann die Malware bereits während der Installation Secrets aus lokalen Entwicklungsumgebungen, CI-Runnern und Cloud-Kontexten auslesen.

Welche Credentials werden gestohlen?

Die Malware sucht gezielt nach besonders wertvollen Zugangsdaten und Konfigurationsdateien:

  • GitHub Tokens
  • AWS-, GCP- und Azure-Zugangsdaten
  • Kubernetes Secrets
  • SSH Private Keys
  • HashiCorp Vault Tokens
  • npm- und PyPI-Tokens
  • Docker Credentials
  • .env-Dateien

In Cloud-Umgebungen geht das Payload noch weiter: Es fragt aktiv AWS Secrets Manager, Azure Key Vault und GCP Secret Manager ab. Auf GitHub-Actions-Runnern liest die Malware Secrets direkt aus dem Prozessspeicher. Das übliche Masking in Workflow-Logs wird dadurch vollständig umgangen.

Tarnung und Persistenz

Der Exfiltrations-Traffic wird bewusst an api.anthropic.com/v1/api geschickt. Der Hostname wirkt in Organisationen, die Anthropic-Dienste nutzen, auf den ersten Blick unauffällig. Der Pfad /v1/api ist jedoch kein gültiger Anthropic-Endpunkt und dient ausschließlich der Tarnung.

Gestohlene Credentials werden in öffentlichen GitHub-Repositories unter Opfer-Accounts abgelegt. Die Beschreibung dieser Repositories lautet „Miasma: The Spreading Blight“. Zusätzlich richtet die Malware Persistenzmechanismen ein, darunter kitty-monitor.service auf Linux und com.user.kitty-monitor.plist auf macOS.

Besonders kritisch ist der Dead-Man-Switch: Ein mitinstallierter Token-Monitor namens gh-token-monitor überwacht gestohlene GitHub-Tokens. Wird ein Token widerrufen, bevor die Persistenz entfernt wurde, können destruktive Befehle ausgelöst werden, bis hin zum Löschen des kompletten Home-Verzeichnisses. Tokens sollten deshalb erst rotiert werden, nachdem alle Persistenzmechanismen entfernt wurden.

Bin ich betroffen?

Betroffen sind Umgebungen, in denen eines der 31 kompromittierten Pakete am oder nach dem 1. Juni 2026 installiert wurde. Dazu gehören unter anderem:

  • @redhat-cloud-services/frontend-components Version 7.7.2
  • @redhat-cloud-services/chrome Version 2.3.1
  • @redhat-cloud-services/rbac-client Version 9.0.3

Wer diese oder andere Pakete aus dem kompromittierten Namespace installiert hat, sollte nicht nur das Paket entfernen, sondern die gesamte Umgebung als kompromittiert betrachten.

Sofortmaßnahmen

Schritt-für-Schritt-Reaktionsplan

  1. Betroffene Maschinen isolieren, bevor weitere Schritte unternommen werden.
  2. Persistenzdateien entfernen: kitty-monitor und gh-token-monitor auf allen betroffenen Systemen löschen.
  3. Injizierte Hooks prüfen: .claude/settings.json, .vscode/tasks.json und ~/.config/index.js untersuchen.
  4. Alle kompromittierten Pakete deinstallieren und Lockfiles aus vertrauenswürdigen Quellen neu generieren.
  5. In CI-Pipelines vorübergehend npm ci --ignore-scripts verwenden.
  6. Erst jetzt alle Credentials rotieren: GitHub Tokens, npm Tokens, Cloud-Keys, SSH-Keys, Vault- und Kubernetes-Tokens.
  7. Betroffene CI-Runner und Entwicklermaschinen von sauberen Images neu aufsetzen.

Fazit

Dieser Angriff zeigt eindrücklich, wie gefährlich Supply-Chain-Angriffe auf vertrauenswürdige Namespaces sind. Entwickler verlassen sich zu Recht auf offizielle Paketquellen. Genau dieses Vertrauen macht den Angriffsvektor so wirkungsvoll.

CI/CD-Pipelines mit OIDC-Token-Zugriff sind ein hochattraktives Ziel. Ihre Absicherung muss deshalb höchste Priorität haben: minimale Token-Berechtigungen, kurze Laufzeiten, klare Trust-Policies, getrennte Build-Kontexte und eine konsequente Überwachung von Paketveröffentlichungen sind Pflicht.

Weitere passende Beiträge