Ce qui change
Un script d’installation a tenté d’assurer sa persistance « via les hooks de Claude Code et le fichier tasks.json de VS Code » 1. Le 4 août 2026, des versions malveillantes de keyv, flat-cache et file-entry-cache, dont le cumul dépasse 500 millions de téléchargements hebdomadaires, ont commencé à exécuter un voleur d’identifiants à l’installation. Endor Labs indique que la charge a depuis été republiée dans des centaines d’autres paquets sous plusieurs comptes de mainteneurs 2. Elle vise les identifiants cloud, les secrets d’infrastructure et les fichiers de configuration liés à l’IA, et tente aussi de récolter les secrets des environnements CI/CD 1. Les données sortent par des dépôts GitHub créés sous des identités compromises, description par défaut « Shai-Hulud: Here We Go Again » 1.
Ce que le nettoyage laisse passer
Le vol est banal. L’intéressant, c’est où la charge s’installe : un hook est une commande que votre agent lance sur ses propres événements, et en écrire un procure une réexécution sans démon, sans shell, sans cron, et cela rend à mon sens incomplet le réflexe habituel, supprimer l’arborescence de dépendances et réinstaller propre. Il récure le répertoire d’entrée du paquet et laisse le fichier visé. Une configuration d’agent versionnée est pire : commitée, relue comme de la configuration, récupérée par l’équipe. Le deuxième saut emprunte git et non le registre, et les flux d’avis de sécurité que je suis ne surveillent pas cette route.
Trois commandes, sur le poste et sur la machine de build ; la troisième demande si votre organisation héberge déjà un dépôt d’exfiltration 1 :
npm ls keyv flat-cache file-entry-cache
git log -p --all -- <votre-config-agent> '**/tasks.json'
gh search repos "Shai-Hulud: Here We Go Again" --owner <votre-organisation>
Impact pour une équipe
Je n’ai vu passer aucune version saine, et la charge a été republiée sous plusieurs comptes de mainteneurs 2 : traitez cela comme un renouvellement d’identifiants plutôt que comme un épinglage. Renouvelez tout identifiant lisible par un script d’installation ou présent dans une configuration d’agent, postes et machines de build compris, jetons de CI en premier 1. Tranchez ensuite : la configuration d’agent de votre dépôt est-elle du code relu en revue, ou un fichier que n’importe quelle installation peut écrire ? Sur la plupart des dépôts que j’ai vus, c’est la seconde réponse : la seule partie de l’incident qui vous appartienne.