HalluSquatting : l’attaque IA qui transforme les hallucinations en botnet - êtes-vous prêt ?

73 % des développeurs utilisent désormais un assistant de codage IA au quotidien, selon une enquête Stack Overflow 2025. Mais que se passe-t-il lorsque l’outil censé vous faire gagner du temps invente un nom de bibliothèque qui n’existe pas, et que ce nom est déjà piégé par un attaquant ? C’est le scénario que dévoile une équipe de chercheurs israéliens sous le nom de HalluSquatting. Cette technique combine deux failles bien connues de l’intelligence artificielle - l’hallucination et l’injection de prompt - pour transformer un assistant de codage en vecteur d’infection silencieux. Dans cet article, nous décortiquons le mécanisme, les risques réels pour les équipes de cybersécurité françaises, et surtout les mesures concrètes pour s’en protéger, en nous appuyant sur les standards ANSSI et les bonnes pratiques RGPD.

HalluSquatting : quand l’IA invente le piège

Le principe est aussi simple que redoutable. Un assistant IA, sollicité pour récupérer un outil populaire, peut générer un nom plausible mais totalement fictif - c’est ce qu’on appelle une hallucination. L’attaquant va alors systématiquement provoquer cette erreur, noter le nom inventé le plus fréquent, l’enregistrer sur une plateforme comme GitHub ou un store de plugins, et y cacher des instructions malveillantes. Lorsqu’un développeur demande à son assistant de récupérer le même outil, celui-ci invoque le nom piégé, exécute les instructions et installe un logiciel malveillant, sans que l’utilisateur n’ait rien vu.

Les deux piliers de l’attaque : hallucination + injection indirecte

L’attaque exploite deux comportements intrinsèques des grands modèles de langage (LLM) :

1. L’hallucination : le modèle invente une information en la présentant comme factuelle. Dans le contexte du codage, cela se traduit par des noms de paquets, de dépôts ou de plugins qui n’existent pas.
2. L’injection indirecte de prompt : les instructions malveillantes sont dissimulées dans le contenu récupéré par l’assistant, sans que l’utilisateur les ait jamais tapées. L’assistant les intègre alors à son propre contexte et les exécute comme si elles venaient de l’utilisateur.

« L’hallucination n’est plus un simple bug - c’est une surface d’attaque exploitable. » - Aya Spira, chercheuse à l’Université de Tel Aviv.

Le scénario en quatre étapes

1. Cibler un outil tendance : l’attaquant identifie un dépôt ou un plugin qui monte en popularité. Plus il est demandé, plus l’assistant risque d’halluciner son nom.
2. Forcer l’erreur : il interroge répétitivement l’IA sur cet outil et relève le nom inventé le plus fréquent.
3. Piéger le nom : il crée un compte sur GitHub ou sur un store, dépose un contenu sous ce nom fictif, et y cache des instructions malveillantes.
4. Attendre la victime : un développeur légitime demande à son assistant d’installer l’outil. L’assistant invoque le nom piégé, exécute les instructions, et installe un botnet.

Dans les expériences menées, le taux de succès atteignait 85 % pour les requêtes de dépôts et 100 % pour les installations de compétences (skills), et ce de manière cohérente entre différents modèles et formulations.

Pourquoi c’est une menace inédite pour les développeurs français

Le paysage cyber français est particulièrement exposé. Avec l’adoption massive d’outils comme GitHub Copilot, Cursor, Windsurf, Cline, Gemini CLI ou la famille OpenClaw, les équipes de développement intègrent ces assistants dans leurs pipelines CI/CD sans toujours mesurer les risques.

Une attaque qui contourne les défenses classiques

Contrairement à un botnet traditionnel qui exploite des mots de passe faibles ou des vulnérabilités réseau, HalluSquatting n’a besoin :

• D’aucun mot de passe à voler,
• D’aucune faille réseau à exploiter,
• D’aucun type de machine spécifique (Windows, Linux, macOS - tout fonctionne).

Le vecteur d’attaque est le texte lui-même : l’assistant lit le contenu piégé et agit. Les pare-feux traditionnels ne voient rien d’anormal, car il n’y a pas d’exploit réseau.

« L’IA est le véhicule de livraison, pas la cargaison. » - Ron Bitton, chercheur chez Intuit.

Un précédent inquiétant : le slopsquatting et le phantom squatting

Cette attaque s’inscrit dans une tendance plus large. En janvier 2026, Charlie Eriksen (Aikido Security) avait découvert un paquet npm fictif, react-codeshift, déjà présent dans 237 projets, avec des agents tentant encore de l’installer quotidiennement. Il l’a enregistré lui-même pour éviter tout dommage. En mai 2026, Palo Alto Networks (Unit 42) décrivait le phantom squatting : environ 250 000 noms de domaine hallucinés par les IA, laissés sans propriétaire et donc disponibles à l’enregistrement.

HalluSquatting va plus loin : il ne se contente pas de rediriger vers un site malveillant, il force l’assistant à exécuter du code sur la machine de l’utilisateur. Et les marketplaces ne sont pas une barrière efficace : en juin 2026, Trail of Bits a réussi à soumettre des compétences malveillantes passant inaperçues auprès de plusieurs scanners de stores en moins d’une heure.

Comment se protéger : mesures techniques et organisationnelles

Face à cette menace, les équipes de sécurité françaises doivent adopter une approche multicouche, alignée sur les recommandations de l’ANSSI et les principes de défense en profondeur.

