Red Hat hat einen schwerwiegenden Sicherheitsvorfall bestätigt: Insgesamt 32 offizielle npm-Pakete unter dem Namensraum @redhat-cloud-servicescodecodecode wurden mit Malware infiltriert. Die Sicherheitsfirma StepSecurity entdeckte am 1. Juni 2026, dass die schädlichen Versionen nicht etwa gefälschte Pakete waren – sie stammten aus der offiziellen CI/CD-Pipeline, trugen eine gültige Signatur und wurden über den legitimen Namensraum verbreitet. Es handelt sich um einen Angriff, der das Vertrauen in die Lieferkette von npm auf eine völlig neue Stufe stellt.
Der Angriff: Kein Typosquatting, sondern direkte Kontrolle
Was diesen Vorfall von bisherigen Supply-Chain-Angriffen unterscheidet, ist die Methode. Die Angreifer haben nicht etwa ähnlich klingende Paketnamen genutzt, sondern die GitHub-Konten von Red-Hat-Mitarbeitenden kompromittiert und schädliche Commits direkt in das offizielle Repository RedHatInsightscodecodecode eingeschleust. Von dort aus nutzten sie GitHub Actions und dessen OIDC-Token, um die schadhaften Pakete mit gültiger SLSA-Provenienz (Supply-chain Levels for Software Artifacts) zu signieren und auf npm zu veröffentlichen.
Betroffen sind 32 Pakete in 96 verschiedenen Versionen, die zusammengerechnet rund 117.000 Downloads pro Woche erreichten. Wie StepSecurity in seiner Analyse hervorhebt, war kein einziges herkömmliches Sicherheitsmerkmal in der Lage, die Malware als gefährlich zu identifizieren – der Paketname, die Veröffentlichungsquelle und die Signatur waren alle authentisch.
Miasma – die neueste Welle des Shai-Hulud-Wurms
Die eingeschleuste Backdoor trägt den Namen „Miasma: The Spreading Blight“ und wird als Unterart des berüchtigten Shai-Hulud-Wurms eingestuft. Shai-Hulud, der seit September 2025 die npm-Ökosysteme attackiert, wird der Bedrohungsgruppe TeamPCP zugeschrieben. Die Angriffskampagne hat sich in mehreren Wellen entwickelt:
- September 2025: Erste Welle – etwa 200 Pakete infiziert
- November 2025: Zweite Welle – auf rund 800 Pakete ausgeweitet, darunter Zapier und PostHog
- März 2026: Axios-Kompromittierung (Urheberschaft: Sapphire Sleet aus Nordkorea)
- April 2026: Bitwarden und SAP – TeamPCP nutzt GitHub Actions als Einfallstor
- Mai 2026: TanStack, Mistral AI, OpenAI – Mini-Shai-Hulud-Kampagne mit über 170 Paketen
- 1. Juni 2026: Red Hat – Miasma-Variante, 32 Pakete kompromittiert
Ein entscheidender Wendepunkt war der 12. Mai 2026, als TeamPCP den Quellcode von Shai-Hulud öffentlich auf einem Git-Repository veröffentlichte und auf BreachForums sogar ein Preisgeld von 1.000 Dollar für denjenigen auslobte, der den größten Supply-Chain-Angriff durchführt. Seit der Code öffentlich ist, kann jeder die Technik nachahmen – die eigentliche Frage ist daher nicht, ob TeamPCP selbst oder ein Nachahmer hinter dem Red-Hat-Angriff steckt, sondern dass die Angriffsmuster jetzt frei verfügbar sind.
Wie die Malware arbeitet: Ein 4,2 MB großes Preinstall-Skript
Der Einstiegspunkt war eine preinstallcodecodecode-Hook in der package.jsoncodecodecode. Sobald ein Entwickler npm installcodecodecode ausführt, wird noch vor dem eigentlichen Anwendungscode ein 4,2 MB großes, obfuskiertes Payload ausgeführt. Allein die Größe ist bei einer normalen Bibliothek ein Alarmzeichen – in einer automatisierten Pipeline wird sie jedoch meist nicht bemerkt.
Das Skript durchläuft drei Stufen der Obfuskation, lädt dann Bun Runtime herunter und führt den eigentlichen Schadcode aus. Dieser zielt darauf ab, nahezu alle Zugangsdaten aus der Entwicklungsumgebung zu stehlen:
- GitHub Actions-Tokens (inkl. OIDC- und Runtime-Tokens)
- AWS-Zugangsschlüssel, Secret Keys, Session-Tokens
- GCP-Standardanmeldedaten, Service-Account-Keys
- Azure-Dienstprinzipal-Anmeldeinformationen
- Kubernetes-Service-Account-Tokens, kubeconfig-Dateien
- HashiCorp Vault-Tokens und -Adressen
- npm- und PyPI-Publish-Tokens aus .npmrc und .pypirc
- SSH-Private-Keys (RSA, Ed25519)
- Docker-Registry-Anmeldedaten (config.json)
- GPG-Schlüsselbund
- Alle .env-Dateien auf dem Dateisystem
Besonders raffiniert ist der direkte Zugriff auf den Prozessspeicher des GitHub-Actions-Runners. Über /proc/<pid>/memcodecodecode des Runner.Workercodecodecode-Prozesses können Tokens ausgelesen werden, die in den Logs maskiert werden – im Arbeitsspeicher sind sie jedoch im Klartext vorhanden.
Selbstvermehrung: Der Wurm wird zum Dauerbrenner
Ein zentrales Merkmal von Miasma ist seine Fähigkeit zur Selbstreplikation. Sobald der Schadcode an einen npm-Publish-Token gelangt, sucht er automatisch nach anderen Paketen, für die der kompromittierte Entwickler Schreibrechte besitzt, und veröffentlicht dort neue, mit Backdoor versehene Versionen. Dabei werden auch Token mit aktivierter Zwei-Faktor-Authentifizierung missbraucht, weil der Angriff den Token selbst stiehlt – die 2FA umgeht er auf diese Weise. Ein einziger infizierter Rechner kann so eine ganze Kette von Paketen befallen, ohne dass der Angreifer weiter eingreifen muss.
Zusätzlich nutzt die Malware gestohlene GITHUB_TOKENcodecodecodes, um über die GitHub Contents API base64-kodierte Daten in den Repositories der Opfer zu speichern – als Exfiltrationskanal. Da die API-Unterdomäne api.github.comcodecodecode in den meisten CI-Umgebungen nicht blockiert ist, unterscheidet sich dieser Traffic kaum von legitimen Git-Operationen.
Eine Backdoor, die selbst nach der Paketbereinigung überlebt
Selbst wenn die infizierten npm-Pakete gelöscht werden, ist die Gefahr nicht vorbei. Die Malware injiziert sich in die Konfigurationsdateien von Entwicklungswerkzeugen. Dazu gehören:
- Claude Code: Eintrag eines
SessionStartcodecodecode-Hooks in~/.claude/settings.jsoncodecodecode, der bei jedem Start von Claude Code ausgeführt wird. - VS Code: Ein
folderOpencodecodecode-Trigger in.vscode/tasks.jsoncodecodecode, der jedes Mal feuert, wenn der Entwickler das Projektverzeichnis öffnet.
Diese Konfigurationsdateien werden von den üblichen Sicherheitsscans meist nicht erfasst und überleben selbst eine Neuinstallation der betroffenen npm-Pakete. Der Rechner bleibt dauerhaft infiziert.
Frühwarnung: Infostealer-Logs enthielten Red-Hat-Zugangsdaten
Die Sicherheitsfirma WhiteIntel berichtete, dass bereits am 13. April und 15. Mai 2026 GitHub-Anmeldeinformationen und Session-Cookies von Red-Hat-Mitarbeitern in Infostealer-Logs aufgetaucht waren. Dieses gestohlene Material könnte die Grundlage für die Account-Kompromittierung gewesen sein. Von der Aufzeichnung der Logs bis zum tatsächlichen Angriff vergingen nach Analysen von WhiteIntel oft nur 48 Stunden – schneller, als die meisten Security-Teams ihren wöchentlichen Review abschließen können.
Red Hats Reaktion
Red Hat veröffentlichte das Sicherheitsbulletin RHSB-2026-006 und entfernte sämtliche betroffenen Versionen aus der npm-Registry. Das Unternehmen betont, dass es sich um Frontend-Bibliotheken handelt, die nicht in den Build-Prozess der Red-Hat-Produkte selbst eingebunden werden. „Durch die Versionsfixierung wurde zum jetzigen Stand der Untersuchung bestätigt, dass keine infizierten Versionen in die Produkt-Builds gelangt sind“, heißt es in dem Bulletin. Kunden seien daher derzeit keinem direkten Risiko ausgesetzt. Die Untersuchung dauert jedoch an.
Der Angriff erfolgte in zwei Wellen: Die erste dauerte von 10:53 bis 10:53:33 Uhr (UTC), die zweite von 13:44 bis 13:46:47 Uhr. Bereits gegen 13 Uhr wurden die Informationen öffentlich, und die meisten schadhaften Versionen wurden noch am selben Tag aus der Registry entfernt.
Ein Systemvertrauen, das nicht mehr existiert
Die Serie von Supply-Chain-Angriffen im Jahr 2026 – Axios, Bitwarden, SAP, TanStack, OpenAI, jetzt Red Hat – zeigt eine erschreckende Gemeinsamkeit: Es geht nicht mehr darum, gefälschte Pakete von echten zu unterscheiden. Jedes Sicherheitsmerkmal, auf das Entwickler vertrauen, ist inzwischen als Angriffsvektor nutzbar. Der Paketname? Authentisch. Der Download-Count? Hoch. Die SLSA-Signatur? Gültig.
Was bedeutet das für Entwickler? Wer eine der betroffenen Versionen installiert hat, sollte alle Tokens seines GitHub-, npm- und Cloud-Umfelds als kompromittiert betrachten und sofort rotieren. Allerdings enthält die Malware eine „Dead Man’s Switch“-Funktion: Sobald sie erkennt, dass Tokens ungültig werden, könnte sie zerstörerische Aktionen auslösen. Daher ist es ratsam, die betroffene Umgebung zuerst zu isolieren und ein forensisches Image zu erstellen, bevor die Tokens zurückgesetzt werden.
Auch wenn die direkte Nutzung von @redhat-cloud-servicescodecodecode-Paketen in der Breite begrenzt sein mag, so verdeutlicht der Vorfall ein systemisches Problem: Das Vertrauensmodell von npm – und damit der gesamten Open-Source-Lieferkette – ist an einem Punkt angelangt, an dem Angreifer es effizienter ausnutzen können, als es die Sicherheitsmaßnahmen zu schützen vermögen. Und der Quellcode für diese Angriffsmuster ist jetzt öffentlich verfügbar.
Weitere Informationen: StepSecurity-Analyse und Red Hat RHSB-2026-006.
