Le typosquatting, qui consiste à enregistrer une version mal orthographiée d'un paquet populaire et à attendre qu'un développeur tape accidentellement et installe le mauvais paquet, existe depuis une dizaine d'années dans npm. Ce n'est pas nouveau, le registre dispose de protections contre cela.
Puis l'IA est arrivée et a tout changé à nouveau. Le slopsquatting est la nouvelle version de l'AI du typosquatting. Au lieu de miser sur les fautes de frappe humaines, les attaquants misent sur les hallucinations de l'IA, les noms de paquets 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 aujourd'hui. 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 faire concrètement pour y remédier.
Qu'est-ce que le slopsquatting ?
Le slopsquatting, également appelé hallucination squatting, consiste pour un pirate à enregistrer un nom de paquet que les modèles d'IA ont tendance à halluciner, puis à attendre que les développeurs l'installent sur recommandation de l'IA. Les pirates qui recourent au squatting misent sur le fait que les assistants IA suggèrent en toute confiance des noms de paquets qui n'existent pas, et que les développeurs leur font confiance en pensant qu'il s'agit d'un paquet réel qu'ils ont demandé.
Lorsqu'un développeur exécute l'installation de ce nom de paquet, il obtient le paquet de l'attaquant. Le paquet exécute généralement un script post-installation qui vole toutes les informations d'identification présentes dans l'environnement (clés API, cloud , jetons d'authentification npm) et les transmet à l'attaquant.
Alors que certains paquets incluent simplement l'attaque dans un script post-installation, les paquets plus sophistiqués évitent complètement d'intégrer du code malveillant dans le paquet, utilisant plutôt la prise en charge par npm des dépendances basées sur des URL pour récupérer une charge utile à partir d'un serveur externe au moment de l'installation. Le paquet semble sain à tout scanner statique naïf, car il ne contient aucun code manifestement malveillant.
Imaginons que vous demandiez à votre IA d'installer un package JavaScript linter. Elle vous propose importations inutilisées et vous demande si vous souhaitez l'installer (si ce n'est pas le cas, il ne vous le demande tout simplement pas). Cela ressemble au paquet que vous avez déjà utilisé, vous l'installez donc.
Claude veut exécuter : npm install unused-imports
[y] Accepter [n] Refuser [e] Modifier [Esc] AnnulerCependant, le véritable paquet est eslint-plugin-importations-inutiliséesIl s'avère que importations inutilisées est un paquet malveillant, et surprise ! Vous venez d'installer un logiciel malveillant ! (Il s'agit en fait d'un réel paquet malveillant, soit dit en passant, et potentiellement une attaque intentionnelle de slopsquatting. Vous pouvez le consulter sur Aikido .. npm l'a actuellement placé sous contrôle de sécurité).
Les LLM ont tendance à inventer des noms de paquets. Mackenzie Jackson, développeur chez Aikido , a décrit une hallucination qu'il a rencontrée dans 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 faisable mais peu courante, pour laquelle il n'existe pas de solution de paquet évidente. Au lieu d'admettre qu'il était perplexe, le modèle a inventé des noms de paquets. Mackenzie commente ainsi le processus de réflexion de l'IA : « Je n'ai rien à vous proposer, mais je dois vous proposer quelque chose, alors voici comment je pense que ces paquets pourraient s'appeler. »
En quoi le slopsquatting diffère-t-il du typosquatting ?
Le typosquatting consiste pour un pirate à enregistrer un paquet malveillant dont le nom est suffisamment proche d'un paquet populaire pour qu'un utilisateur se connecte par erreur en tapant une faute de frappe. Les pirates recherchent un paquet très téléchargé dont le nom est facile à mal orthographier, suppriment un trait d'union, intervertissent deux lettres, ajoutent un caractère supplémentaire et « squattent » le paquet mal orthographié avant que quelqu'un d'autre ne le fasse. Le typosquatting est une pratique courante sur npm depuis au moins 2017, date à laquelle un pirate a publié crossenv, un squat du populaire cross-env package. npm dispose désormais de protections contre ce problème, en empêchant l'enregistrement de noms de paquets trop similaires à ceux qui existent déjà.
Le slopsquatting est une forme de typosquatting, mais au lieu de miser sur les doigts maladroits des utilisateurs, les pirates misent sur les erreurs d'une IA considérée comme fiable (oui, c'est ainsi que l'IA est perçue actuellement). La principale différence entre le slopsquatting et le typosquatting tel que nous le connaissions auparavant réside dans le fait que les variantes sont totalement différentes et que, dans le premier cas, les pirates ont un plus grand choix de noms.
Par exemple, 8,7 % des noms de paquets Python générés par l'IA se sont avérés être des paquets JavaScript valides. Dans ce cas, le modèle établit le bon lien avec un élément réel, mais dans le mauvais écosystème. Un terrain fertile pour les pirates qui souhaitent enregistrer des noms de paquets provenant d'autres écosystèmes.
Les chercheurs de l'USENIX Security 2025 ont testé 16 modèles sur 576 000 échantillons de code et ont découvert que les hallucinations suivent des schémas prévisibles : 38 % sont des amalgames tels que mongoose express, où le modèle mélange deux éléments réels, 13 % sont des variantes orthographiques et 51 % sont des inventions pures et simples. Cela représente un réservoir de noms squattables bien plus important que celui offert par le typosquatting, et contrairement au typosquatting, aucun de ces nouveaux noms n'a de « similitude » dans le système de protection de npm.
Le squattage des toilettes est-il d'actualité ?
Nous pensons que oui. Nous observons des paquets de logiciels malveillants dont les noms correspondent au modèle du slopsquatting, mais nous ne pouvons pas prouver ce que les pirates ont l'intention de faire avec ces noms. Prenez importations inutilisées, le paquet malveillant confirmé dont nous avons parlé précédemment. Début février, il enregistrait encore 233 téléchargements par semaine. Ces développeurs suivent soit les recommandations de l'IA qui pointent toujours vers ce nom, soit ils l'ont quelque part dans leur arborescence de dépendances et le réinstallent, soit ils l'ont trouvé dans la documentation ou sur Stack Overflow qui n'ont pas été mis à jour.
Cependant, les chercheurs sont en train de découvrir et de prouver les premiers précurseurs du slopsquatting dans la vie réelle. Au début de l'année 2024, Bar Lanyado, de Lasso Security, a remarqué que les modèles d'IA hallucinaient de manière répétée un paquet Python. appelé huggingface-cli. Le véritable outil s'installe différemment, car pip install -U "huggingface_hub[cli]", mais les modèles continuaient à suggérer la version plus courte, inexistante. Lanyado a téléchargé un paquet vide sous ce nom sur PyPI pour voir ce qui se passerait.
huggingface-cli a été téléchargé plus de 30 000 fois en trois mois. Alibaba avait copié-collé la commande d'installation hallucinée dans le fichier README de l'un de ses référentiels publics. Le paquet était inoffensif, mais Lanyado a prouvé que cette stratégie fonctionnait. Alibaba a simplement eu la chance que Lanyado s'en soit aperçu avant un pirate informatique.
Une hallucination générée par un logiciel d'IA qui s'est propagée d'elle-même
Charlie Eriksen, chercheur en sécurité chez Aikido trouvé quelque chose d'encore plus fou– un nom de paquet halluciné se propageant à travers une infrastructure IA réelle, avec de véritables agents essayant de l'exécuter, que personne n'avait délibérément implanté. En janvier 2026, Charlie a affirmé que ce paquet npm appelé react-codeshift. Le paquet n'était pas réel, n'avait pas d'auteur et n'avait certainement pas été enregistré auparavant. Le nom est un classique hallucination par confusion. Il existe deux paquets réels portant des noms similaires, jscodeshift et react-codemod, que LLM a mélangé pour inventer le nom react-codeshift.
Le paquet avait fait sa première apparition dans un seul commit de 47 compétences d'agent générées par LLM. On peut supposer qu'une IA a été chargée de générer un ensemble d'instructions pour l'agent de codage et qu'elle a, ce faisant, imaginé des noms de paquets dont elle aurait besoin pour accomplir ces tâches. Aucun humain n'a vérifié le résultat (ou du moins ne l'a pas testé), de sorte que cette hallucination de l'IA a été immortalisée via GitHub.
Au moment où Charlie l'avait trouvé dans le cadre de ses recherches sur les colis non réclamés, le nom de ce paquet inexistant s'était propagé à 237 référentiels via des fourches et avait été traduit en japonais. Après que Charlie l'ait revendiqué, react-codeshift continuaie à enregistrer quelques téléchargements quotidiens. Il s'agit d'agents IA qui suivent des instructions de compétences et déclenchent des installations npx dans des environnements réels. Si un pirate 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 par slopsquatting
Vérifiez l'éditeur, pas seulement le nom
La réponse évidente est de vérifier les noms des paquets avant de les installer, mais ce n'est pas si simple. Le nombre de téléchargements n'est pas un indicateur fiable (nous avons constaté que des paquets malveillants sont régulièrement téléchargés chaque jour). Ce qui importe réellement, c'est l'éditeur : qui a enregistré ce paquet, quand, et cela correspond-il à ce que vous attendez d'un gestionnaire légitime ? Un paquet prétendant être un eslint Un plugin sans informations sur son développeur et dont la date d'enregistrement remonte à mardi dernier est un signal d'alarme, quel que soit son nombre de téléchargements.
Considérer l'installation autonome de paquets comme une opération privilégiée
Si vous utilisez des agents IA capables d'installer des paquets sans confirmation, Claude Code en mode bypass, une configuration de codage agentique ou des pipelines CI avec des autorisations npm étendues, l'étape de vérification que vous effectuez normalement en tant qu'humain n'existe plus. L'agent continuera simplement s'il dispose des autorisations nécessaires. C'est le modèle de menace sur lequel repose le slopsquatting, donc définissez ces autorisations en conséquence.
Analysez l'intégralité de votre arborescence de dépendances
Certains noms de paquets 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 scannerSCA analyse de la composition logicielle ) examine l'intégralité de votre arborescence de dépendances afin de détecter les paquets malveillants cachés et enfouis.
Utilisez SafeChain pour une protection au niveau npm
Aikido est un wrapper open source pour npm, npx, fil, 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 en toute confiance de faux noms de paquets à installer et d'agents IA qui diffusent ces noms dans les référentiels.
Alors que le codage par ambiance devient la norme et que de plus en plus d'agents IA sur le thème du homard commencent à coder sans intervention humaine (lire notre article « Pourquoi essayer de sécuriser OpenClaw est ridicule »), la marge de manœuvre dont dispose un humain pour détecter un nom de paquet malveillant avant son exécution ne cesse de se réduire. Nous avons constaté que les noms hallucinés par les LLM sont cohérents et répétables, et les attaquants s'en rendent compte.
Vérifiez vos arborescences de dépendances. Vérifiez les éditeurs. Et utilisez un outil qui se situe entre votre gestionnaire de paquets et le registre et qui effectue les vérifications à votre place.