1. Désactiver les modes automatiques non supervisés

La plupart des assistants proposent un mode « auto » ou « yolo » qui exécute les commandes sans demander de confirmation. C’est la porte d’entrée numéro un.

Règle d’or : un assistant ne doit jamais exécuter une commande non vérifiée issue d’une source externe.

2. Imposer une vérification préalable des ressources

Avant qu’un assistant ne télécharge ou n’installe un paquet, il doit :

1. Rechercher le nom dans un registre officiel (npm, PyPI, GitHub) pour confirmer son existence.
2. Vérifier que le propriétaire du dépôt correspond bien à l’éditeur attendu.
3. Comparer le hash de l’archive avec une signature connue.

Les concepteurs d’outils peuvent intégrer cette vérification dans le planner de l’IA, en faisant des mots comme clone, install ou fetch des déclencheurs de vérification obligatoire.

3. Former les développeurs à la « méfiance IA »

Chaque développeur doit intégrer ces réflexes :

• Ne jamais faire confiance à un nom d’outil généré par l’IA sans vérification manuelle.
• Considérer toute suggestion de paquet ou de dépôt comme potentiellement fictive.
• Signaler immédiatement toute tentative d’installation inhabituelle.

« Traitez tout nom qu’un assistant vous donne comme une hypothèse, pas un fait. » - Aya Spira.

4. Durcir les plateformes et les marketplaces

Les gestionnaires de registres (npm, GitHub, stores de plugins) doivent :

• Pré-enregistrer les noms fictifs que les IA inventent le plus souvent, comme on le fait déjà contre le typosquatting.
• Bloquer la réutilisation de noms de dépôts connus sous de nouveaux comptes.
• Auditer les soumissions avec des scanners comportementaux, pas seulement des signatures statiques.

5. Mettre en place une supervision active

Les équipes SOC doivent maintenir une veille cyber multi-sources et surveiller :

• Les connexions sortantes vers des dépôts GitHub récemment créés.
• Les installations de paquets dont le nom ne correspond à aucun projet connu.
• Les exécutions de commandes par des processus d’IA (identifiables via leur ligne de commande).

Un outil comme Wazuh (open source) peut être configuré pour alerter sur ces comportements, en corrélant les logs des postes de développement.

Cas concret : comment une PME française a failli tomber dans le piège

Prenons l’exemple fictif mais réaliste d’InnoDev, une PME de 50 développeurs basée à Lyon. L’équipe utilise Cursor en mode agent pour automatiser l’intégration de nouvelles bibliothèques open source. Un matin, un développeur demande à l’assistant d’ajouter une librairie de traitement d’images récemment devenue populaire. L’assistant, n’ayant pas cette référence dans son entraînement, invente le nom image-optimizer-pro. Ce nom a été préalablement enregistré par un attaquant sur GitHub, avec un README.md contenant une injection de prompt.

L’assistant télécharge le dépôt, lit les instructions cachées, et exécute une commande qui installe un botnet de type Mirai modifié pour exfiltrer les identifiants de connexion. Heureusement, le SOC de l’hébergeur détecte un trafic anormal vers un serveur en Roumanie, et l’incident est stoppé avant toute compromission.

Ce qui a sauvé InnoDev :

• Une règle de pare-feu bloquant les connexions sortantes vers des IP inconnues.
• Une politique de confirmation manuelle obligatoire pour toute installation de paquet.
• Une formation mensuelle des développeurs aux nouvelles menaces IA, appuyée par des ressources comme les meilleurs livres cybersécurité à lire en 2025.

Les limites de la recherche et les perspectives

Les chercheurs de l’Université de Tel Aviv (Aya Spira, Stav Cohen, Ron Bitton, Ben Nassi) ont testé leur attaque sur Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI et OpenClaw. Tous ont exécuté le code malveillant. Les charges utiles étaient des placeholders inoffensifs, mais le chemin est le même pour un vrai malware.

« Les attaques ne font que s’améliorer, jamais l’inverse. » - Les chercheurs.

Ils ont prévenu les éditeurs et les opérateurs de marketplaces avant la publication, et n’ont pas divulgué les étapes exactes de reproduction. Mais le principe est désormais public, et il est probable que des variantes émergent rapidement, à l’image des défis posés par la cryptographie post-quantique.

Questions encore ouvertes :

• Comment détecter une hallucination malveillante avant qu’elle ne soit exploitée ?
• Les modèles open source (Llama, Mistral) sont-ils aussi vulnérables que les modèles propriétaires ?
• Faut-il un label de sécurité pour les assistants de codage, à l’image de la certification ANSSI CSPN pour les produits de sécurité ?

Conclusion : l’IA ne doit jamais être votre seul filet de sécurité

HalluSquatting n’est pas une faille CVE à corriger avec un patch. C’est une faiblesse architecturale des systèmes d’IA qui confondent plausibilité et réalité. Pour les DSI et RSSI français, le message est clair : ne laissez jamais un assistant IA agir sans supervision humaine sur des ressources externes. Les mesures de bon sens - confirmation manuelle, vérification préalable, formation des équipes - restent les plus efficaces. En attendant que les éditeurs intègrent des garde-fous robustes, c’est à vous de définir les règles du jeu. La cybersécurité ne se délègue pas à une machine, même intelligente.

Prochaine action : auditez dès aujourd’hui les droits accordés à vos assistants de codage. Si l’un d’eux peut exécuter des commandes sans votre accord, vous êtes déjà vulnérable.