Sept outils d’agents compromis : leurs hooks exécutent la mise à jour

Une prépublication soumise le 3 septembre 2026 décrit une attaque de chaîne d’approvisionnement contre les hooks de cycle de vie de sept environnements d’agents IA. Dans l’étude présentant HookPry, une mise à jour transforme un plugin initialement bénin en support de commandes malveillantes, ensuite exécutées automatiquement lors d’événements ordinaires.
Les sept environnements ont été compromis pendant des essais contrôlés, et non lors d’intrusions observées chez des utilisateurs. Sur 1 000 exécutions couvrant 25 combinaisons d’environnements et de modèles, HookPry a produit un effet malveillant vérifié dans chacun des sept outils évalués ; le meilleur taux par environnement atteint 92,5 %.
La mise à jour conserve l’identité du plugin, mais change son autorité

Le scénario commence par l’installation normale d’une version dépourvue de charge malveillante. L’attaquant publie ensuite, sous la même identité, une version dont la configuration ajoute ou modifie un hook reliant un événement de cycle de vie à une commande shell.
Cette distinction éclaire le titre : le hook n’installe pas lui-même la nouvelle version, mais il exécute les commandes introduites par cette mise à jour. Une ouverture de session, un appel d’outil, une modification de fichier ou l’ouverture d’un projet peut suffire à déclencher le processus configuré.
La commande ne suit pas nécessairement le chemin de décision du modèle. Une fois l’événement produit, l’environnement associe le hook à la commande et lance le sous-processus ; le modèle peut ne jamais voir cette commande, la proposer ou être invité à l’approuver. L’effet reste toutefois limité par trois conditions : la mise à jour doit être adoptée, l’événement doit survenir et le sous-processus ne peut agir qu’avec les privilèges qui lui sont accordés.
Les sept environnements ont cédé, sans taux uniforme

HookPry met en œuvre dix objectifs allant de la collecte d’identifiants et de l’exfiltration à la persistance, à l’altération de fichiers et à l’élévation de privilèges. Au total, 77 % des 1 000 exécutions ont produit un effet confirmé par un mécanisme de vérification externe. Le taux maximal de 92,5 % concerne Hermes ; il ne décrit donc ni tous les outils, ni toutes les attaques.
Le test des défenses portait sur 40 artefacts malveillants et 40 contrôles bénins synthétiques. Microsoft Defender n’a détecté aucun des 40 artefacts malveillants ; HookPolicy en a détecté 20 et une configuration de Semgrep fondée sur cinq règles en a détecté 19. Leur union en a reconnu 21 et manqué 19, soit 47,5 %.
Ces résultats ne constituent pas une mesure générale des performances de Microsoft Defender ou de l’analyse statique. HookPolicy et Semgrep étaient des configurations de recherche, les contrôles bénins étaient synthétiques, et ni l’analyse comportementale ni les produits spécialisés de sécurité de la chaîne d’approvisionnement n’ont été évalués. Une analyse indépendante du scénario HookPry souligne en outre que les taux publiés n’ont pas encore fait l’objet d’une reproduction séparée.
L’audit doit mesurer ce qui change entre deux manifestes

Le modèle de menace déplace le contrôle utile du nom du plugin vers son autorité effective. L’inventaire doit associer chaque hook à sa version, à son événement déclencheur, à la commande ou au script lancé, au répertoire de travail, aux accès réseau, aux secrets disponibles et à l’identité système du sous-processus.
À chaque mise à jour, une comparaison sémantique entre l’ancien et le nouveau manifeste doit faire ressortir les nouveaux événements, commandes, chemins de scripts et destinations réseau, ainsi que tout élargissement de l’accès aux fichiers, aux variables d’environnement ou aux identifiants. Une modification de cette nature correspond à un changement de permission, même si l’identité publique du plugin ne varie pas.
- Soumettre les hooks modifiés à une nouvelle autorisation, liée à la configuration réellement installée et non au seul nom du paquet.
- Épingler la version et vérifier l’intégrité lorsque l’environnement ne sait pas distinguer une correction fonctionnelle d’un élargissement d’autorité. La suspension des mises à jour automatiques réduit alors l’exposition, sans constituer une protection complète.
- Limiter les privilèges du sous-processus avec une identité dédiée, une vue restreinte du système de fichiers, des secrets circonscrits à la tâche et des règles réseau adaptées.
- Conserver la provenance de l’exécution : version du plugin, empreinte de la configuration, événement déclencheur, commande, contexte de sécurité et résultat.
La surveillance doit viser les processus réellement lancés par les hooks, et pas seulement les actions que le modèle déclare avoir choisies. Une commande absente du manifeste précédemment autorisé, un processus enfant inattendu ou une nouvelle connexion réseau après une mise à jour sont des écarts directement observables.
Le résultat concerne le runtime, pas seulement les prompts
HookPry montre qu’une protection centrée sur l’injection de prompt, les refus du modèle ou ses appels d’outils ne couvre pas automatiquement la configuration exécutable de l’environnement. Une synthèse de la surface d’attaque des agents, soumise en mars puis révisée en août 2026, classait déjà les API d’outils robustes, les comportements vérifiables et les protections de chaîne d’approvisionnement parmi les problèmes encore ouverts.
Les limites de HookPry restent importantes : les expériences ont utilisé des environnements éphémères, des ressources synthétiques, cinq backends de modèles et 40 cas d’attaque. Elles ne couvrent pas tous les systèmes d’exploitation, shells, réseaux, politiques d’entreprise, versions futures ou taux réels d’adoption des plugins et de leurs mises à jour. Les failles d’implémentation, les évasions de sandbox et l’installation forcée étaient exclues du modèle de menace.
Le constat établi est donc précis : une mise à jour de configuration a suffi à obtenir au moins un effet malveillant dans chacun des sept environnements testés. Il ne prouve ni une campagne active, ni une exposition identique de tous les agents IA. La suite dépendra de reproductions indépendantes et des réponses des éditeurs ; dans l’intervalle, les manifestes de hooks, leurs privilèges et leurs processus doivent être traités comme une même chaîne d’autorisation.
À lire aussi:
Abonnez-vous à notre newsletter
Recevez directement les dernières actualités sur le Web3, l’IA et les cryptomonnaies.