Qu'est-ce que le slopsquatting ? L'attaque HalluSquatting sur les agents de code IA

Qu'est-ce que le slopsquatting ?

Le slopsquatting consiste à enregistrer un nom de paquet logiciel qui n'existe pas mais qu'un grand modèle de langage est susceptible d'halluciner, afin qu'un développeur ou un agent IA installe le paquet de l'attaquant en le croyant légitime. Le terme a été forgé par Seth Larson, Security Developer-in-Residence à la Python Software Foundation, en avril 2025, comme un mot-valise formé de « AI slop » (la bouillie produite par l'IA) et de « typosquatting ».

Deux idées le sous-tendent, et il est utile de les distinguer. L'hallucination de paquets est le comportement du modèle : un LLM, à qui l'on demande d'écrire du code, référence une cible d'installation qui n'a jamais été publiée. Le slopsquatting est l'attaque qui transforme ce comportement en mécanisme de livraison, en revendiquant le premier le nom halluciné. L'hallucination est la vulnérabilité ; le slopsquatting est l'exploitation.

“

Un humain qui lit « pip install reqwest-py » pourrait s'arrêter et vérifier. Un agent lance la commande. À l'instant où un nom de paquet passe d'une suggestion qu'une personne tape à une action qu'un agent exécute, le dernier point de contrôle humain disparaît.

Slopsquatting et typosquatting : quelle différence ?

Ce sont deux attaques par confusion de noms sur la chaîne d'approvisionnement logicielle, mais elles exploitent des erreurs différentes et, surtout, elles échappent à des défenses différentes.

La différence porteuse est la troisième ligne. Les défenses contre le typosquatting supposent que le nom malveillant ressemble à un vrai, donc elles signalent les paquets situés à une faible distance d'édition des bibliothèques populaires. Un nom halluciné n'est la faute d'orthographe de rien. L'analyse de Socket sur les noms hallucinés a trouvé que près de la moitié étaient très dissemblables de tout vrai paquet, fabriqués mais crédibles en contexte, ce qui explique précisément pourquoi la détection de sosies passe à côté sans les voir.

Comment se déroule concrètement une attaque de slopsquatting ?

L'attaque compte quatre étapes, et le plus inconfortable est que l'attaquant n'a pas besoin de deviner. Le modèle lui dit quoi enregistrer.

Ce qui rend l'étape deux exploitable, c'est que les hallucinations ne sont pas du bruit aléatoire. Dans la plus vaste étude à ce jour, les chercheurs ont relancé le même prompt dix fois et ont constaté que 43 % des noms de paquets hallucinés réapparaissaient dans les dix passages, et que 58 % réapparaissaient plus d'une fois. Le modèle n'invente pas un faux nom différent à chaque fois ; il gravite vers les mêmes. Un attaquant peut récolter ces noms en masse, enregistrer les plus tenaces, et attendre. Parce que les agents en modes autonomes ou « yolo » installent et exécutent sans confirmation, le hook post-installation de la charge utile se déclenche à l'instant où le paquet atterrit, avant même qu'une pull request n'existe pour être relue.

À quel point les paquets hallucinés sont-ils fréquents ?

Assez fréquents pour être un canal de distribution plutôt qu'un cas marginal. La mesure de référence est l'étude USENIX Security 2025 « We Have a Package for You! » de l'University of Texas at San Antonio et de Virginia Tech, qui a analysé 2,23 millions d'échantillons de code générés par 16 modèles en Python et JavaScript.

Le taux n'est pas uniforme. Les modèles open source ont halluciné des paquets dans 21,7 % des échantillons contre 5,2 % pour les modèles commerciaux, un écart d'environ un facteur quatre, et certains modèles spécialisés dans le code ont inventé un paquet dans plus d'un tiers de leurs sorties. Deux forces poussent ensuite le risque à la hausse avec le temps, pas à la baisse : les équipes laissent de plus en plus les agents écrire et installer les dépendances sans surveillance, et les mêmes modèles continuent de suggérer les mêmes noms fabriqués à tous ceux qui les interrogent.

Le slopsquatting s'est-il déjà produit dans la vraie vie ?

Oui, et la preuve précède le nom. Fin 2023, le chercheur en sécurité Bar Lanyado, de Lasso Security, a remarqué que plusieurs modèles hallucinaient de façon répétée un paquet Python nommé huggingface-cli. En guise de preuve de concept inoffensive, il a publié un paquet vide sous ce nom. En trois mois, il avait été téléchargé plus de 30 000 fois et, comme The Register l'a rapporté, une grande entreprise (Alibaba) référençait la commande d'installation dans le README de l'un de ses propres dépôts de recherche. Le paquet était bénin. Un acteur malveillant qui aurait guetté la même hallucination ne l'aurait pas été.

