Quand votre assistant de codage invente un paquet, les attaquants l'enregistrent en premier

Demandez à un assistant de codage IA de nettoyer les imports et il peut vous fournir un nom de paquet qui n'existe pas. Le nom semblera plausible. Il combinera deux outils réels ou suivra une convention de nommage que vous reconnaissez. Vous collez la commande d'installation, et si quelqu'un a déjà enregistré ce nom, vous venez d'installer tout ce qu'il a publié.

Les chercheurs en sécurité appellent cela le slopsquatting. C'est un parent du typosquatting, sauf que l'attaquant n'a pas besoin que vous fassiez une faute de frappe. Il lui suffit de savoir ce que le modèle a tendance à inventer, puis d'être le premier à le revendiquer.

L'ampleur n'est pas anecdotique

Une étude USENIX Security de 2025 a testé 16 modèles de génération de code sur 576 000 échantillons de code en Python et en JavaScript. Elle a trouvé plus de 205 000 noms de paquets uniques qui n'existaient sur aucun registre. Le taux d'hallucination était d'au moins 5,2 % pour les modèles commerciaux et de 21,7 % pour les modèles open source. Une étude de suivi de 2026 a testé cinq modèles frontières plus récents et mesuré des taux entre 4,62 % et 6,10 %, ce qui est plus faible mais toujours présent dans chaque modèle testé.

Ce qui transforme une bizarrerie en surface d'attaque, c'est la répétabilité. Lorsque les chercheurs ont relancé des prompts identiques, une grande part des noms hallucinés revenait à chaque fois. Les modèles ne devinent pas au hasard ; ils convergent vers les mêmes mauvaises réponses parce qu'ils ont appris les mêmes schémas à partir des mêmes données d'entraînement. Cette prévisibilité est la vulnérabilité. Un attaquant peut exécuter les mêmes prompts, collecter les noms qui se répètent et les enregistrer avant tout le monde.

L'étude de 2026 a identifié 127 noms de paquets que les cinq modèles testés produisaient alors qu'ils n'existaient pas, dont 53 étaient encore disponibles à l'enregistrement après l'application des protections des registres.

De vrais paquets, de vraies installations

Cela s'est déjà produit. Début 2026, des chercheurs ont trouvé un paquet appelé react-codeshift référencé dans 237 dépôts GitHub. Le nom mélange deux outils réels, jscodeshift et react-codemod. Il n'avait jamais été publié. Une compétence générée par IA contenant le paquet fictif avait été copiée et forkée, permettant à la référence de se propager d'elle-même.

Un paquet appelé metro-evaluator sur npm contenait du code malveillant dans quatre versions publiées en décembre 2025 avant d'être retiré cinq jours plus tard et remplacé par un espace réservé de sécurité. Les modèles testés avaient suggéré ce nom dix fois. Un autre, unused-imports, imitait le véritable eslint-plugin-unused-imports et continuait de collecter des installations auprès de développeurs dont l'assistant les y avait orientés.

L'opération plus vaste est une campagne que la société de sécurité Koi Security appelle PhantomRaven, active depuis au moins août 2025. Koi lui attribue 126 paquets npm malveillants et plus de 86 000 téléchargements. L'astuce est différente d'un nom halluciné. Le package.json semble propre, ne contenant parfois guère plus qu'une ligne de journal, mais il pointe vers une dépendance hébergée à une URL HTTP en clair plutôt que vers un autre paquet npm. La plupart des scanners ne suivent pas les URL brutes, de sorte que la charge utile qui récolte les jetons npm, les identifiants GitHub et les secrets CI se charge invisiblement au moment de l'installation. Endor Labs a documenté trois nouvelles vagues de la même campagne entre novembre 2025 et février 2026, ajoutant 88 paquets supplémentaires téléversés via environ 50 comptes jetables.

Les registres ont bloqué la plupart des noms, pas tous

Il y a une bonne nouvelle dans la recherche. Les registres de paquets sont devenus meilleurs pour bloquer les noms que les modèles ont tendance à inventer. Ils normalisent les noms similaires, tiennent des listes d'interdiction et surveillent les schémas qui apparaissent dans de nombreux échantillons générés. Lorsque l'étude de 2026 a vérifié sa liste de 127 noms hallucinés partagés, la plupart avaient déjà été revendiqués ou bloqués par des projets légitimes et les défenses des registres.

