Attaque de la chaîne d'approvisionnement Mini Shai-Hulud — Vérificateur d'IOC

curl -fsSL https://raw.githubusercontent.com/nkopylov/tanscript-exploit-check/main/check-tanstack-exploit.sh | bash

Ou clonez et exécutez localement :

git clone https://github.com/nkopylov/tanscript-exploit-check.git
cd tanscript-exploit-check
./check-tanstack-exploit.sh [project_dir ...]

Ce qui s'est passé

Ce vérificateur couvre deux vagues de la campagne d'attaque de la chaîne d'approvisionnement Mini Shai-Hulud menée par TeamPCP :

Vague 1 : Compromission CI/CD de TanStack (11 mai 2026)

Le 11 mai 2026 (19:20-19:26 UTC), un attaquant a publié 84 versions malveillantes sur 42 paquets npm @tanstack/* en une fenêtre de 6 minutes. L'attaque a également touché des paquets de Mistral AI, UiPath, OpenSearch et d'autres — plus de 170 paquets au total sur npm et PyPI.

Aucun identifiant de mainteneur n'a été volé. L'attaquant a exploité la chaîne de confiance CI/CD elle-même via une attaque en 3 étapes :

1. Exploit pull_request_target — Un fork GitHub jetable a ouvert une PR qui exécutait du code attaquant dans le contexte de sécurité du dépôt de base
2. Empoisonnement du cache GitHub Actions — Le code du fork a empoisonné le cache pnpm partagé, qui a ensuite infecté les workflows de publication légitimes
3. Extraction de jetons OIDC de la mémoire du processus — Le code malveillant a extrait les jetons de publication npm directement de la mémoire du runner GitHub Actions, produisant des paquets avec des attestations de provenance valides SLSA Build Level 3

Vague 2 : Prise de contrôle du compte npm « atool » (19 mai 2026)

Le 19 mai 2026 (01:39-02:06 UTC), le compte npm compromis atool ([email protected]) a publié 637 versions malveillantes sur 314 paquets en deux vagues automatisées. Les cibles à fort impact incluent :

• size-sensor (4,2 M de téléchargements/mois)
• echarts-for-react (3,8 M de téléchargements/mois)
• @antv/scale (2,2 M de téléchargements/mois)
• timeago.js (1,15 M de téléchargements/mois)
• 310+ paquets supplémentaires @antv/* et autres

Cette vague utilisait une charge utile basée sur Bun (498 Ko index.js) déclenchée via "preinstall": "bun run index.js", avec une charge utile de deuxième niveau cachée dans des commits imposteurs poussés vers le dépôt GitHub antvis/G2 via l'exploit de partage d'objet fork.

Ce que fait le code malveillant (les deux vagues)

Les deux vagues utilisent la même famille d'outils « Mini Shai-Hulud » :

• Récolte d'identifiants : 80+ variables d'environnement, chaîne AWS complète (env → config → IMDSv2 → ECS → Secrets Manager), PAT GitHub, jetons npm, clés SSH, jetons K8s, jetons Vault, gestionnaires de mots de passe (1Password, Bitwarden, pass, gopass)
• Persistance : démons gh-token-monitor (Vague 1) et kitty-monitor (Vague 2) via LaunchAgent/systemd ; hooks dans .claude/settings.json et .vscode/tasks.json
• Exfiltration : Réseaux P2P (Vague 1), API GitHub Git Data + HTTPS déguisé en traces OpenTelemetry (Vague 2)
• Abus CI/CD : Injection de workflow déversant toJSON(secrets), échange de jetons OIDC npm
• Interrupteur de sécurité : rm -rf ~/ si le jeton GitHub est révoqué alors que le démon est actif
• C2 par dépôt mort (Vague 2) : Interroge l'API de recherche de commits GitHub pour le mot‑clé firedalazer, commandes signées RSA-PSS

Ce que ce script vérifie

Paquets concernés

Vague 1 : TanStack (42 paquets)

Seuls @tanstack/router* et @tanstack/start* ont été concernés. NON concernés : @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store.

Voir l'avis complet pour les 42 paquets.

Vague 2 : Compte atool (314 paquets)

Tous les paquets publiés par l'utilisateur npm atool ([email protected]) ont reçu des versions malveillantes le 19 mai 2026. Les paquets à fort impact incluent :

Plus 310+ paquets principalement dans le scope @antv/* (@antv/g2, @antv/g6, @antv/l7, @antv/s2, @antv/x6, @antv/f2, etc.), ai-figure, timeago-react, jest-canvas-mock, jest-date-mock, et d'autres.

Voir l'article SafeDep pour la liste complète.

Remédiation (en cas de compromission)

CRITIQUE : Désactivez l'interrupteur de sécurité AVANT de révoquer un quelconque jeton. Le logiciel malveillant efface $HOME si les jetons sont révoqués alors que le démon est actif.

1. Tuez les démons de persistance (gh-token-monitor ET kitty-monitor) et supprimez les services LaunchAgent/systemd
2. Supprimez les fichiers de persistance (.claude/router_runtime.js, .vscode/setup.mjs, ~/.local/share/kitty/cat.py, /var/tmp/.gh_update_state, etc.)
3. Supprimez node_modules et les lockfiles, réinstallez avec --ignore-scripts
4. Révélez TOUS les identifiants (npm, GitHub, AWS, GCP, clés SSH, jetons Vault, jetons de gestionnaire de mots de passe, etc.)
5. Bloquez les domaines attaquants au niveau DNS/pare-feu (api.masscan.cloud, filev2.getsession.org, git-tanstack.com, t.m-kosche.com)

Annonces officielles et références

Vague 1 : TanStack (11 mai)

• CVE-2026-45321 (CVSS 9.6 Critique) — Enregistrement CVE
• GHSA-g7cv-rxg3-hmpx — Avis GitHub
• Post-mortem TanStack — tanstack.com/blog/npm-supply-chain-compromise-postmortem
• Suivi du durcissement TanStack — tanstack.com/blog/incident-followup
• Problème de suivi GitHub — TanStack/router#7383

Vague 2 : Prise de contrôle du compte atool (19 mai)

• Analyse SafeDep — safedep.io/mini-shai-hulud-strikes-again-314-npm-packages-compromised

Articles de chercheurs en sécurité

• Socket.dev
• Snyk
• StepSecurity (découvreurs originaux)
• Wiz
• Orca Security
• SecurityWeek

Invites de durcissement pour les agents de codage IA

Copiez-collez ces invites dans votre agent de codage IA (Claude Code, Cursor, Cline/OpenClaw, Windsurf, Hermes, etc.) pour durcir votre projet contre les attaques de la chaîne d'approvisionnement comme celle-ci.

Invite 1 : Délai de publication npm (mise en quarantaine des nouvelles versions)

Durcissez la configuration npm de ce projet contre les attaques de la chaîne d'approvisionnement. Effectuez les actions suivantes :

1. Épinglez les versions exactes : Supprimez tous les préfixes ^ et ~ de chaque dépendance dans package.json afin que npm install ne récupère jamais silencieusement une version nouvellement publiée.

2. Désactivez les scripts postinstall par défaut : Ajoutez ignore-scripts=true dans .npmrc. Ajoutez ensuite un script "preinstall" explicite dans package.json qui n'exécute que les scripts de cycle de vie connus et sûrs dont ce projet a réellement besoin (le cas échéant).

3. Imposez des installations basées uniquement sur le lockfile en CI : Assurez-vous que la CI utilise npm ci (pas npm install). S'il existe un fichier de configuration CI, vérifiez-le. Sinon, notez-le comme une étape manuelle.

4. Ajoutez la vérification de provenance : Ajoutez npm audit signatures comme étape dans le pipeline CI et comme hook git pre-push.

Invite 2 : Durcir la configuration de l'agent IA

Auditez et durcissez la configuration de l'agent de codage IA de ce projet contre les attaques par injection de la chaîne d'approvisionnement (comme la campagne TanStack/Mini Shai-Hulud qui a injecté des hooks malveillants dans .claude/settings.json et .vscode/tasks.json). Effectuez les actions suivantes :

Claude Code (.claude/) :

1. Examinez .claude/settings.json et .claude/settings.local.json pour toute entrée hooks qui exécute des commandes shell. Signalez tout ce qui exécute des fichiers .js, .mjs ou .sh — surtout s'ils proviennent de .claude/, .vscode/ ou node_modules/.
2. Supprimez tous les hooks que vous ne pouvez pas rattacher à un usage légitime et créé par l'utilisateur.

Invite 3 : Durcissement de GitHub Actions

Auditez et durcissez la configuration GitHub Actions de ce dépôt contre les attaques CI/CD de la chaîne d'approvisionnement. Effectuez les actions suivantes :

1. Supprimez ou refactorez tout déclencheur pull_request_target — ceux-ci exécutent le code du workflow dans le contexte du dépôt de base avec accès aux secrets, même lorsqu'ils sont déclenchés par un fork. Remplacez par pull_request + un workflow séparé avec validation d'approbation si nécessaire.

2. Épinglez toutes les actions tierces à des SHA de commit complets (pas des tags ou branches). Par exemple, remplacez actions/checkout@v4 par actions/checkout@<sha-complet>. Ajoutez un commentaire avec le tag pour la lisibilité.

3. Appliquez le principe du moindre privilège à chaque workflow. Ajoutez des blocs permissions: explicites. La plupart des workflows n'ont besoin que de contents: read. Les workflows de publication ont besoin de id-token: write — et rien d'autre.

4. Restreignez la portée du cache : Si vous utilisez actions/cache, assurez-vous que les clés de cache sont limitées à la branche pour éviter l'empoisonnement inter-branches. Ajoutez restore-keys avec précaution — ne restaurez pas les caches de branches non fiables.

Licence

MIT