Le retournement de 2026, c'est que les agents IA propagent désormais ces noms à votre place. La note de recherche de la Cloud Security Alliance d'avril 2026 sur le slopsquatting documente comment des commandes d'installation hallucinées se propagent à travers des fichiers « agent skill » copiés-collés. Dans un cas de janvier 2026, un paquet npm fabriqué (un nom qu'un modèle a produit en fusionnant deux vrais outils) était déjà référencé par 237 dépôts GitHub avant que quiconque ne le signale, semé en grande partie par un unique commit qui ajoutait des dizaines de fichiers de compétences générés par LLM. L'hallucination n'est pas restée dans une seule fenêtre de chat ; elle a été commitée, partagée et réexécutée par chaque agent qui a lu la compétence.

Qu'est-ce que l'attaque HalluSquatting (juillet 2026) ?

Pendant la majeure partie de la courte histoire du slopsquatting, l'attaquant était opportuniste : enregistrer les noms que le modèle privilégie, puis attendre. Un article publié le 8 juillet 2026, « Beware of Agentic Botnets » de Spira, Cohen, Feldman, Bitton, Wool et Nassi (Tel Aviv University, Technion et Intuit), supprime l'attente. Il démontre un déclencheur adverse universel et transférable qui force les agents à halluciner une ressource précise, choisie par l'attaquant, à la demande, plutôt que d'espérer qu'ils tombent sur une ressource que l'attaquant possède déjà.

Le mécanisme chaîne deux défaillances décrites plus haut. D'abord, le déclencheur oriente l'agent vers la récupération d'une ressource (un dépôt, une compétence, un paquet) sous un nom que l'attaquant contrôle. Ensuite, une injection de prompt indirecte dissimulée dans cette ressource récupérée s'exécute lorsque le terminal de l'agent la lance, obtenant une exécution d'outil à distance et installant un logiciel malveillant de botnet auto-propagateur. Les chercheurs présentent le résultat comme une attaque non ciblée et scalable : un seul déclencheur adverse, aucune préparation par victime, un logiciel malveillant qui se propage d'un agent compromis au suivant.

Pourquoi un scanner ne peut-il pas l'attraper ?

Parce que les deux contrôles sur lesquels la plupart des équipes s'appuient regardent au mauvais endroit ou arrivent trop tard.

Lisez la colonne de droite de haut en bas et un thème unique émerge. Chacun de ces contrôles agit sur le paquet une fois qu'il est sur le disque, ou cherche une ressemblance qu'un nom fabriqué n'a pas. Le script d'installation d'une dépendance malveillante s'exécute au moment de l'installation, ce qui, pour un agent autonome, se produit quelques secondes après que le modèle a inventé le nom, et bien avant qu'un scanner, un relecteur ou un flux de CVE ne pèse dans la balance. Le seul endroit où l'arrêter est avant que la commande d'installation ne s'exécute.

Comment prévenir le slopsquatting

Aucune de ces mesures n'est exotique. La discipline consiste à les appliquer à des agents qui avancent plus vite que les humains qui les supervisent.

1. Coupez l'auto-installation aveugle. N'exécutez pas les agents en modes entièrement autonomes « installe et exécute » face à de vrais identifiants. Exigez une approbation explicite pour toute nouvelle dépendance, afin qu'un nom fabriqué doive passer sous au moins un regard humain.

2. Vérifiez qu'un paquet existe et est réel avant de l'ajouter. « Il s'est installé » n'est pas une preuve de légitimité ; l'attaquant a fait en sorte qu'il s'installe. Vérifiez que le paquet a un vrai historique : âge, trajectoire de téléchargement, un vrai dépôt source, des mainteneurs nommés. Un paquet enregistré la semaine dernière qu'un modèle jure être standard, c'est exactement la forme de cette attaque.

3. Épinglez les versions et commitez des lockfiles avec des empreintes d'intégrité. Un lockfile avec des empreintes signifie qu'une version substituée ou nouvellement empoisonnée ne peut pas se glisser en silence, et il rend une nouvelle dépendance visible comme un changement relisable plutôt qu'un ajout transitif invisible.

4. Restreignez la provenance des paquets. Utilisez un miroir interne, un registre privé ou une liste blanche pour que l'agent ne puisse installer que depuis des sources validées. Si un nom halluciné n'est pas dans le miroir, l'installation échoue de façon sûre au lieu de contacter le registre public.

5. Exécutez l'analyse de composition logicielle (SCA), comme filet de sécurité. La SCA vaut la peine d'être lancée sur chaque nouvelle dépendance, mais traitez-la comme le dernier filet, pas le premier. Elle attrape les paquets et versions déjà connus comme mauvais ; elle n'attrapera pas un paquet malveillant zero-day le jour où il est enregistré.

