La dernière campagne de piratage de la chaîne d'approvisionnement n'a pas seulement compromis des registres open source. Elle a détourné le pipeline de déploiement au sein de l'une des organisations les plus soucieuses de la sécurité au monde, et le point d'entrée a été une simple installation de dépendances npm.
Le 11 mai 2026, le groupe malveillant TeamPCP a lancé la quatrième vague de sa campagne de vers Shai-Hulud, désormais connue sous le nom de Mini Shai-Hulud. L'attaque a compromis 84 versions de paquets malveillants réparties sur 42 paquets TanStack dans le registre npm en l'espace de six minutes, pour finalement s'étendre à plus de 170 paquets dans les registres de code source npm et PyPI (Python Package Index), y compris des espaces de noms appartenant à Mistral AI, UiPath et OpenSearch. Au moins un des paquets affectés, @tanstack/react-router, enregistre environ 12 millions de téléchargements hebdomadaires.
Il s'agit de la quatrième vague d'une campagne qui ne cesse de s'intensifier. Les vagues précédentes comprenaient la première compromission de npm (Shai-Hulud 1.0) et la vague 2.0 visant les identifiants GitHub.
OpenAI a révélé cette semaine que deux appareils appartenant à des employés avaient été compromis. Aucune donnée utilisateur, aucun système de production ni aucune propriété intellectuelle n'ont été affectés, mais les mesures de confinement ont nécessité l'isolation des systèmes, la rotation des identifiants, le recours à des experts en informatique légale externes, ainsi qu'une rotation complète des certificats de signature de code sur macOS, Windows, iOS et Android, déclenchée par l'installation d'une seule dépendance.
Mini Shai-Hulud, quatrième vague : en bref
- Date de l'attaque : 11 mai 2026
- Paquets compromis : 84 versions malveillantes réparties dans 42 paquets @tanstack/* ; plus de 170 au total sur les registres npm et PyPI
- CVE : CVE-2026-45321, score CVSS : 9,6 (Critique)
- Source : TeamPCP (également répertorié sous les noms PCPcat et UNC6780)
- Mécanisme : trois vulnérabilités en chaîne dans GitHub Actions — Pwn Request, empoisonnement du cache, extraction de jetons OIDC (OpenID Connect) à partir de la mémoire du processus du runner
- Victime notable : OpenAI – deux appareils d'employés ont été compromis ; des informations confidentielles, notamment des certificats de signature de code pour macOS, iOS, Windows et Android, ont été exfiltrées depuis les référentiels de code source internes
- Versions précédentes : Shai-Hulud 1.0 (septembre 2025), 2.0 (novembre 2025) et 3.0 (décembre 2025)
- Conséquences : compromission des environnements de développement et de CI/CD, prise de contrôle des comptes des responsables de paquets et des paquets eux-mêmes, et la provenance SLSA ainsi que les versions signées ne sont plus « sécurisées par défaut »
- Principaux risques : les paquets malveillants qui satisfont à l'attestation de provenance de niveau 3 de la norme SLSA (Supply-chain Levels for Software )
Comment l'attaque s'est déroulée
La quatrième vague de Mini Shai-Hulud est à ce jour la version la plus sophistiquée sur le plan technique de cette campagne. Alors que les vagues précédentes s'appuyaient sur des comptes d'administrateurs compromis pour publier directement des paquets malveillants, la quatrième vague a exploité en chaîne trois vulnérabilités de GitHub Actions afin de détourner le pipeline de publication légitime lui-même.
Le déroulement de l'attaque :
- Fork et camouflage : l'attaquant a créé un fork du dépôt TanStack/router, qu'il a renommé zblgg/configuration afin qu'il n'apparaisse pas comme un fork évident dans les listes de forks de GitHub.
- Déclencher le workflow : une pull request a été ouverte, ce qui a déclenché le workflow « pull_request_target » — le modèle « Pwn Request » qui autorise le workflow à accéder au code du fork
- Corruption du cache : le code de la branche créée par l'attaquant a inséré dans le cache de GitHub Actions une entrée pnpm-store corrompue de 1,1 Go, indexée de manière à ce que le workflow de publication la restaure ultérieurement
- Effacer les traces : la pull request malveillante a ensuite été forcée à passer à un état « sans opération » puis fermée afin de dissimuler les preuves de la compromission
- Attendez le déclenchement : lorsque des responsables légitimes de TanStack ont fusionné des pull requests sans rapport avec le projet dans la branche principale, le processus de publication s'est déclenché et a restauré le cache corrompu
- Steal the token: Attacker-controlled binaries read /proc/<pid>/mem of the Runner.Worker process to extract the OIDC token minted for npm trusted publishing
- Publication via le pipeline : ces jetons ont été utilisés pour publier 84 versions malveillantes de paquets dans le registre npm via le pipeline de publication légitime de TanStack.
- Résultat : des paquets comportant des attestations de provenance SLSA de niveau 3 valides, des attestations Sigstore valides et des signatures GitHub Actions légitimes, générés par le pipeline de publication officiel, mais contenant des logiciels malveillants destinés à voler des identifiants. Comme l'a confirmé TanStack dans son rapport d'analyse rétrospective, du point de vue des développeurs, ces paquets semblaient cryptographiquement authentiques, sans aucun signe visible de compromission.
Des secrets ont été divulgués : la charge utile du logiciel malveillant a exfiltré des secrets exposés – identifiants et jetons qui étaient activement accessibles sur les systèmes compromis – via trois canaux redondants : un domaine de typosquatting (git-tanstack[.]com), le réseau décentralisé de messagerie Session, et API GitHub utilisant des jetons volés. Les identifiants ciblés comprenaient des jetons GitHub, des secrets cloud provenant d'AWS, de GCP et d'Azure, des données d'authentification CI/CD, des identifiants Kubernetes, Vault HashiCorp Vault et des clés SSH.
Sur les machines des développeurs, le logiciel malveillant installait un démon persistant nommé « gh-token-monitor » (via LaunchAgent sous macOS ou systemd sous Linux) qui interrogeait GitHub toutes les 60 secondes. En cas de réception d'une erreur 40X due à la révocation d'un jeton, le démon tentait d'exécuter la commande « rm -rf ~/ » afin d'effacer le répertoire personnel de l'utilisateur. Le démon se fermait automatiquement au bout de 24 heures.
L'impact d'OpenAI et ce qu'il nous apprend
La communication d'OpenAI précise clairement la nature des données exfiltrées : il s'agit d'un ensemble limité d'identifiants provenant d'un sous-ensemble de dépôts de code source internes accessibles aux deux employés dont les comptes ont été compromis, y compris des certificats de signature de code pour les produits macOS, iOS, Windows et Android. OpenAI a confirmé qu'il n'y avait aucune preuve que ces certificats aient été utilisés pour signer des logiciels malveillants, mais procède à leur renouvellement par mesure de précaution et demande aux utilisateurs de macOS de mettre à jour leurs applications avant le 12 juin 2026, date après laquelle les applications signées avec les anciens certificats pourraient cesser de fonctionner.
Un deuxième détail révélé par OpenAI mérite d'être souligné. Les deux appareils compromis n'avaient pas encore reçu les mises à jour des configurations de gestion des paquets, notamment les contrôles tels que la vérification de l'ancienneté minimale des versions et la validation de la provenance des paquets, qui étaient en cours de déploiement dans l'ensemble de l'environnement de l'organisation. L'attaque a eu lieu pendant cette période de déploiement.
Cela met en évidence une faille bien réelle et courante. Les contrôles de sécurité sont mis en place progressivement. Lors de tout déploiement par étapes, une partie des systèmes est davantage exposée. La campagne de TeamPCP s'est déroulée sans interruption pendant plusieurs semaines, consistant à publier des paquets malveillants dans les registres et à attendre qu'ils soient installés. Le choix du moment n'était pas fortuit.
Vérifiez vos Software pour prévenir Supply Chain
La solution MetaDefender Software ™ est conçue pour aider les organisations à inspecter les artefacts, paquets et fichiers binaires réels entrant dans le cycle de vieSoftware (SDLC), y compris les paquets comportant des signatures valides ou des attestations de provenance, offrant ainsi une visibilité sur les logiciels tout au long du pipeline, au moment où les paquets sont utilisés.
Trois fonctionnalités deSupply Chain MetaDefender Software Supply Chain comblent directement les failles exploitées par cette attaque :
Metascan™ Multiscanning: combine plus de 30 moteurs anti-malware commerciaux pour analyser les paquets provenant de registres de code source, notamment npm et PyPI, avant qu'ils n'atteignent les postes de travail des développeurs ou les pipelines CI/CD. Alors qu'un moteur de détection unique pourrait ne pas signaler une variante nouvellement publiée, la surface de détection combinée réduit la fenêtre pendant laquelle un paquet malveillant peut s'exécuter sans être détecté.
Génération de SBOM (Software of Materials) : offre une visibilité sur les composants logiciels de l'ensemble d'une pile, les dépendances directes et transitives, l'historique des versions et les métadonnées du registre, avec la prise en charge de plus de dix langages de programmation. Le SBOM permet de détecter les modifications inattendues apportées aux paquets avant qu'elles ne se répercutent en aval, et s'exporte aux formats CycloneDX et SPDX afin de garantir la conformité aux exigences réglementaires, notamment la loi DORA (Digital Operational Resilience Act).
Proactive DLP™ : analyse le code source à la recherche de secrets codés en dur (mots de passe, API , jetons et identifiants intégrés au code) avant qu'ils ne soient exposés aux attaquants. Cette approche se distingue de la réponse à l'exfiltration d'identifiants : la technologie Proactive DLP™ traite le risque que des secrets laissés dans le code source ou les fichiers de configuration deviennent accessibles lorsqu'un référentiel est compromis, comme cela s'est produit lors de l'incident OpenAI.
MetaDefender Software Supply Chain s'intègre nativement à GitHub, GitLab, Azure DevOps et Nexus, plaçant l'inspection au sein même du pipeline plutôt qu'en parallèle. Une version récente, la version 3.3.0, ajoute la prise en charge du transfert sécurisé d'artefacts entre environnements isolés via un transfert de données unidirectionnel utilisant la technologie de diode de données, permettant aux organisations évoluant dans des environnements isolés ou hautement sécurisés de valider les artefacts avant qu'ils ne franchissent les limites du réseau, avec un processus d'activation disponible qui s'intègre aux workflows DevSecOps existants.
Mesures immédiates recommandées
À l'attention de toute organisation ayant éventuellement installé des paquets concernés pendant la fenêtre « Mini Shai-Hulud » :
- Vérifiez la présence du démon gh-token-monitor avant de révoquer les jetons : isolez et sauvegardez d'abord les systèmes concernés ; une révocation prématurée déclenche la charge utile d'effacement.
- Remplacer les identifiants exposés: identifiants PAT GitHub, jetons npm, clés SSH et identifiants de cloud pour tout développeur ou pipeline ayant installé des paquets pendant la période concernée ; activer l'authentification à deux facteurs (MFA).
- Supprimez les paquets compromis: videz le cache npm et le répertoire node_modules ; fixez les versions des paquets à celles publiées après le 12 mai 2026.
- Vérifiez les actions GitHub et les workflows CI/CD: recherchez les événements de publication inattendus, les nouveaux workflows ou les connexions sortantes vers des points de terminaison inconnus.
- Renforcez la sécurité des pipelines: restreignez les scripts de cycle de vie, limitez l'accès au réseau sortant et réduisez au minimum la portée des jetons.
- Associez les contrôles de provenance à l'inspection du contenu: une provenance valide indique l'origine du pipeline, mais pas son intégrité ; recourez à l'analyse antivirus parallèlement à la vérification des attestations.
Principaux enseignements
L'attestation de provenance indique l'origine, mais pas l'intégrité
Wave Four a généré des paquets malveillants valablement certifiés, car le pipeline de publication lui-même avait été compromis. Les vérifications de signature et de provenance constituent un indicateur utile, mais ne garantissent pas la sécurité du contenu.
La fenêtre de déploiement correspond à une fenêtre d'exposition
. L'incident survenu chez OpenAI s'est produit lors de la mise en place progressive de nouveaux contrôles de la chaîne logistique. Toute organisation présente des lacunes similaires lors du déploiement de ses contrôles. Une inspection au niveau du contenu à chaque étape permet de réduire la dépendance vis-à-vis de l'exhaustivité des politiques de sécurité avant qu'une attaque ne se produise.
Cette campagne est toujours en cours
. Mini Shai-Hulud constitue la quatrième vague d'une campagne dont le niveau de sophistication technique n'a cessé de croître depuis septembre 2025. Considérer chaque incident isolé comme résolu sans remédier aux vulnérabilités sous-jacentes des pipelines expose les organisations à la prochaine itération.
En combinant la visibilité sur la liste des composants logiciels (SBOM), l'analyse multi-menaces et la détection des secrets codés en dur, il est possible de réduire la surface d'exposition dans les environnements de développement logiciel modernes. Ne faites confiance à aucun fichier. Ne faites confiance à aucun appareil.
Prêt à sécuriser votre chaîne de développement logiciel contre les attaques de la chaîne d'approvisionnement telles que Mini Shai-Hulud ?
