Qu'est-ce que le slopsquatting ?

Qu'est-ce que le slopsquatting ? C'est une attaque Dans ce cas, des acteurs malveillants enregistrent les noms de paquets exacts que les assistants de programmation IA hallucinent, puis chargent ces paquets avec des logiciels malveillants et attendent qu'un développeur les installe. Il ne s'agit pas d'un cas marginal. Dans une recherche présentée à USENIX Sécurité 2025, 19.7 % des packages recommandés par les modèles de codage IA sur 576 000 échantillons de code n’existaient pas, et les chercheurs ont recensé plus de 205 000 noms hallucinés uniques dans les modèles testés.

Comprendre ce qu'est le slopsquatting (et à quoi cela ressemble concrètement) est important car il ne s'agit pas simplement d'une bizarrerie de l'IA. Le slopsquatting est le successeur, à l'ère de l'IA, de… le typosquattageIl existe une différence cruciale entre le typosquatting et le slopsquatting : ce dernier repose sur une faute de frappe humaine, tandis que le slopsquatting repose sur une erreur de modèle, répétée de manière suffisamment prévisible pour qu'un attaquant puisse l'exploiter à grande échelle. Ce guide explique ce qu'est le slopsquatting, pourquoi il se propage plus vite que les systèmes de contrôle des paquets ne peuvent le détecter, quels risques il engendre et comment les organisations peuvent le découvrir et le prévenir avant qu'il n'atteigne la production.

Définition du slopsquatting #

