Slopsquatting : quand l'IA recommande des paquets qui n'existent pas

Tu demandes à une IA de code d’ajouter une fonctionnalité. Elle te répond « installe telle bibliothèque », tu copies la commande, tu l’exécutes. Sauf que cette bibliothèque n’existe pas. Ou pire : elle existe, parce qu’un pirate a vu passer la même suggestion avant toi et a enregistré ce nom exprès. Ce mécanisme a un nom, une étude scientifique derrière, et une méthode simple pour s’en protéger.

D’où vient le problème : une étude scientifique précise

En 2025, six chercheurs (Joseph Spracklen, Raveen Wijewickrama, A H M Nazmus Sakib, Anindya Maiti, Bimal Viswanath et Murtuza Jadliwala) publient à ce sujet une étude au 34e symposium USENIX Security, l’une des conférences de référence en sécurité informatique, intitulée « We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs ».

Leur méthode : générer 576 000 extraits de code avec 16 modèles d’IA différents (des modèles commerciaux et des modèles open source), en Python et en JavaScript, puis vérifier si chaque paquet mentionné existe vraiment sur les registres officiels (npm, PyPI). Résultat : 19,7 % des paquets recommandés n’existaient pas. Le taux grimpe à 21,7 % pour les modèles open source, contre 5,2 % pour les modèles commerciaux. Au total, les chercheurs ont recensé 205 474 noms de paquets différents, tous inventés.

Le détail le plus important pour comprendre la suite : ces noms inventés ne sont pas aléatoires d’une fois sur l’autre. Un même modèle, interrogé plusieurs fois avec un prompt proche, a tendance à réinventer le même nom fictif. C’est exactement ce qui rend l’attaque possible.

Comment un pirate en profite : le slopsquatting

Seth Larson, développeur en résidence à la Python Software Foundation, donne un nom à cette technique d’attaque en avril 2025 : le « slopsquatting », contraction de « AI slop » (le contenu de mauvaise qualité généré par IA) et de « typosquatting » (la technique consistant à enregistrer un nom proche d’un nom connu pour piéger une faute de frappe).

Le mécanisme est direct : un attaquant repère, en interrogeant les mêmes modèles d’IA que tout le monde utilise, quels noms de paquets fictifs reviennent souvent. Il enregistre ensuite ce nom, pour de vrai, sur npm ou PyPI, avec du code malveillant à l’intérieur. Il n’a plus qu’à attendre qu’un développeur (ou un agent IA autonome qui exécute les commandes sans supervision) tape npm install nom-invente ou pip install nom-invente en suivant aveuglément la suggestion. La faille n’est plus dans un paquet existant : elle est dans la confiance accordée à un nom qui n’a jamais existé avant que l’attaquant ne le crée.

Le Top 10 OWASP 2025, la référence mondiale des risques de sécurité web, a d’ailleurs créé en 2025 une catégorie dédiée à ce type de risque, « Software Supply Chain Failures », qui élargit l’ancienne catégorie consacrée aux composants vulnérables : la chaîne d’approvisionnement logicielle (d’où viennent tes dépendances, comment elles sont distribuées) est désormais reconnue comme un risque à part entière, pas seulement un détail technique.

Pourquoi ça touche particulièrement le vibe-coding

Quand tu ne codes pas toi-même au quotidien, tu n’as pas forcément le réflexe de vérifier qu’un paquet existe vraiment avant de l’installer : l’IA te dit de le faire, tu le fais. C’est précisément le terrain où le slopsquatting fonctionne le mieux. Un projet de recherche a d’ailleurs constaté qu’un nom de paquet halluciné pouvait réapparaître d’un modèle à l’autre et d’une requête à l’autre, ce qui veut dire que le même faux nom peut circuler largement avant qu’un attaquant ne l’exploite.

Et si c’est l’IA elle-même qui tape la commande ?

