Slopsquatting: cuando tu asistente de IA instala un paquete que no existe

Pide ayuda a un asistente de programación y a menudo te sugerirá una librería junto con el código. La mayoría de las veces la librería es real. A veces no lo es: el modelo produce un nombre que suena bien, sigue las convenciones de nombres del ecosistema y, sencillamente, no existe en npm ni en PyPI. Si ejecutas el comando de instalación sin mirar, pasa una de dos cosas. La instalación falla, lo cual es molesto pero inofensivo. O alguien ya ha publicado un paquete con ese nombre exacto, y acabas de ejecutar su código.

Qué es el slopsquatting

Slopsquatting es el nombre de ese segundo caso: registrar nombres de paquetes que los modelos de IA tienden a inventar y esperar a que la gente los instale. El término suele atribuirse a Seth Larson, security developer-in-residence de la Python Software Foundation, y es un juego de palabras con el typosquatting, en el que los atacantes registran variantes mal escritas de paquetes populares. La diferencia está en quién comete el error. Con el typosquatting, una persona se equivoca al teclear. Con el slopsquatting, un modelo sugiere con total seguridad el nombre equivocado y una persona se fía.

El riesgo no es hipotético. En un experimento del que se habló mucho, un investigador se dio cuenta de que los modelos recomendaban una y otra vez un paquete llamado huggingface-cli, que no es la forma en que se instala la herramienta real de Hugging Face. Publicó un paquete vacío con ese nombre para ver qué pasaba, y se descargó decenas de miles de veces. El paquete era inofensivo. Uno malicioso no lo habría sido.

Con qué frecuencia inventan paquetes los modelos

El estudio más exhaustivo hasta la fecha es «We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs», presentado en USENIX Security 2025. Los autores generaron 576.000 muestras de código en Python y JavaScript con 16 modelos populares y comprobaron cada paquete al que hacía referencia el código. Encontraron que el porcentaje medio de paquetes alucinados era de al menos el 5,2 % en los modelos comerciales y del 21,7 % en los modelos open source, y recopilaron 205.474 nombres de paquetes únicos que no existían.

Dos detalles del artículo importan más que las cifras principales. Primero, los nombres inventados suelen repetirse: cuando los autores volvieron a ejecutar diez veces los prompts que habían producido una alucinación, el 43 % de esos nombres reaparecieron todas y cada una de las veces. Los nombres predecibles son justo lo que necesita un atacante. Segundo, la mayoría no son variantes mal escritas de paquetes reales, así que una comprobación de erratas no los detectará. Solo alrededor del 13 % se diferenciaban en uno o dos caracteres de un nombre existente.

Los modelos han mejorado desde aquellos experimentos, y los asistentes que buscan en el registro antes de sugerir un paquete hacen que el problema sea menos frecuente. Menos frecuente no significa desaparecido, sobre todo en tareas de nicho en las que el modelo ha visto pocos ejemplos reales.

Por qué el ataque es viable

Publicar en npm o PyPI es gratis y lleva minutos. Un atacante no necesita comprometer nada; solo necesita adivinar los nombres que producen los modelos y registrarlos antes que nadie. Después, los scripts de instalación hacen el resto: npm ejecuta por defecto los scripts preinstall y postinstall, y un paquete de Python puede ejecutar código al construirse o importarse. Una sola instalación en el portátil de un desarrollador o en un runner de CI puede exponer claves SSH, credenciales de la nube y tokens en variables de entorno.

Los agentes agravan el problema. Cuando un asistente puede ejecutar npm install o pip install por su cuenta, puede que ninguna persona llegue a mirar el nombre del paquete.

Revisa un paquete en un minuto

Antes de añadir una dependencia que no elegiste tú, búscala en el registro:

# 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}'

Después hazte unas cuantas preguntas rápidas:

• ¿Existe siquiera? Un 404 significa que el nombre era inventado. No lo crees, y no instales una alternativa «parecida» sin revisarla también.
• ¿Es completamente nuevo? Un paquete publicado por primera vez en las últimas semanas, con una sola versión y sin historial, merece una segunda mirada, sobre todo si su nombre coincide con lo que sugirió tu asistente.
• ¿Apunta a un proyecto real? Un repositorio enlazado con commits, issues y otros usuarios es buena señal. Un repositorio vacío o inexistente, no.
• ¿Es el paquete que la documentación te dice que instales? La documentación de la propia herramienta es la mejor fuente para el nombre correcto. huggingface-cli frente al comando de instalación documentado es un buen ejemplo de por qué.

Hábitos que ayudan

• Usa lockfiles e instala a partir de ellos en CI (npm ci, pip install -r con versiones fijadas y hashes), para que no se cuele un nombre nuevo durante un build.
• Revisa los cambios de dependencias en las pull requests con el mismo cuidado que los cambios de código. Un diff que añade tres paquetes merece tres búsquedas.
• Pide a tu asistente que enlace la página del paquete en el registro o su documentación oficial cuando sugiera algo nuevo. Es una forma barata de destapar un nombre inventado.
• Si tu agente puede ejecutar instalaciones por su cuenta, dale una allowlist o exige confirmación para las dependencias nuevas.
• Plantéate desactivar los scripts de instalación por defecto (npm config set ignore-scripts true) y activarlos solo para los paquetes que los necesiten. Rompe algunos paquetes, así que pruébalo antes.

Automatiza la parte tediosa

Las búsquedas manuales funcionan para un paquete. No escalan a un repositorio con cientos de dependencias, ni a imports enterrados en código que un asistente generó la semana pasada. Es un buen trabajo para las herramientas.

La suite de riesgos del código generado por IA de vetkit busca las dependencias y los imports de tus manifiestos en registros públicos como npm y PyPI. Señala los nombres que no existen, las versiones que nunca se publicaron y los paquetes publicados por primera vez en los últimos 30 días. A los registros solo se envían nombres y versiones de paquetes, nunca tu código fuente, y no se buscan los paquetes de registros privados ni de tus propios workspaces. El servidor MCP de vetkit también expone una comprobación de paquetes, para que un asistente pueda verificar un nombre antes de instalar nada.

Uses lo que uses, el principio es el mismo: un nombre de paquete que viene de un modelo es una afirmación, y verificar una afirmación antes de ejecutarla cuesta muy poco.