Le slopsquatting, en termes formels, consiste à enregistrer un nom de paquetage généré artificiellement par un modèle de langage de grande taille (un nom inventé qui semble plausible mais qui n'existe dans aucun registre public) et à y exécuter du code malveillant. avant qu'un véritable développeur ne l'installe sur la base de la suggestion de l'IA.

Le terme étend le concept de typosquatting (enregistrement d'un nom de paquet imitant un nom existant par le biais d'une faute d'orthographe courante) au mode de défaillance spécifique de l'IA générative. Alors que le typosquatting exploite une faute de frappe humaine, le slopsquatting exploite une erreur de frappe humaine. hallucinations du modèle d'IAn: un assistant de codage recommande pip install ou npm install pour un paquet qui n'a jamais existé, et un attaquant qui a remarqué le même nom inventé se répéter dans les invites l'enregistre en premier.

Le slopsquatting, en termes pratiques, est une attaque de la chaîne d'approvisionnement qui transforme une erreur de modélisation en une faille exploitable, sans qu'aucune erreur humaine ne soit requise, si ce n'est la confiance accordée à la suggestion de l'IA. Ce n'est pas une théorie. Un simple paquet malveillant, installé comme test anodin en 2023, a été téléchargé plus de 30 000 fois en trois mois sans aucune promotion, confirmant ainsi que des variantes malveillantes exploitant exactement ce schéma sont actuellement actives dans les registres publics.

Slopsquatting vs Typosquatting : quelle est la différence ? #

Le slopsquatting et le typosquatting aboutissent au même résultat (un développeur installe un paquet malveillant en le croyant légitime), mais la source de l'erreur est catégoriquement différente.

Le typosquatting repose sur une erreur de frappe humaine : un développeur souhaite écrire « requests » et tape « requests » à la place, et un attaquant ayant enregistré ce nom mal orthographié est à l’affût. Le risque est lié à une simple frappe, à un moment d’inattention.

Le slopsquatting élimine complètement l'erreur humaine et la remplace par une erreur de modèle, qui se répète à grande échelle pour chaque développeur recevant une invite similaire. Une analyse complémentaire a révélé que lorsque les chercheurs ont exécuté des invites identiques à dix reprises, 43 % des noms de paquets erronés sont apparus systématiquement, et 58 % se sont reproduits plus d'une fois. C'est cette répétabilité qui rend le slopsquatting vulnérable : un attaquant n'a pas besoin de deviner une faute de frappe. Il lui suffit d'observer quel nom erroné un modèle répète sans cesse et de l'enregistrer avant un développeur légitime.

La principale différence réside dans l'échelle. Un package typosquatté attend une erreur de frappe. Un package slopsquatté attend que la même recommandation générée par l'IA atteigne le développeur suivant, puis celui d'après, et ainsi de suite, dans toutes les organisations utilisant le même modèle.

Pourquoi les spreads de slopsquatting ? #

Le slopsquatting prolifère pour la même raison que le typosquatting depuis toujours : les attaquants exploitent un schéma prévisible auquel les développeurs font confiance par défaut. La nouveauté réside dans l’ampleur de cette confiance.

L'essor du codage assisté par l'IALes agents autonomes et les flux de travail de « codage intuitif », où les développeurs examinent de moins en moins de code avant de l’exécuter, ont modifié la surface d’attaque des logiciels de deux manières concrètes :

Le point d'entrée n'est plus seulement le développeur. Une attaque par typosquatting repose sur une simple faute de frappe. Le slopsquatting peut prendre naissance au sein même du modèle et se propager à des centaines de développeurs posant des questions similaires et recevant la même recommandation erronée, multipliant ainsi la portée d'une attaque unique.

La surface d'attaque s'est déplacée plus haut dans la chaîne de traitement. Il ne suffit plus d'examiner le code écrit par un humain. Les équipes doivent également surveiller les dépendances suggérées par un assistant IA, les serveurs MCP auxquels il se connecte et les agents qui installent des paquets de manière autonome, sans intervention humaine directe. La sécurité applicative traditionnelle, conçue pour examiner les dépôts et les humains, est désormais vulnérable. commits, n'a jamais été conçu pour observer cette nouvelle interaction entre développeur, IA et registre de paquets, et c'est précisément là que se cache le slopsquatting.

Risques liés au squat #

L'occupation illégale de logements crée des risques à plusieurs niveaux qui s'amplifient mutuellement, et la tendance s'accélère au lieu de s'estomper.

• Exploitation répétable. Comme les noms hallucinés ne sont pas aléatoires, un même faux nom réapparaît de manière prévisible d'une session à l'autre et d'un modèle à l'autre. Les attaquants n'ont pas besoin de deviner ; il leur suffit d'observer le comportement du modèle et de repérer les noms récurrents, transformant ainsi une hallucination ponctuelle en une attaque reproductible et à grande échelle.
• Propagation de l'agent. Le slopsquatting ne se limite plus au simple copier-coller d'une commande d'installation suggérée par un développeur. En janvier 2026, des chercheurs ont découvert que des agents de programmation IA avaient déjà diffusé des instructions faisant référence à un paquet npm erroné dans 237 dépôts, et que ces agents tentaient encore de l'installer quotidiennement, sans qu'aucun humain ne soit là pour détecter l'erreur.
• Évasion par similarité de nom. Environ 38 % des noms hallucinés ressemblent fortement à des paquets réels, ce qui réduit les chances qu'un développeur repère la substitution au premier coup d'œil. Un paquet malveillant dont le nom diffère d'un seul caractère d'une dépendance de confiance ne paraît pas suspect ; on dirait une simple faute de frappe.
• Exposition persistante après détection. Un paquet halluciné qui remplaçait un plugin ESLint légitime enregistrait encore des téléchargements hebdomadaires même après que le registre l'ait placé sous séquestre de sécurité, preuve que le signalement d'un paquet slopsquatté n'empêche pas immédiatement son installation.

Où se cache le squat #

Le plus difficile avec le slopsquatting, c'est que cela ne ressemble pas à une attaque au moment où elle se produit ; cela ressemble à une installation pip ou npm normale qui se termine avec succès, car le paquet existe réellement une fois qu'un attaquant l'a enregistré.

Le squattage s'introduit généralement par :

• Assistants et copilotes de programmation IA. La suggestion initiale, un nom de package fictif présenté aux côtés d'un code légitime et fonctionnel, est à l'origine de la vulnérabilité. Rien dans le code environnant ne semble anormal, car il ne l'est généralement pas ; seule la dépendance est factice.
• Agents de codage autonomes. Les flux de travail automatisés qui installent les dépendances sans vérification humaine suppriment le seul point de contrôle, à savoir un développeur qui s'arrête pour vérifier un nom, qui permettrait autrement de détecter un paquet erroné avant qu'il n'atteigne un projet.
• Gestionnaires de paquets sans étape de vérification. Ni `pip install` ni `npm install` ne signalent d'erreur lorsque le paquet cible existe et est malveillant. L'installation se termine normalement car, du point de vue du gestionnaire de paquets, rien d'anormal n'est détecté.

Comment détecter et prévenir le squattage #

Prévenir le slopsquatting ne nécessite pas d'outils exotiques. Il suffit d'appliquer systématiquement les bonnes pratiques de gestion des dépendances existantes, plutôt que de les assouplir dès qu'une IA « suggère » le code.

Vérifiez tout nouveau paquet avant de l'installer., surtout s'il s'agit d'une suggestion d'un assistant IA. Vérifiez son inscription dans le registre officiel, identifiez l'organisme qui le gère, sa date de publication et assurez-vous que le nombre de téléchargements est authentique.

Ne jamais supposer que le code généré par l'IA est sûr par défautUn code qui « fonctionne » ne signifie pas que ses dépendances sont légitimes. L'analyse des dépendances doit faire partie intégrante de la revue de code, et non en être une exception.

Déployez une analyse des dépendances qui signale les schémas de risque au-delà des CVE connues : paquets anormaux, noms suspectement similaires à des noms existants, nouveaux responsables de la maintenance sans antécédents ou scripts d’installation au comportement inhabituel.

Appliquer AI-SPM comme couche de gouvernance. La gestion de la posture de sécurité IA est une pratique conçue pour détecter précisément ce type de risque introduit par l'IA à grande échelle, en découvrant en permanence les dépendances suggérées par l'IA et en les évaluant avant même qu'un humain ait à penser à les vérifier manuellement.

Se prémunir contre le squat avec Xygeni #

Le slopsquatting ne peut être empêché par la seule vigilance des développeurs. Une politique consistant à « vérifier chaque paquet suggéré par l'IA » est inapplicable à grande échelle dans une organisation où les suggestions de dépendances arrivent plus vite que n'importe quel processus de vérification humaine ne peut les traiter.

Xygéni Cette approche traite cela comme un problème de détection continue : inventaire et IA Nomenclature IA surface chaque IA introduite dépendance à travers le SDLC, offrant aux équipes un historique complet des suggestions et installations effectuées par l'assistant IA. Xygeni Shield, Alimenté par MEW (Alerte précoce aux logiciels malveillants), détecte et bloque les paquets malveillants, y compris ceux slopsquattés, avant même qu'une signature n'existe, comblant ainsi la lacune exacte que les scanners basés sur les signatures laissent ouverte.

Si vos équipes utilisent des assistants de programmation IA, le problème du slopsquatting est déjà présent. La question est de savoir si le prochain nom erroné sera détecté avant son installation.

QFP #