6. Relisez spécifiquement les nouvelles dépendances. Faites de « ce changement ajoute-t-il une dépendance ? » une étape de relecture explicite. Une ligne ajoutée à package.json ou requirements.txt mérite plus de vigilance que cent lignes de logique métier, car elle importe le code de quelqu'un d'autre avec vos privilèges.

7. Isolez le travail d'agent non fiable. Quand un agent tourne face à un dépôt inconnu ou à du contenu tiers, donnez-lui un conteneur sans secret hôte et sans chemin vers la production. Les scripts d'installation s'exécutent immédiatement, donc un agent détourné ne devrait rien avoir de précieux à portée lorsque l'un d'eux se déclenche.

8. Traitez les paquets suggérés par l'agent comme une entrée non fiable. L'assurance de la suggestion n'est pas une preuve. Un nom que le modèle présente comme évident est précisément le nom dont un attaquant a déjà vérifié que le modèle l'apprécie.

Là où la prévention doit vivre : l'application des règles au moment de l'agent

Reparcourez cette liste et les contrôles efficaces partagent une propriété : ils agissent avant que la commande d'installation ne s'exécute. Le scanner qui lit un diff, le flux de SCA, la base de données de CVE, ils arrivent tous après que l'agent a déjà récupéré et exécuté le paquet. À la cadence de l'agent, c'est trop tard. L'endroit où imposer « n'installe pas un paquet que tu ne peux pas vérifier » est à l'intérieur de la boucle de l'agent, à l'instant où l'agent tend la main vers la commande d'installation.

C'est la couche qu'ajoute VibeDefend. C'est un CLI npm gratuit qui s'installe en environ cinq secondes et branche vos agents de code IA (Claude Code, OpenAI Codex, Cursor, Windsurf et VS Code Copilot) sur une gouvernance qui tourne pendant qu'ils travaillent, pas après.

Deux des quatre couches correspondent directement à cette attaque. Le garde-fou d'actions (Action Guard) intercepte l'action risquée avant qu'elle ne se déclenche : l'installation d'un paquet non vérifié, tout neuf, ou absent de votre liste blanche est signalée par un avertissement ou bloquée, l'interception étant consignée dans la piste d'audit, de sorte que la dépendance fabriquée n'atteint jamais l'étape d'installation. Les règles de sécurité (Security Rules) chargent la discipline elle-même dans le contexte de l'agent avant qu'il n'écrive, de sorte que « vérifie qu'une dépendance existe et est de confiance avant de l'ajouter » est une règle que l'agent lit au moment du prompt plutôt qu'un point de checklist que personne n'a appliqué. À leurs côtés, Live Findings garde chaque résultat des scanners de CybeDefend (SAST avec atteignabilité, SCA, secrets, IaC et CI/CD) en direct dans le contexte de l'agent, de sorte qu'un problème de dépendance est trié dans la boucle au lieu de remonter des jours plus tard.

Et la SCA de CybeDefend rafraîchit son renseignement sur les vulnérabilités en continu, avec une nouvelle synchronisation environ toutes les quinze minutes, de sorte qu'à l'instant où un paquet est divulgué comme malveillant, il remonte dans l'agent en quelques minutes plutôt qu'au prochain scan nocturne, et chaque dépendance que l'agent importe est vérifiée dans la boucle. Les deux couches comblent mutuellement leurs angles morts : le garde-fou d'actions (Action Guard) empêche l'installation d'un paquet tout neuf que personne n'a encore signalé, et la SCA rafraîchie en continu attrape ceux qui ne se révèlent malveillants que plus tard.

Surtout, rien de votre code ne transite par le réseau. Les décisions se prennent localement, à côté de l'agent ; seules des métadonnées de gouvernance structurées (la règle qui s'est déclenchée, le chemin du fichier, la sévérité, un horodatage) atteignent le backend, et les tenants UE et US sont physiquement séparés. Ce n'est pas un remplacement des lockfiles, des listes blanches et de la relecture humaine. C'est la couche qui les rend applicables à la vitesse à laquelle un agent travaille réellement, de sorte que l'installation d'un paquet qui n'a jamais existé est arrêtée avant qu'elle ne se produise, au lieu d'être investiguée après.

CybeDefend est la couche AppSec au moment de l'agent conçue précisément pour cela. Elle relie chaque agent de code IA de votre poste à vos règles métier, à vos référentiels de sécurité (OWASP, SOC 2, GDPR, ISO 27001), à un garde-fou d'actions (Action Guard) qui bloque les installations risquées ou non vérifiées avant qu'elles ne s'exécutent, et à une analyse rafraîchie en continu de chaque dépendance et de chaque ligne que l'agent écrit. Le slopsquatting ne fonctionne que dans l'intervalle entre un modèle qui invente un nom et un humain qui s'en aperçoit. CybeDefend referme cet intervalle, à l'intérieur de la boucle, avant même qu'une pull request ne soit ouverte.

