En janvier 2026, le chercheur en sécurité Charlie Eriksen, d’Aikido Security, a enregistré sur npm le paquet react-codeshift, un nom qu’il n’avait pas créé et qui n’avait jamais été publié auparavant. Ce paquet était une hallucination issue de la fusion de deux bibliothèques réelles, jscodeshift et react-codemod, puis s’était propagé dans 237 dépôts GitHub au moyen de fichiers d’instructions (Agent Skills) générés par des modèles de langage. Après son enregistrement, des agents automatisés ont commencé à tenter de l’installer régulièrement, démontrant qu’un nom de paquet inventé par une IA pouvait rapidement atteindre des environnements réels.
Cet épisode illustre le slopsquatting, une attaque de chaîne d’approvisionnement dans laquelle un acteur malveillant enregistre des paquets inexistants mais fréquemment suggérés par des outils d’IA afin d’inciter des développeurs ou des agents de programmation à les installer.
Mécanisme de l’attaque : un risque de cybersécurité exploitant la prévisibilité des LLM
Un modèle de langage ne vérifie pas systématiquement l’existence d’une dépendance dans un registre comme npm ou PyPI avant de la recommander : il génère une réponse probabiliste et peut ainsi produire un nom de paquet plausible mais inexistant. Cette erreur devient particulièrement exploitable lorsqu’elle se répète. Dans leur étude, Joseph Spracklen et ses coauteurs ont relancé dix fois 500 prompts ayant déjà conduit à des hallucinations de paquets : 43% des noms inventés réapparaissaient à chaque exécution et 58% apparaissaient au moins deux fois.
Cette persistance signifie qu’un attaquant n’a pas besoin de deviner un nom au hasard : il peut sonder un modèle, repérer les dépendances fictives qui reviennent régulièrement, puis les enregistrer sur un registre public avant qu’un développeur ou un agent de programmation ne tente de les installer.
Ampleur du problème et taux d’hallucinations selon les modèles LLM (Claude, GPT, Gemini, DeepSeek)
L’étude de référence de Spracklen et al., présentée à USENIX Security 2025, apporte des chiffres particulièrement marquants. En analysant 576 000 échantillons de code générés par 16 modèles, les chercheurs ont constaté que près de 20 % des dépendances recommandées n’existaient pas, soit plus de 440 000 noms sur 2,23 millions.
Le phénomène est encore plus prononcé côté open source, avec un taux moyen de 21,7 %, contre 5,2 % pour les modèles commerciaux.
Une réplication publiée en 2026 par Aleksandr Churilov, portant sur plusieurs modèles récents (Claude, GPT, Gemini, DeepSeek), montre une amélioration relative : les taux observés se situent entre 4,62 % et 6,10 %. L’écart entre modèles s’est donc réduit, mais le problème reste significatif. À grande échelle, même quelques pourcents représentent un volume important de dépendances fictives.
L’étude initiale met également en évidence un autre risque : la confusion entre écosystèmes. Environ 8,7 % des paquets Python halluciné correspondent en réalité à des paquets existants sur npm. Concrètement, un développeur peut être redirigé vers une dépendance d’un autre langage ou pire, vers un paquet malveillant enregistré par un attaquant sous le même nom.
Cas réels et vulnérabilités documentées : du package npm/PyPI malveillant à l’HalluSquatting
Un cas emblématique, documenté par Bar Lanyado (Lasso Security), illustre bien le problème : plusieurs modèles de langage recommandaient d’installer un paquet Python nommé huggingface-cli. Problème : ce paquet n’existait pas. La méthode officielle reposait en réalité sur huggingface_hub, qui fournit la CLI (aujourd’hui accessible via la commande hf).
Pour mesurer l’impact réel de cette erreur, le chercheur a publié un paquet vide nommé huggingface-cli sur PyPI. Résultat : plus de 30 000 téléchargements en trois mois, sans aucun contenu malveillant. Son analyse a ensuite montré que cette mauvaise recommandation avait été copiée dans la documentation d’un projet de recherche public lié à Alibaba (GraphTranslator). Autrement dit, une hallucination d’IA peut se retrouver dans du code rée et être exécutée par des développeurs.
Un cas plus récent montre une escalade préoccupante. Un paquet npm malveillant nommé unused-imports suggéré par des modèles à la place du paquet légitime eslint-plugin-unused-imports continuait d’être téléchargé malgré un blocage de sécurité, avec environ 233 installations hebdomadaires début 2026 (Cloud Security Alliance).
Ce type d’attaque s’inscrit dans une technique appelée HalluSquatting. Le principe : exploiter les hallucinations prévisibles des IA pour créer des paquets ou ressources piégées. Dans des environnements agentiques, le risque est encore plus élevé : un agent peut récupérer ces ressources et exécuter des instructions malveillantes, ouvrant la voie à des compromissions voire à de l’exécution de code à distance.
Mitigation du Slopsquatting : une chaîne de confiance rigoureuse, pas une automatisation aveugle
- Vérifier systématiquement les paquets avant installation : ne jamais exécuter une commande d’installation suggérée par une IA sans confirmer que le paquet existe bien sur le registre visé (PyPI, npm, crates.io, etc.). Il convient notamment de vérifier son mainteneur, sa date de publication, son historique et, lorsque c’est pertinent, ses statistiques de téléchargement. Cette vérification peut être automatisée dans les pipelines CI/CD afin de bloquer les builds lorsqu’une dépendance est inconnue, nouvellement publiée ou ne respecte pas les politiques de sécurité.
- Imposer une validation humaine pour les nouvelles dépendances : lorsqu’un agent de code autonome propose ou ajoute une bibliothèque, son installation ne devrait pas être exécutée automatiquement. Une approbation humaine doit permettre de vérifier que la dépendance correspond bien au besoin et qu’il s’agit du bon paquet. Une étape explicite de revue des dépendances dans les pull requests peut notamment permettre d’identifier les noms de paquets plausibles mais inexistants ou suspects.
- Surveiller les paquets récemment publiés : une dépendance inconnue de l’organisation et récemment enregistrée mérite une attention particulière avant son intégration en production. Des contrôles peuvent signaler les paquets très récents, disposant de peu de téléchargements ou associés à des mainteneurs sans historique établi. Leur propriétaire, leur historique de versions, leur documentation et leur dépôt source doivent alors être vérifiés avant autorisation.
- Privilégier une liste blanche pour les projets critiques : plutôt que d’autoriser par défaut toute dépendance proposée par un assistant de code, les organisations peuvent maintenir un catalogue interne de paquets et de versions approuvés. Pour les environnements sensibles, l’accès direct aux registres publics peut être restreint au profit d’un dépôt interne servant de point de contrôle. Toute nouvelle dépendance doit alors être validée avant de pouvoir être utilisée par un développeur ou un agent IA.
Pour aller plus loin, consultez notre guide des architectures et vecteurs de risques IA afin de resituer ce vecteur parmi les risques de chaîne d’approvisionnement propres à l’IA.
FAQ : Sécurité IA et agents de développement
Un modèle plus récent élimine-t-il le risque de slopsquatting ?
Ce risque concerne-t-il uniquement les développeurs individuels ?
Comment un attaquant sait-il quels noms hallucinés cibler ?
Audit et pentest IA : sécuriser votre chaîne d’approvisionnement logicielle DevSecOps
Nos experts évaluent l’exposition de vos pipelines de développement aux dépendances hallucinées et testent la résistance de vos agents de code dans le cadre de notre offre de pentest IA. Vous souhaitez échanger sur votre projet ou évaluer vos besoins ? Contactez nos experts.