Les outils de vibe-coding les plus récents (Claude Code, Replit Agent, et d’autres agents similaires) ne se contentent pas de suggérer une commande : ils peuvent l’exécuter eux-mêmes, sans qu’un humain ne la relise avant qu’elle ne parte. C’est justement ce qui rend le slopsquatting plus dangereux dans ce contexte précis : l’installation de dépendances déclarées dans un fichier de configuration est, par nature, une action considérée comme routinière par ces outils, pas comme une action à risque qui déclenche automatiquement une double vérification. Le nom halluciné n’a même plus besoin de convaincre un humain de taper npm install : il suffit qu’il convainque l’IA de le proposer, une seule fois, pour qu’il se retrouve exécuté.

Ça ne veut pas dire qu’il faut se passer de ces outils, mais que la vérification manuelle décrite plus bas devient encore plus utile quand tu leur laisses le clavier : relis la liste des paquets qu’une IA s’apprête à installer avant de valider, exactement comme tu relirais une modification de code.

La méthode pour vérifier un paquet avant de l’installer

Avant de lancer npm install ou pip install sur un nom suggéré par une IA, prends trente secondes pour ces vérifications :

1. Confirme que le paquet existe vraiment, sur le site officiel du registre (npmjs.com ou pypi.org), pas seulement dans le terminal. Tu peux aussi demander les informations en ligne de commande sans encore l’installer :

npm view nom-du-paquet

2. Regarde son historique. D’après le guide de sécurité npm d’OWASP, un paquet fiable a généralement « des milliers, voire des millions de téléchargements » et « un vrai dépôt GitHub, avec du code, des commits et des contributeurs authentiques ». Un paquet publié la veille, avec zéro téléchargement et aucun dépôt, doit t’alerter, surtout si c’est l’IA qui vient de te le suggérer.
3. Lance un audit de sécurité sur ce que tu as déjà installé :

npm audit

D’après la documentation officielle de npm, cette commande « soumet une description des dépendances de ton projet à ton registre par défaut et demande un rapport des failles connues ».

4. Garde un fichier de verrouillage (package-lock.json ou équivalent) et évite d’installer une version qui n’y figure pas encore sans l’avoir vérifiée.
5. Vérifie l’orthographe exacte. Un nom presque bon, une lettre inversée ou un tiret déplacé, est un signe classique d’un paquet qui se fait passer pour un autre plus connu, que l’IA soit ou non impliquée dans la suggestion.
6. Pour aller plus loin, des outils automatisés existent pour repérer les paquets récemment publiés ou suspects avant qu’ils n’entrent dans ton projet, en complément de ta propre vigilance.

Rien de tout ça ne prend longtemps une fois que c’est devenu un réflexe. Il ne s’agit pas de te méfier de chaque suggestion d’une IA de code, mais de traiter un nom de paquet comme tu traiterais un lien reçu dans un mail auquel tu ne t’attendais pas : ça mérite un second regard avant de cliquer, ou ici, avant d’installer.

À retenir

• Une étude USENIX Security 2025, portant sur 576 000 extraits de code et 16 modèles d’IA, a mesuré que 19,7 % des paquets recommandés par ces IA n’existaient pas.
• Le slopsquatting (terme de Seth Larson, avril 2025) consiste, pour un attaquant, à enregistrer ces noms inventés avant qu’un développeur ne les installe par erreur.
• Ce risque figure désormais dans une catégorie propre du Top 10 OWASP 2025, consacrée à la chaîne d’approvisionnement logicielle.
• Avant d’installer un paquet suggéré par une IA : vérifie qu’il existe sur le registre officiel, regarde son historique de téléchargements et son dépôt, puis lance un audit de sécurité.
• Ne jamais faire confiance à un nom de paquet uniquement parce qu’une IA vient de te le donner.

Pour automatiser cette vérification à chaque installation, le connecteur verif-paquets fait cette recherche à ta place avant que tu tapes la commande.