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)
6. Auditez les journaux du fournisseur cloud pour la période du 11 au 19 mai 2026

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.

5. Créez un script de politique de mise à jour : Créez un scripts/safe-update.sh qui :

   • Prend un nom de paquet en argument
   • Vérifie quand la dernière version a été publiée (npm view <pkg> time --json)
   • Refuse de mettre à jour si la version a moins de 3 jours
   • Si elle a plus de 3 jours, exécute npm install <pkg>@latest --save-exact
   • Affiche un résumé de ce qui a changé

Ne modifiez aucun code applicatif. Touchez uniquement les fichiers de configuration, .npmrc, les scripts package.json et la configuration CI.

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.
3. Ajoutez une règle .gitignore pour empêcher que .claude/settings.local.json soit commité (il doit rester local).

VS Code (.vscode/) :

1. Examinez .vscode/tasks.json et .vscode/launch.json pour les tâches qui exécutent des scripts ou binaires inattendus.
2. Supprimez toute entrée de tâche qui référence des fichiers comme setup.mjs, router_runtime.js ou d'autres noms qui n'appartiennent pas à ce projet.
3. Vérifiez .vscode/extensions.json pour des extensions que vous ne reconnaissez pas.

Cursor (.cursor/) :

1. Examinez .cursor/settings.json et tous les fichiers de règles pour des commandes ou hooks injectés.
2. Mêmes vérifications que VS Code ci-dessus — Cursor hérite de la configuration .vscode/.

Général :

1. Vérifiez s'il y a des scripts preinstall, postinstall, prepare ou prestart dans package.json que vous n'avez pas écrits. Signalez ceux qui sont suspects.
2. Vérifiez .github/workflows/ pour tout workflow utilisant pull_request_target — signalez-le comme un risque de sécurité avec un commentaire expliquant pourquoi.
3. Assurez-vous que .gitignore exclut les fichiers de session de l'agent qui pourraient fuiter des identifiants (.claude/projects/, .cursor/logs/, etc.).

Rapportez ce que vous avez trouvé et ce que vous avez modifié. Ne modifiez pas le code applicatif.

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.

5. Ajoutez StepSecurity Harden-Runner comme première étape de chaque job : step-security/harden-runner@v2 avec egress-policy: audit (ou block si vous connaissez vos points de terminaison autorisés).

6. Vérifiez la présence de secrets dans les journaux du workflow : Assurez-vous qu'aucune étape du workflow n'affiche ${{ secrets.* }} ou ${{ toJSON(secrets) }} dans la sortie standard.

Rapportez toutes les modifications. Ne modifiez pas le code applicatif.

Licence

MIT