Foire aux questions

Qu'est-ce que le slopsquatting ?

Le slopsquatting est une attaque sur la chaîne d'approvisionnement logicielle (supply chain) qui enregistre un nom de paquet qu'un modèle IA est susceptible d'halluciner, afin que des développeurs et des agents de code IA installent le paquet malveillant de l'attaquant en le croyant être une vraie dépendance. Le terme, forgé par Seth Larson de la Python Software Foundation en avril 2025, combine « AI slop » et « typosquatting ». Il fonctionne parce que les grands modèles de langage inventent des noms de paquets plausibles qui n'existent pas, et qu'ils inventent les mêmes de façon cohérente, offrant aux attaquants une liste prévisible de noms à revendiquer.

Quelle est la différence entre le slopsquatting et le typosquatting ?

Le typosquatting exploite les erreurs de frappe humaines en enregistrant des noms qui ressemblent étroitement à de vrais paquets, il peut donc être détecté en mesurant la distance de chaîne par rapport aux bibliothèques populaires. Le slopsquatting exploite l'hallucination de l'IA en enregistrant des noms entièrement fabriqués qu'un modèle invente, qui ne sont les fautes d'orthographe d'aucun vrai paquet et échappent donc à la détection de sosies. En bref, le typosquatting parie sur le glissement de vos doigts ; le slopsquatting parie sur votre assistant IA qui invente une dépendance et l'installe pour vous.

Qu'est-ce que l'attaque HalluSquatting ?

Le HalluSquatting est une escalade du slopsquatting apparue en 2026, décrite dans l'article « Beware of Agentic Botnets » (arXiv, 8 juillet 2026). Au lieu d'attendre qu'un modèle tombe sur un nom que l'attaquant possède déjà, elle utilise un déclencheur adverse universel et transférable pour forcer les agents IA à halluciner une ressource précise, choisie par l'attaquant, à la demande, puis la chaîne avec une injection de prompt indirecte pour obtenir une exécution de code à distance et propager un logiciel malveillant de botnet. Les chercheurs ont rapporté des taux de ressources hallucinées allant jusqu'à 85 % pour le clonage de dépôt et 100 % pour l'installation de compétences, sur neuf assistants dont Cursor, Windsurf, Copilot, Cline et Gemini CLI.

À quel point les hallucinations de paquets par l'IA sont-elles fréquentes ?

Très fréquentes. Une étude USENIX Security 2025 portant sur 2,23 millions d'échantillons de code générés par IA a constaté que 19,7 % référençaient au moins un paquet halluciné, a catalogué 205 474 noms fabriqués uniques, et a montré que les hallucinations sont reproductibles : 43 % d'entre elles revenaient dans les dix relances du même prompt. Les modèles open source étaient pires (21,7 %) que les commerciaux (5,2 %). C'est la reproductibilité qui rend le problème exploitable, car les attaquants peuvent prédire et préenregistrer les noms qu'un modèle privilégie.

Un scanner SCA ou la détection de typosquatting peuvent-ils attraper le slopsquatting ?

Pas de manière fiable, et pour deux raisons distinctes. La détection de typosquatting cherche des noms à faible distance d'édition de vrais paquets, mais un nom halluciné est fabriqué plutôt qu'une quasi-erreur, il n'est donc proche de rien que le filtre surveille. L'analyse de composition logicielle (SCA) s'exécute après qu'un paquet est installé et cherche des versions vulnérables connues, mais un paquet malveillant fraîchement enregistré n'a pas encore de CVE, et son script d'installation a déjà tourné au moment où la SCA regarde. Les deux valent la peine d'être lancés comme filets de sécurité ; aucun n'arrête l'installation elle-même.

Comment empêcher mon agent de code IA d'installer des paquets hallucinés ?

Ne laissez pas les agents installer des dépendances sans surveillance, vérifiez que tout nouveau paquet existe réellement et a un vrai historique avant de l'ajouter, restreignez les installations à un registre privé ou à une liste blanche, et commitez des lockfiles avec des empreintes d'intégrité pour que les nouvelles dépendances soient visibles et relisables. Parce que ces vérifications n'aident que si quelque chose les impose avant que la commande d'installation ne s'exécute, la correction durable est l'application des règles au moment de l'agent : un contrôle comme VibeDefend qui intercepte l'installation d'un paquet non vérifié ou inexistant à l'intérieur de la boucle de l'agent, plutôt qu'un scanner qui lit les dégâts après coup.