Le problème est que « la plupart » ne signifie pas « tous ». La même étude a trouvé 53 noms encore disponibles à l'enregistrement après l'application des protections. Un seul nom enregistrable sur lequel plusieurs modèles frontières s'accordent suffit pour construire une attaque, car l'attaquant n'a besoin de deviner que le modèle, pas le développeur. Les opérateurs de registres ont fermé la majeure partie de la porte ; l'écart restant est étroit mais ouvert.

Le même schéma s'est désormais étendu au-delà des gestionnaires de paquets. Des chercheurs en sécurité ont documenté des attaquants enregistrant des domaines que les modèles hallucinent, ainsi que des dépôts et des compétences que les agents sont susceptibles d'inventer. Le mécanisme est identique dans chaque cas : un modèle prédit un nom plausible, et un système conçu pour faire confiance à cette prédiction agit en conséquence. Chaque nouvelle surface qu'un agent peut atteindre devient un endroit de plus où planter un nom que l'agent ira chercher.

Pourquoi les agents aggravent la situation

Un développeur humain pourrait remarquer un nom de paquet suspect. Un agent, non. Les agents installent des dépendances de manière autonome, souvent sans qu'un humain lise d'abord la commande. Des chercheurs ont démontré des techniques d'injection de prompt qui amènent les agents à demander des noms de paquets contrôlés par l'attaquant, avec des taux de réussite rapportés allant jusqu'à 100 % sur des outils tels que Cursor, Windsurf et GitHub Copilot.

C'est cette combinaison qui a changé le profil de risque. L'hallucination fournit le nom. L'agent fournit l'exécution. L'attaquant n'a plus qu'à attendre que les deux se rencontrent.

Le problème de fuite est le même problème

Un rapport connexe de la société Glow a révélé que des agents exposaient plus de 13 000 images internes sur GitHub, provenant de plus de 300 organisations. Le mécanisme est banal : les agents et leurs utilisateurs placent des captures d'écran, des diagrammes et des documents dans des dépôts publics, parfois sans comprendre que « public » signifie consultable et permanent. Les mêmes outils qui accélèrent les développeurs facilitent aussi le déplacement de matériel interne vers un endroit où il ne devrait pas aller.

Les deux problèmes partagent une même cause racine. Les agents agissent à la vitesse de la machine sur des instructions qui peuvent être erronées (un nom halluciné) ou sensibles (une capture d'écran interne). Le point de contrôle humain qui se trouvait autrefois entre l'intention et l'action est exactement ce que l'agent supprime.

Ce qu'il faut vraiment faire

Les défenses ne sont pas compliquées, ce qui est une bonne nouvelle vu la rapidité avec laquelle la menace a évolué.

Traitez chaque commande d'installation produite par un agent comme une entrée non fiable. Vérifiez que le paquet existe avant de l'installer. Vérifiez son ancienneté ; un nom halluciné qui a été enregistré sera récent. Vérifiez que l'éditeur a un historique. Pour npm et PyPI, une rapide consultation des métadonnées répond aux trois questions en quelques secondes.

Exigez une approbation humaine avant qu'un agent n'ajoute une dépendance. C'est le changement à plus forte valeur, car il intercepte à la fois les noms hallucinés, les enregistrements malveillants et les requêtes issues d'injections de prompt. Cela ralentit légèrement l'agent et ferme la plus grande faille.

Limitez la portée de l'agent. Un agent de codage a besoin d'un accès au dépôt ; il a rarement besoin d'identifiants de production, et il ne devrait pas avoir un gestionnaire de paquets pointé vers un registre privé sans vérification. Des outils comme Socket et Snyk peuvent automatiser la consultation du registre dans l'IDE ou le pipeline CI, ce qui vaut le coût dès qu'une équipe utilise des agents sur de nombreux dépôts.

La partie inconfortable est que rien de tout cela n'est un bug qui sera corrigé par un patch. L'hallucination est intégrée à la façon dont ces modèles prédisent le texte : ils génèrent le prochain nom plausible, pas un nom vérifié. La correction doit résider dans le flux de travail autour du modèle, et c'est un processus que la plupart des équipes peuvent commencer cette semaine.