Slopsquatting : quand votre assistant IA installe un paquet qui n’existe pas

Demandez de l’aide à un assistant de code et il vous proposera souvent une bibliothèque en plus du code. La plupart du temps, la bibliothèque existe. Parfois non : le modèle produit un nom qui sonne juste, qui respecte les conventions de nommage de l’écosystème, et qui n’existe tout simplement pas sur npm ou PyPI. Si vous lancez la commande d’installation sans regarder, deux choses peuvent arriver. Soit l’installation échoue, ce qui est agaçant mais sans danger. Soit quelqu’un a déjà publié un paquet sous ce nom exact, et vous venez d’exécuter son code.

Qu’est-ce que le slopsquatting ?

Le slopsquatting désigne ce second cas : enregistrer les noms de paquets que les modèles d’IA ont tendance à inventer, puis attendre que des gens les installent. Le terme est généralement attribué à Seth Larson, security developer-in-residence de la Python Software Foundation, et il fait écho au typosquatting, où des attaquants enregistrent des variantes mal orthographiées de paquets populaires. La différence tient à qui commet l’erreur. Avec le typosquatting, c’est une personne qui fait une faute de frappe. Avec le slopsquatting, c’est un modèle qui suggère avec assurance le mauvais nom, et une personne qui lui fait confiance.

Le risque n’a rien de théorique. Lors d’une expérience largement médiatisée, un chercheur a remarqué que les modèles recommandaient sans cesse un paquet nommé huggingface-cli, alors que ce n’est pas ainsi que s’installe le véritable outil de Hugging Face. Il a publié un paquet vide sous ce nom pour voir ce qui se passerait, et il a été téléchargé des dizaines de milliers de fois. Le paquet était inoffensif. Un paquet malveillant ne l’aurait pas été.

À quelle fréquence les modèles inventent des paquets

L’étude la plus complète à ce jour est « We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs », présentée à USENIX Security 2025. Les auteurs ont généré 576 000 échantillons de code en Python et en JavaScript avec 16 modèles populaires et vérifié chaque paquet auquel le code faisait référence. Ils ont constaté que la part moyenne de paquets hallucinés était d’au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source, et ils ont recensé 205 474 noms de paquets uniques qui n’existaient pas.

Deux détails de l’article comptent davantage que les chiffres principaux. D’abord, les noms inventés sont souvent reproductibles : quand les auteurs ont relancé dix fois des prompts ayant produit une hallucination, 43 % de ces noms sont revenus à chaque fois. Des noms prévisibles, c’est exactement ce dont un attaquant a besoin. Ensuite, la plupart ne sont pas des variantes orthographiques proches de paquets réels, si bien qu’une détection de fautes de frappe ne les repérera pas. Seuls 13 % environ se trouvaient à un ou deux caractères d’un nom existant.

Les modèles se sont améliorés depuis ces expériences, et les assistants qui interrogent le registre avant de suggérer un paquet rendent le problème plus rare. Plus rare ne veut pas dire disparu, surtout pour des tâches de niche pour lesquelles le modèle a vu peu d’exemples réels.

Pourquoi l’attaque est facile à mener

Publier sur npm ou PyPI est gratuit et prend quelques minutes. Un attaquant n’a rien à compromettre ; il lui suffit de deviner les noms que produisent les modèles et de les enregistrer le premier. Les scripts d’installation font le reste : npm exécute par défaut les scripts preinstall et postinstall, et un paquet Python peut exécuter du code lors de son build ou de son import. Une seule installation sur le portable d’un développeur ou sur un runner de CI peut exposer des clés SSH, des identifiants cloud et des jetons présents dans les variables d’environnement.

Les agents aggravent le problème. Quand un assistant peut lancer lui-même npm install ou pip install, il se peut qu’aucun humain ne regarde jamais le nom du paquet.

Vérifier un paquet en une minute

Avant d’ajouter une dépendance que vous n’avez pas choisie vous-même, consultez le registre :

# npm: does it exist, who publishes it, when was it first released?$ npm view some-package name version time.created repository.url # PyPI: same questions, from the JSON API$ curl -s https://pypi.org/pypi/some-package/json | jq '.info | {name, version, home_page, project_urls}'

Posez-vous ensuite quelques questions rapides :

• Existe-t-il seulement ? Une erreur 404 signifie que le nom a été inventé. Ne le créez pas, et n’installez pas une alternative « assez proche » sans la vérifier elle aussi.
• Est-il tout récent ? Un paquet publié pour la première fois ces dernières semaines, avec une seule version et aucun historique, mérite un second examen, surtout si son nom correspond à ce que votre assistant a suggéré.
• Renvoie-t-il à un vrai projet ? Un dépôt lié avec des commits, des issues et d’autres utilisateurs est bon signe. Un dépôt vide ou absent ne l’est pas.
• Est-ce le paquet que la documentation vous dit d’installer ? La documentation de l’outil lui-même est la meilleure source pour le nom correct. huggingface-cli comparé à la commande d’installation documentée en est un bon exemple.

Les bonnes habitudes

• Utilisez des lockfiles et installez à partir d’eux en CI (npm ci, pip install -r avec versions et hachages épinglés), pour qu’aucun nouveau nom ne puisse se glisser pendant un build.
• Relisez les changements de dépendances dans les pull requests avec autant de soin que les changements de code. Un diff qui ajoute trois paquets mérite trois vérifications.
• Demandez à votre assistant de donner le lien vers la page du paquet sur le registre ou vers sa documentation officielle quand il suggère quelque chose de nouveau. C’est un moyen peu coûteux de débusquer un nom inventé.
• Si votre agent peut lancer des installations de lui-même, donnez-lui une liste d’autorisation ou exigez une confirmation pour toute nouvelle dépendance.
• Envisagez de désactiver par défaut les scripts d’installation (npm config set ignore-scripts true) et de ne les activer que pour les paquets qui en ont besoin. Cela casse certains paquets : testez d’abord.

Automatiser la partie fastidieuse

Les vérifications manuelles fonctionnent pour un paquet. Elles ne passent pas à l’échelle d’un dépôt comptant des centaines de dépendances, ni des imports enfouis dans du code qu’un assistant a généré la semaine dernière. C’est un travail tout trouvé pour l’outillage.

La suite « risques du code IA » de vetkit recherche les dépendances et les imports de vos manifestes sur des registres publics comme npm et PyPI. Elle signale les noms qui n’existent pas, les versions qui n’ont jamais été publiées et les paquets publiés pour la première fois au cours des 30 derniers jours. Seuls les noms et versions des paquets sont envoyés aux registres, jamais votre code source, et les paquets issus de registres privés ou de vos propres workspaces ne sont pas recherchés. Le serveur MCP de vetkit expose aussi une vérification de paquets, pour qu’un assistant puisse valider un nom avant d’installer quoi que ce soit.

Quel que soit l’outil, le principe reste le même : un nom de paquet venu d’un modèle est une affirmation, et une affirmation se vérifie à peu de frais avant de l’exécuter.