Les hallucinations des IA agents, longtemps jugées inoffensives, deviennent avec HalluSquatting un vecteur d’exécution de code arbitraire

HalluSquatting exploite un réflexe des IA agents: inventer des liens “plausibles” quand une ressource n’existe pas ou n’est pas claire.

Des chercheurs montrent que ces hallucinations peuvent pousser un assistant de code à récupérer un dépôt piégé, puis à lancer des scripts malveillants sur la machine.

Le danger augmente dès que l’agent a accès au terminal, à l’installation de paquets et à des secrets de projet.

À lire aussi :

• Une opération mondiale fait tomber la “chaîne d’assemblage” du cybercrime : serveurs saisis et comptes gelés
• L’arme secrète des data centers contre les hackers ? Ce générateur quantique pourrait changer la sécurité informatique

Tel Aviv University et Technion décrivent une faille, l’URL inventée devient une arme

Le scénario est simple, et il vise le cur des usages modernes. Un développeur demande à un agent de récupérer un outil ou une bibliothèque, l’agent propose une adresse, puis exécute des commandes. Le problème apparaît quand le modèle “comble les trous” et fabrique une URL ou un dépôt GitHub qui semble crédible.

Des chercheurs de Tel Aviv University, du Technion et d’Intuit décrivent cette mécanique sous le nom de HalluSquatting, pour “adversarial hallucination squatting”. Leur point central, l’attaque ne repose pas sur une faute de frappe humaine, mais sur une sortie non déterministe du modèle, qui “rêve” un chemin standard du type propriétaire/projet.

Dans leurs tests, les agents peuvent halluciner des ressources potentiellement piégées jusqu’à 85% du temps dans certains contextes, selon les résultats rapportés. Cette fréquence rend l’attaque exploitable à l’échelle, surtout quand les équipes automatisent l’installation de dépendances ou la mise en place d’environnements.

Le risque n’est pas théorique, car l’agent agit dans une chaîne de confiance. Une fois qu’un dépôt malveillant est cloné, un script d’installation ou une commande “pratique” peut suffire à déclencher l’exécution. À partir de là, l’attaquant n’a plus besoin d’insister, le code tourne sur la machine de la cible.

Du terminal à la compromission, l’agent sert de relais d’exécution

HalluSquatting devient dangereux quand l’agent dispose de droits concrets, comme lancer des commandes, installer des paquets, modifier des fichiers. Dans beaucoup d’environnements, l’assistant a un accès direct au terminal, à des scripts de build, et parfois à des variables d’environnement contenant des secrets.

Une fois le code piégé exécuté, les conséquences classiques de compromission s’appliquent. Les chercheurs évoquent des scénarios comme une reverse shell, l’installation d’un miner, ou l’exfiltration de données. Le point de bascule tient au fait que l’utilisateur pense suivre une recommandation “normale” de l’outil.

Le modèle de menace change, car il n’y a pas forcément de lien de phishing envoyé à un humain. L’agent fabrique lui-même la destination, puis y conduit l’utilisateur, ou exécute directement. Dans une équipe, une commande validée une fois peut être recopiée, automatisée, puis réutilisée dans des pipelines.

À grande échelle, l’idée d’une “armée” d’agents compromis apparaît. Si des assistants de code sont intégrés à des parcs de machines de développement, ou à des environnements cloud, un attaquant peut viser des dépôts appâts et attendre que les agents les “découvrent”. Le coût d’attaque baisse, le gain potentiel monte.

Pourquoi ce n’est pas du typosquatting, la prédictibilité des hallucinations

Le typosquatting classique vise les erreurs humaines, un caractère en moins dans un nom de paquet, un domaine proche, une confusion visuelle. HalluSquatting vise autre chose, la tendance du modèle à produire une réponse confiante en l’absence de certitude. L’attaquant mise sur des schémas de génération répétables, comme owner/repo ou tool/tool.

Dans la pratique, un agent qui ne trouve pas une ressource peut “déduire” un chemin. Si l’attaquant a réservé le dépôt ou le paquet correspondant à ce chemin probable, il n’a plus qu’à préparer un contenu qui ressemble à l’outil attendu. Le piège fonctionne d’autant mieux que l’agent cherche à être utile et rapide.

Le vecteur est renforcé par l’habitude de demander “installe X” ou “récupère le repo officiel”. Le mot “officiel” n’a aucune valeur technique, et le modèle peut l’interpréter comme un signal de confiance, pas comme une exigence de vérification. Dans un flux de travail pressé, l’utilisateur valide.

Voici une comparaison des deux approches, pour clarifier le mécanisme et les défenses associées.

Copilot, Cursor et autres assistants, la tentation du “mode autopilote”

Les assistants de code sont de plus en plus “agentiques”, ils ne se contentent plus de suggérer une ligne, ils enchaînent des actions. Dans ce contexte, l’accès au shell et aux outils système devient un accélérateur de productivité, mais aussi un multiplicateur de risque.

Le problème n’est pas un produit unique, mais une classe de comportements. Dès qu’un agent peut appeler des outils, résoudre des dépendances, cloner des repos et lancer des scripts, il devient une surface d’attaque. Les chercheurs parlent d’une faiblesse “fondamentale” car la non-fiabilité factuelle n’est pas un bug isolé.

Un exemple concret, demander “installe la dernière version de tel utilitaire de tests” dans un projet inconnu. Si l’agent ne connaît pas la source officielle, il peut proposer un dépôt plausible, puis exécuter un script d’installation. Un dépôt appât peut afficher un README rassurant et livrer un script discret.

Ce risque est plus élevé quand les équipes laissent l’agent opérer avec peu de friction, validation automatique des commandes, absence de revue, ou exécution dans l’environnement principal. Dans une organisation, la même demande répétée par plusieurs développeurs peut créer une exposition cumulative.

Mesures concrètes, verrouiller les sources et réduire les droits des agents

La première défense consiste à casser la chaîne “suggestion, exécution”. Un agent peut proposer, mais l’exécution doit rester sous contrôle, avec une vérification de la source. Concrètement, imposer une allowlist de domaines, d’organisations GitHub, ou de registres, et bloquer le reste au niveau réseau.

Deuxième levier, réduire les permissions. Un agent qui peut lire le code mais pas exécuter de commandes limite l’impact. Quand l’exécution est nécessaire, elle peut se faire dans une sandbox ou un conteneur jetable, sans accès aux secrets, ni au système hôte. Les environnements éphémères réduisent la persistance.

Troisième levier, renforcer l’hygiène de dépendances. Verrouiller les versions, exiger des hash ou des signatures quand c’est possible, et privilégier des sources vérifiées. Pour les dépôts, pointer vers des URLs explicitement validées, pas vers des “devine-moi le repo officiel”.

Enfin, surveiller ce que fait l’agent. Journaliser les commandes, alerter sur les clones depuis des comptes inconnus, et traiter les scripts d’installation comme du code à risque. Le gain de temps de l’automatisation reste réel, mais il doit s’acheter avec des garde-fous, pas avec une confiance implicite dans des sorties probabilistes.