Le typosquatting, qui consiste à enregistrer une version mal orthographiée d'un package populaire et à attendre qu'un développeur tape et installe accidentellement le mauvais package, existe depuis une décennie dans npm. Ce n'est pas nouveau — le registre dispose de protections pour cela.
Puis l'IA est arrivée et a tout changé à nouveau. Le slopsquatting est la nouvelle forme de typosquatting, alimentée par l'IA. Au lieu de miser sur les fautes de frappe humaines, les attaquants misent sur les hallucinations de l'IA, c'est-à-dire les noms de packages que les LLM recommandent avec confiance mais qui n'existent pas réellement. Pendant un certain temps, cela a été considéré comme un risque théorique, mais ce n'est plus le cas. Les hallucinations de l'IA sont parmi nous, tout comme les slopsquatters.
Dans cet article, nous examinerons comment fonctionne le slopsquatting, ce que les chercheurs découvrent actuellement sur le terrain et ce que vous pouvez réellement faire à ce sujet.
Qu'est-ce que le slopsquatting ?
Le slopsquatting, également appelé hallucination squatting, se produit lorsqu'un attaquant enregistre un nom de package que les modèles d'IA ont tendance à halluciner, puis attend que les développeurs l'installent sur recommandation d'une IA. Les attaquants pratiquant le squatting s'appuient sur des assistants IA qui suggèrent avec confiance des noms de packages inexistants, et sur des développeurs qui leur font confiance en pensant qu'il s'agit d'un vrai package qu'ils ont demandé.
Lorsqu'un développeur exécute l'installation de ce nom de package, il obtient le package de l'attaquant. Le package exécutera généralement un script post-installation qui dérobera toutes les informations d'identification présentes dans l'environnement (clés API, jetons cloud, jetons d'authentification npm) et les transmettra à l'attaquant.
Alors que certains packages incluent simplement l'attaque dans un script post-installation, des packages plus sophistiqués évitent de placer du code malveillant dans le package, utilisant plutôt le support de npm pour les dépendances basées sur des URL afin de récupérer une charge utile depuis un serveur externe au moment de l'installation. Le package semble propre à tout scanner statique naïf car il n'y a pas de code manifestement malveillant.
Supposons que vous demandiez à votre IA d'installer un package de linter JavaScript. Elle propose unused-imports et vous demande si vous voulez l'installer (si elle ne contourne pas complètement la question). Cela ressemble au package que vous avez déjà utilisé, alors vous l'installez.
Claude souhaite exécuter : npm install unused-imports
[y] Accepter [n] Refuser [e] Modifier [Esc] AnnulerCependant, le vrai package est eslint-plugin-unused-imports. Il s'avère que, unused-imports est un package malveillant, et surprise ! Vous venez d'installer un malware ! (Il s'agit en fait d'un vrai package malveillant, d'ailleurs, et potentiellement une attaque de slopsquatting intentionnelle. Vous pouvez le consulter sur Aikido Intel. npm l'a maintenant mis en attente de sécurité).
Les LLM hallucinent en fait pas mal de noms de packages. Mackenzie Jackson, Developer Advocate chez Aikido Security, a décrit une hallucination qu'il a rencontrée lors d'un épisode du podcast Secure Disclosure. Il a demandé à une IA de l'aider à connecter son projet Node.js à une base de données OrientDB, une combinaison techniquement réalisable mais peu courante, sans solution de package évidente. Au lieu d'admettre qu'il était bloqué, le modèle a inventé des noms de packages. Mackenzie dit à propos du processus de pensée de l'IA : « Je n'ai rien pour vous, mais je dois avoir quelque chose pour vous, alors voici comment je pense que les packages pour cela s'appelleraient. »
En quoi le slopsquatting est-il différent du typosquatting ?
Le typosquatting se produit lorsqu'un attaquant enregistre un paquet malveillant dont le nom est suffisamment proche d'un paquet populaire pour qu'un utilisateur le saisisse par erreur. Les attaquants identifient un paquet très téléchargé dont le nom est facile à mal orthographier, suppriment un trait d'union, échangent deux lettres, ajoutent un caractère supplémentaire et « squattent » le paquet mal orthographié avant quiconque. Le typosquatting est une constante de npm depuis au moins 2017, lorsqu'un attaquant a publié crossenv, un squat du populaire cross-env paquet. npm dispose désormais de protections contre cela, en empêchant l'enregistrement de noms de paquets trop similaires à ceux existants.
Le slopsquatting est du typosquatting, mais au lieu de miser sur les erreurs de saisie humaines, les attaquants misent sur une IA qui se trompe avec assurance. (Oui, c'est le niveau de fiabilité de l'IA actuellement). La principale différence entre le slopsquatting et le typosquatting que nous avons connu par le passé est que les variantes sont totalement différentes, et avec le premier, les attaquants disposent d'un volume de noms plus élevé parmi lesquels choisir.
Par exemple, 8,7 % des noms de paquets Python « hallucinés » par l'IA se sont avérés être des paquets JavaScript valides. Dans ce cas, le modèle établit la bonne connexion avec une entité réelle, mais dans le mauvais écosystème. Un terrain fertile pour les attaquants qui souhaitent enregistrer des noms de paquets provenant d'autres écosystèmes.
Des chercheurs de l'USENIX Security 2025 ont testé 16 modèles sur 576 000 échantillons de code et ont constaté que les hallucinations suivent des schémas prévisibles : 38 % sont des confusions comme express-mongoose, où le modèle mélange deux éléments réels, 13 % sont des variantes de fautes de frappe et 51 % sont de pures fabrications. C'est un bassin de noms « squattables » bien plus vaste que ce que le typosquatting n'a jamais offert, et contrairement au typosquatting, aucun de ces nouveaux noms n'a de « similarité » à laquelle se référer dans le système de protection de npm.
Le slopsquatting est-il déjà une réalité ?
Nous le pensons. Nous observons des paquets malveillants dont les noms sont cohérents avec le schéma du slopsquatting, mais nous ne pouvons pas prouver l'intention des attaquants derrière ces noms. Prenons unused-imports, le paquet malveillant confirmé dont nous avons parlé plus tôt. Début février, il enregistrait encore 233 téléchargements par semaine. Ces développeurs suivent soit des recommandations d'IA qui pointent toujours vers ce nom, l'ont quelque part dans leur arbre de dépendances et le réinstallent, ou l'ont trouvé dans la documentation ou sur Stack Overflow qui n'ont pas été mis à jour.
Cependant, des chercheurs trouvent et prouvent bel et bien les premiers précurseurs du slopsquatting dans la vie réelle. Début 2024, Bar Lanyado de Lasso Security a remarqué que les modèles d'IA « hallucinaient » à plusieurs reprises un paquet Python appelé huggingface-cli. L'outil réel s'installe différemment, comme pip install -U "huggingface_hub[cli]", mais les modèles continuaient de suggérer la version plus courte et inexistante. Lanyado a téléchargé un paquet vide sous ce nom sur PyPI pour voir ce qui se passerait.
huggingface-cli a enregistré plus de 30 000 téléchargements authentiques en trois mois. Alibaba avait copié-collé la commande d'installation « hallucinée » dans le README de l'un de ses dépôts publics. Le paquet était inoffensif, mais Lanyado a prouvé que cette stratégie fonctionne. Alibaba a juste eu de la chance que Lanyado l'ait découvert avant un attaquant.
Une hallucination de paquet d'IA qui s'est propagée d'elle-même
Charlie Eriksen, Chercheur en sécurité chez Aikido découvert quelque chose d'encore plus inattendu– un nom de package halluciné se propageant à travers une infrastructure d'IA réelle, avec de véritables agents tentant de l'exécuter, que personne n'avait délibérément implanté. En janvier 2026, Charlie a revendiqué ce package npm nommé react-codeshift. Le package n'était pas réel, n'avait pas d'auteur et n'avait certainement jamais été enregistré auparavant. Le nom est une classique hallucination par amalgame. Deux packages réels avec des noms similaires existent, jscodeshift et react-codemod, qu'un LLM a fusionné pour inventer le nom react-codeshift.
Le package avait fait sa première apparition dans un seul commit de 47 compétences d'agent générées par LLM. Nous pouvons supposer qu'une IA a été invitée à générer un ensemble d'instructions pour agents de codage et, ce faisant, a halluciné des noms de packages dont elle aurait besoin pour effectuer ces tâches. Aucun humain n'a examiné la sortie (ou du moins ne l'a pas testée), de sorte que cette hallucination d'IA a été immortalisée via GitHub.
Au moment où Charlie l'avait découvert dans le cadre de ses recherches sur les packages non revendiqués, le nom de ce package non-existant s'était propagé à 237 dépôts via des forks et avait été traduit en japonais. Après que Charlie l'ait revendiqué, react-codeshift continuait de recevoir quelques téléchargements quotidiens. Il s'agit d'agents IA suivant des instructions de compétences et déclenchant des installations npx dans des environnements réels. Si un attaquant l'avait enregistré en premier, il aurait pu y avoir une attaque de slopsquatting plus importante qui se serait propagée de manière organique
Comment se protéger contre les attaques de slopsquatting
Vérifiez l'éditeur, pas seulement le nom
La réponse évidente est de vérifier les noms de packages avant l'installation, mais ce n'est vraiment pas si simple. Le nombre de téléchargements n'est pas un indicateur fiable (nous avons vu que les packages malveillants continuent d'avoir des téléchargements quotidiens réguliers). Ce qui compte vraiment, c'est l'éditeur : qui a enregistré ce package, quand, et cela correspond-il à ce que vous attendez d'un mainteneur légitime ? Un package se présentant comme un eslint plugin sans information de mainteneur et une date d'enregistrement de mardi dernier est un signal d'alarme, indépendamment de son nombre de téléchargements.
Traitez l'installation autonome de packages comme une opération privilégiée
Si vous exécutez des agents IA capables d'installer des packages sans confirmation, Claude Code en mode contournement, une configuration de codage agentique, ou des pipelines CI avec des permissions npm étendues, l'étape de vérification que vous feriez normalement en tant qu'humain disparaît. L'agent procédera simplement s'il en a l'autorité. C'est le modèle de menace sur lequel le slopsquatting est construit, alors définissez ces permissions en conséquence.
Scannez votre arbre de dépendances complet
Certains noms de packages hallucinés se retrouvent comme dépendances imbriquées plutôt que comme installations directes, ce qui signifie qu'ils n'apparaîtront pas dans votre package.json. Un scanner d'analyse de la composition logicielle (SCA) examine votre arbre de dépendances complet pour détecter les packages malveillants cachés et enfouis.
Utilisez SafeChain pour une protection au niveau npm
Aikido SafeChain est un wrapper open source pour npm, npx, yarn, et pnpm qui intercepte les commandes d'installation de paquets et les vérifie par rapport à Aikido Intel avant que quoi que ce soit n'atteigne votre machine.
Conclusion
Les noms de paquets non revendiqués ont toujours pu être revendiqués, mais nous disposons désormais d'IA qui nous fournissent avec assurance de faux noms de paquets à installer et d'agents IA qui diffusent ces noms dans les dépôts.
Alors que le « vibe coding » devient la norme et que de plus en plus d'agents IA sur le thème du homard commencent à coder sans intervention humaine (lisez notre article sur « Pourquoi tenter de sécuriser OpenClaw est ridicule »), la fenêtre de temps pour qu'un humain détecte un nom de paquet malveillant avant son exécution ne cesse de se réduire. Nous avons constaté que les noms que les LLM hallucinent sont cohérents et reproductibles, et les attaquants en tirent parti.
Vérifiez vos arbres de dépendances. Vérifiez les éditeurs. Et utilisez un outil qui s'intercale entre votre gestionnaire de paquets et le registre, et effectue les vérifications pour vous.
