Le 1er juin 2026, nous avons détecté que plusieurs packages officiels de Périmètre @redhat-cloud-services sur npm ont été compromises par un ver voleur d'identifiants. Au total, 96 versions réparties sur 32 paquets ont été compromises, téléchargées cumulativement 116 991 fois par semaine. Le malware semble similaire au malware Mini Shai-Hulud qui a été récemment open-sourcé par TeamPCP. Depuis que l'outillage a été rendu public, d'autres acteurs de la menace ont désormais accès aux mêmes techniques et peuvent les reproduire ou les adapter. Les packages ont été publiés via GitHub Actions OIDC, ce qui indique que le pipeline CI/CD a été compromis plutôt qu'un jeton npm. Si vous avez installé des versions de packages affectées depuis le 1er juin 2026, considérez tous les secrets CI, les identifiants cloud, les clés SSH et les jetons npm comme compromis et faites-les pivoter immédiatement.
Chronologie de la campagne Mini Shai-Hulud
- 22 avril 2026 - @bitwarden/cli compromis via un workflow GitHub Actions empoisonné. La charge utile s'auto-identifie comme "Shai-Hulud: The Third Coming."
- 29 avril 2026 - Quatre packages npm SAP compromis suite à la fuite d'un jeton npm via une build de pull request CircleCI malveillante.
- 30 avril 2026 - PyTorch Lightning compromis sur PyPI, versions 2.6.2 et 2.6.3.
- 12 mai 2026 - Mini Shai-Hulud affecte plus de 160 packages, dont Mistral et Tanstack.
- 12 mai 2026 - TeamPCP publie le code source complet de Shai-Hulud sur GitHub, ainsi que des publications sur BreachForums encourageant d'autres à lancer leurs propres campagnes.
- 19 mai 2026 - Le package npm DurableTask de Microsoft compromis, causé par un compte GitHub précédemment compromis.
- 1er juin 2026 - Plus de 30
@redhat-cloud-servicespackages npm compromis avec Miasma, une nouvelle variante de Mini Shai-Hulud.
Miasma : Shai-Hulud est-il de retour ?
La charge utile intégrée dans les packages affectés présente de fortes ressemblances avec Mini Shai-Hulud, le malware de chaîne d'approvisionnement open-sourcé par TeamPCP. Fait intéressant, cette version se nomme "Miasma" et semble avoir remplacé les références familières à Dune de Shai-Hulud par la mythologie grecque.
TeamPCP est un groupe d'acteurs malveillants qui mène des attaques ciblées sur la chaîne d'approvisionnement CI/CD depuis plusieurs mois. Leur malware Mini Shai-Hulud est un ver sophistiqué de vol de credentials qui se propage en republiant des versions piégées de packages auxquels le compte de la victime a accès. Nous avons déjà signalé des compromissions affectant Mistral et TanStack, Durable Task de Microsoft, PyTorch Lightning, Bitwarden CLI, et Intercom, toutes attribuées aux mêmes outils.
Lorsque TeamPCP a open-sourcé Mini Shai-Hulud, la menace s'est étendue au-delà d'un seul acteur. N'importe quel groupe peut désormais reprendre le framework, l'adapter et le déployer contre de nouvelles cibles.
Contournement du Trusted publishing
Le Trusted publishing est un mécanisme introduit par npm pour éliminer les jetons de publication à longue durée de vie des pipelines CI/CD, en les remplaçant par des jetons OIDC à courte durée de vie émis par GitHub Actions. Il a été conçu pour être plus sécurisé, mais comme le montrent de récentes attaques, il peut être contourné si un attaquant accède à un pipeline CI/CD via une vulnérabilité ou un jeton compromis.
Nous avons découvert que le compte GitHub d'un employé de Red Hat a été compromis et utilisé pour pousser des commits orphelins malveillants directement vers plusieurs dépôts, contournant entièrement la code review. Ces commits orphelins contenaient un fichier de workflow (ci.yaml) et un script (_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"Lorsque le workflow s'exécute, il installe Bun et exécute _index.js, en lui transmettant une liste de paquets cibles via la OIDC_PACKAGES variable d'environnement. Le script utilise la id-token: write autorisation de demander un jeton OIDC de courte durée à GitHub, puis utilise ce jeton pour s'authentifier directement auprès du point de terminaison de publication de confiance de npm et publier des versions piégées de chaque paquet de la liste.
C'est le même schéma fondamental observé lors des compromissions de TanStack et Bitwarden : le pipeline CI/CD lui-même devient la surface d'attaque, tandis que la publication de confiance basée sur OIDC – conçue pour éliminer les jetons de longue durée – devient un signal de confiance trompeur.
Le script de pré-installation
Chaque package compromis déclare un script de pré-installation dans son package.json qui exécute automatiquement node index.js à chaque installation npm, avant l'exécution de tout code d'application et avant que le développeur n'ait la moindre indication que quelque chose ne va pas.
"scripts": {
"preinstall": "node index.js"
}
Le fichier index.js est un payload de 4,2 Mo dissimulé derrière plusieurs couches d'obfuscation.
Ce qu'il dérobe
Comme lors des précédentes attaques Mini Shai-Hulud, le payload effectue un balayage étendu des identifiants à travers les fournisseurs cloud, les environnements CI/CD et les outils de développement. Côté CI, il cible les secrets GitHub Actions, notamment GITHUB_TOKEN et ACTIONS_RUNTIME_TOKEN. Pour les identifiants cloud, il collecte les clés d'accès et les jetons de session AWS, les identifiants par défaut des applications GCP et les fichiers de clés de compte de service, ainsi que les identifiants de principal de service Azure et les jetons d'identité gérée. Il recherche également les jetons HashiCorp Vault, les jetons de compte de service Kubernetes et les fichiers kubeconfig, les jetons de publication npm et PyPI, les clés privées SSH, les identifiants de registre Docker, les clés GPG, et tous les fichiers .env qu'il peut trouver sur le système de fichiers.
Comment Aikido détecte cela
Si vous êtes un utilisateur Aikido, vérifiez votre flux central et filtrez les problèmes de logiciels malveillants. Cela apparaîtra comme un problème critique 100/100. Aikido effectue des rescans nocturnes, mais nous vous recommandons de déclencher un rescan manuel dès maintenant.
Si vous n'êtes pas encore un utilisateur Aikido, vous pouvez créer un compte et connecter vos dépôts. Notre couverture des logiciels malveillants est incluse dans le plan gratuit, aucune carte de crédit requise.
Pour une couverture plus large au sein de toute votre équipe, la Device Protection d'Aikido vous offre une visibilité et un contrôle sur les packages logiciels installés sur les appareils de votre équipe. Elle couvre les extensions de navigateur, les bibliothèques de code, les plugins d'IDE et les dépendances de build, le tout en un seul endroit. Arrêtez les malwares avant qu'ils ne soient installés.
Pour une protection future, envisagez Aikido Safe Chain (open source). Safe Chain s'intègre à votre flux de travail existant, en interceptant les commandes npm, npx, yarn, pnpm et pnpx et en vérifiant les paquets par rapport à Aikido Intel avant l'installation.
Indicateurs de compromission
Si vous avez installé l'une des versions de package suivantes, considérez tous les secrets CI, les identifiants cloud, les clés SSH et les jetons npm comme compromis et faites-les pivoter immédiatement :
@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)
