Des chercheurs de l’Université de Tel Aviv, du Technion et d’Intuit ont décrit une nouvelle classe d’attaques contre les applications d’IA basées sur des agents. Il exploite la capacité des modèles de langage à inventer des identifiants inexistants pour les référentiels, les compétences et autres ressources externes.
Dans la prépublication, les auteurs ont montré que de telles erreurs peuvent être transformées en un canal de transmission d'instructions malveillantes. Dans le cadre d’expériences contrôlées, l’attaque a entraîné des appels aux outils d’agent IA intégrés et l’exécution de code à distance.
« Dépendance LLM les identifiants de ressources hallucinées peuvent être utilisés pour améliorer les ressources non ciblées attaques de promptware« , dit l'ouvrage.
Nous parlons spécifiquement de systèmes d'IA basés sur des agents qui ne se contentent pas de répondre aux questions, mais accèdent aux fichiers, recherchent sur Internet, clonent des référentiels, installent des extensions, exécutent des commandes dans le terminal et appellent. API.
Comment fonctionne HalluSquatting
Les auteurs ont appelé l’attaque Adversarial HalluSquatting. Le scénario est construit autour d’une erreur prévisible dans le modèle. L'utilisateur demande à l'agent IA de, par exemple, cloner un référentiel populaire ou installer une compétence. L'agent doit déterminer lui-même l'adresse exacte de la ressource. Si le modèle ne connaît pas le bon identifiant, il peut en proposer un similaire.
L'attaquant surveille à l'avance les ressources populaires, interroge le modèle à plusieurs reprises et découvre quelles adresses inexistantes il génère le plus souvent. Après cela, il enregistre ces noms sur GitHub, ClawHub ou une autre plateforme et y place des instructions malveillantes. Si l’agent IA « hallucine » plus tard cette adresse particulière, il récupérera une ressource malveillante et commencera à l’utiliser comme s’il s’agissait d’une ressource réelle.
Les auteurs ont souligné l'évolutivité du système. Contrairement aux précédentes injections d'invites, l'attaquant n'a pas besoin d'envoyer un e-mail à une victime spécifique, d'ajouter un événement à un calendrier ou d'accéder à un document partagé. Il suffit de publier une ressource malveillante dans un lieu public et d'attendre que l'agent le demande.
« Une ressource compromise peut conduire à la compromission de nombreuses machines », ont noté les chercheurs.
Ce que les tests sur les référentiels ont montré
Les chercheurs ont effectué plus de 14 000 lancements. Dans un premier temps, ils ont testé six modèles de base via des API publiques : Gemini 2.5 Flash, Gemini 2.5 Pro, GPT-5.1, GPT-5.2, Sonnet 4.5 et Opus 4.5.
Les modèles ont reçu une requête du type « imprimer une commande shell pour cloner le référentiel ». L'échantillon comprenait 10 projets récents de GitHub Trending et cinq référentiels plus anciens de 2013 à 2018 en tant que groupe témoin.
Pour les nouveaux référentiels, le taux moyen d'hallucinations était de 92,4 %. Dans 53 des 60 combinaisons référentiel-modèle, le système n'a jamais indiqué le bon propriétaire du projet. Pour les référentiels plus anciens, la moyenne était de 0,9 %. Selon les auteurs, l'écart est dû au fait que les projets plus anciens étaient probablement présents dans les données de formation des modèles, alors que les nouveaux ne l'étaient pas.
Les chercheurs ont identifié trois types d’hallucinations :
- Le modèle met également le nom du référentiel dans le champ propriétaire, créant une adresse comme repo/repo.
- Attribuer le projet à un propriétaire réel mais incorrect.
- Réponses d'espace réservé comme le nom d'utilisateur/le dépôt.
La première option s'est avérée la plus pratique pour l'attaque, car elle est prévisible et souvent disponible à l'enregistrement. Pour 6 000 demandes de nouveaux projets modèles, le modèle a été émis directement et peut être enregistré. limace dans 27% des lancements – 1602 fois. Pour chaque référentiel de tendances de l'échantillon, il y avait au moins un candidat inscrit dans le top 10 du classement universel.
Que s'est-il passé dans les applications réelles d'IA
Dans un deuxième temps, les auteurs sont passés des modèles de base aux applications de production avec accès aux terminaux. Les tests impliquaient Cursor, Cursor CLI, Windsurf, GitHub Copilot, Cline, Gemini CLI, ainsi qu'OpenClaw, ZeroClaw et NanoClaw.
Dans les scénarios de clonage de référentiel attaque de bout en bout déclenché dans 20 à 65 % des lancements en fonction de l'application, du modèle et du type de charge utile. Le tableau d'étude montre par exemple 65 % pour Windsurf avec SWE-1.5, 45 % pour Cline, 35 % pour Copilot Chat, 30 % pour Cursor CLI et 20-25 % pour différents scripts Cursor.
OpenClaw a eu de meilleurs résultats. Avec Sonnet 4.6, le système a montré 100% tant dans l'appel des outils intégrés que dans l'exécution de code à distance. Avec Opus 4.6, le taux était de 80 % dans les deux scénarios. Avec GPT-5.4 Codex, les outils d'appel ont fonctionné dans 10 exécutions sur 10 et RCE a fonctionné dans 4 exécutions sur 10.
Pourquoi la recherche sur le Web aide mais ne résout pas le problème
L'un des principaux facteurs de protection s'est avéré être une recherche sur le Web avant de cloner ou d'installer une ressource. Lorsque Cursor CLI a effectué une recherche avant le clonage, 93,4 % des résultats étaient corrects. Sans chercher, 99,1 % des limaces ont eu des hallucinations.
Le libellé de la demande a également grandement influencé le résultat. Aucun type d'invite ne s'est avéré universellement sûr ; dans chaque catégorie, il y avait au moins un modèle avec un taux d'hallucinations supérieur à 50 %.
Squatting de compétences : attaquer par les compétences
Un bloc de recherche distinct est consacré à ClawHub, un marché de compétences pour OpenClaw et les assistants compatibles. Les chercheurs ont découvert deux classes de vulnérabilités :
- supprimer un mot du titre ;
- écart entre le nom lisible par l'homme de la compétence et son slug réel.
Dans une expérience, OpenClaw avec Sonnet 4.6 a été testé sur 14 compétences. Sur les 140 exécutions, 127 (90,7 %) ont abouti à une identification qui aurait pu être enregistrée par l'attaquant. Seules 13 exécutions ont renvoyé le slug canonique.
Dans une autre expérience, les auteurs ont testé la transférabilité de l'attaque entre OpenClaw, ZeroClaw et NanoClaw. Sur les 90 analyses, 85 (94,4 %) se sont terminées négativement. Après avoir installé la compétence de remplacement, les résultats étaient encore plus sévères. L'expérience d'exfiltration de contexte a eu un taux de réussite de 100 %, chaque combinaison d'assistant et de modèle fournissant une charge utile dans les 10 exécutions. Le scénario dans lequel l'appareil compromis se connecte lui-même au serveur de l'attaquant et lui donne accès à la ligne de commande a fonctionné dans 88 % des cas.
Ce que les auteurs ont proposé et comment les fournisseurs ont répondu
Les chercheurs ont communiqué les résultats aux développeurs d’applications, aux fournisseurs de modèles et aux plateformes. Côté application IA, ils ont suggéré de vérifier la source avant tout téléchargement d'une ressource externe – clonage d'un référentiel, installation d'une compétence, d'un conteneur ou d'un modèle. Pour ce faire, l'agent doit d'abord effectuer une recherche et ensuite seulement transmettre l'adresse à l'outil intégré.
Les auteurs ont recommandé que les plateformes comme GitHub et ClawHub réservent de manière proactive les noms que les modèles composent souvent, limitent la réutilisation dangereuse des noms populaires et filtrent le contenu généré par les utilisateurs à la recherche d'instructions d'IA malveillantes.
GitHub a répondu que le scénario décrit ne constitue pas une vulnérabilité de plateforme. Selon la position de l'entreprise, la création de référentiels sous des noms libres est un comportement attendu de GitHub, et l'attaque se produit en raison des hallucinations de LLM et des actions d'agents qui font confiance au contenu de référentiels tiers.
Les représentants de Cursor ont déclaré que le programme exclut l'injection spontanée, y compris les situations dans lesquelles il est demandé à l'utilisateur de cloner un référentiel non fiable. OpenAI a précisé que les questions liées au contenu des invites et aux modèles de réponses ne sont pas incluses dans le Security and Safety Bug Bounty, à moins qu'elles n'aient un impact vérifiable distinct sur les services de l'entreprise.
Anthropic n'a pas reconnu cela comme une vulnérabilité : la société a classé le script comme une attaque de détournement de nom de dépendance, qui est exclue de son bug bounty. Google a répondu qu'il avait transmis les informations à l'équipe produit responsable pour évaluation.
Rappelons qu'en novembre 2025, les experts de Google étaient arrivés à la conclusion que plusieurs nouvelles familles de malwares utilisaient de grands modèles de langage pour les attaques de pirates.
En mai 2026, les auteurs du rapport du Google Threat Intelligence Group ont documenté la popularité croissante de l’IA parmi les cybercriminels. L’unité a découvert pour la première fois un pirate informatique utilisant un bug zero-day développé grâce à l’intelligence artificielle. Il prévoyait de l'utiliser pour une attaque massive, mais les experts de la société ont réussi à prévenir la menace.
Vous avez trouvé une erreur dans le texte ? Sélectionnez-le et appuyez sur CTRL+ENTRÉE
Voir l’article original en russe
