¿Qué es el slopsquatting? El nuevo ataque HalluSquatting a los agentes de IA

¿Qué es el slopsquatting?

El slopsquatting es la práctica de registrar un nombre de paquete de software que no existe pero que un gran modelo de lenguaje tiene probabilidades de alucinar, de modo que un desarrollador o un agente de IA instale el paquete del atacante creyendo que es legítimo. El término lo acuñó Seth Larson, Security Developer-in-Residence en la Python Software Foundation, en abril de 2025, como una combinación de "AI slop" (basura de IA) y "typosquatting".

Debajo hay dos ideas, y conviene mantenerlas separadas. La alucinación de paquetes (package hallucination) es el comportamiento del modelo: un LLM, al que se le pide escribir código, referencia un objetivo de instalación que nunca se publicó. El slopsquatting es el ataque que convierte ese comportamiento en un mecanismo de entrega, al reclamar primero el nombre alucinado. La alucinación es la vulnerabilidad; el slopsquatting es el exploit.

“

Un humano que lee "pip install reqwest-py" quizá se detenga y compruebe. Un agente ejecuta el comando. En el momento en que el nombre de un paquete pasa de una sugerencia que una persona teclea a una acción que un agente ejecuta, el último punto de control humano desaparece.

Slopsquatting frente a typosquatting: ¿cuál es la diferencia?

Ambos son ataques de confusión de nombres contra la cadena de suministro de software, pero explotan errores distintos y, lo que es crucial, evaden defensas distintas.

La diferencia que lo sostiene todo es la tercera fila. Las defensas contra el typosquatting dan por hecho que el nombre malicioso se parece a uno real, así que marcan los paquetes que están a una pequeña distancia de edición de las bibliotecas populares. Un nombre alucinado no es un error de escritura de nada. El análisis de nombres alucinados que hizo Socket encontró que casi la mitad eran muy distintos de cualquier paquete real, fabricados pero creíbles en su contexto, que es exactamente por lo que la detección de imitaciones pasa de largo junto a ellos.

¿Cómo funciona en realidad un ataque de slopsquatting?

El ataque tiene cuatro pasos, y la parte incómoda es que el atacante no necesita adivinar. El modelo le dice qué registrar.

Lo que hace explotable el segundo paso es que las alucinaciones no son ruido aleatorio. En el mayor estudio hasta la fecha, los investigadores repitieron el mismo prompt diez veces y encontraron que el 43% de los nombres de paquetes alucinados reaparecían en las diez ejecuciones, y el 58% reaparecía más de una vez. El modelo no inventa un nombre falso distinto cada vez; gravita hacia los mismos. Un atacante puede cosechar estos nombres a granel, registrar los persistentes y esperar. Como los agentes en modos autónomos o "yolo" instalan y ejecutan sin confirmación, el hook posinstalación de la carga útil se dispara en el instante en que el paquete aterriza, antes de que exista un pull request que revisar.

¿Con qué frecuencia aparecen los paquetes alucinados?

Suficiente como para ser un canal de distribución y no un caso extremo. La medición definitiva es el estudio de USENIX Security 2025 "We Have a Package for You!" de la University of Texas at San Antonio y Virginia Tech, que analizó 2,23 millones de muestras de código generadas por 16 modelos en Python y JavaScript.

La tasa no es uniforme. Los modelos de código abierto alucinaron paquetes en el 21,7% de las muestras frente al 5,2% de los modelos comerciales, una brecha aproximadamente cuádruple, y algunos modelos especializados en código inventaron un paquete en más de un tercio de sus salidas. Dos fuerzas empujan luego el riesgo hacia arriba con el tiempo, no hacia abajo: los equipos dejan cada vez más que los agentes escriban e instalen dependencias sin supervisión, y los mismos modelos siguen sugiriendo los mismos nombres fabricados a todo el que pregunta.

¿Ha ocurrido el slopsquatting en el mundo real?

Sí, y la prueba es anterior al nombre. A finales de 2023, el investigador de seguridad Bar Lanyado, de Lasso Security, se dio cuenta de que varios modelos alucinaban repetidamente un paquete de Python llamado huggingface-cli. Como una prueba de concepto inofensiva, publicó un paquete vacío con ese nombre. En tres meses se había descargado más de 30.000 veces y, según informó The Register, una gran empresa (Alibaba) referenciaba el comando de instalación en el README de uno de sus propios repositorios de investigación. El paquete era benigno. Un actor malicioso que observara la misma alucinación no lo habría sido.

El giro de 2026 es que ahora los agentes de IA propagan estos nombres por usted. La nota de investigación de abril de 2026 sobre slopsquatting de la Cloud Security Alliance documenta cómo los comandos de instalación alucinados se propagan a través de archivos de "agent skill" copiados y pegados. En un caso de enero de 2026, un paquete npm fabricado (un nombre que un modelo produjo al fusionar dos herramientas reales) ya estaba referenciado por 237 repositorios de GitHub antes de que nadie lo señalara, sembrado en gran parte por un solo commit que añadió decenas de archivos de skill generados por LLM. La alucinación no se quedó en una ventana de chat; se subió, se compartió y la reejecutó cada agente que leyó el skill.

¿Qué es el ataque HalluSquatting (julio de 2026)?

Durante casi toda la corta historia del slopsquatting el atacante era oportunista: registrar cualesquiera nombres que el modelo tienda a favorecer y luego esperar. Un artículo publicado el 8 de julio de 2026, "Beware of Agentic Botnets" de Spira, Cohen, Feldman, Bitton, Wool y Nassi (Tel Aviv University, Technion e Intuit), elimina la espera. Demuestra un detonante adversario universal y transferible que hace que los agentes alucinen bajo demanda un recurso específico elegido por el atacante, en lugar de confiar en que caigan sobre uno que el atacante ya posee.

El mecanismo encadena dos fallos que las secciones anteriores describen. Primero, el detonante dirige al agente a obtener un recurso (un repo, un skill, un paquete) bajo un nombre que el atacante controla. Segundo, una inyección de prompt indirecta oculta dentro de ese recurso obtenido se ejecuta cuando la terminal del agente lo corre, logrando ejecución remota de herramientas e instalando malware de botnet autopropagable. Los investigadores enmarcan el resultado como un ataque escalable y sin objetivo concreto: un solo detonante adversario, sin preparación por víctima, malware que se propaga de un agente comprometido al siguiente.

¿Por qué no puede atraparlo un escáner?

Porque los dos controles en los que se apoya la mayoría de los equipos miran en el lugar equivocado o llegan demasiado tarde.

Lea de arriba abajo la columna de la derecha y emerge un solo tema. Cada uno de estos controles actúa sobre el paquete después de que está en disco, o busca un parecido que un nombre fabricado no tiene. El script de instalación de una dependencia maliciosa se ejecuta en el momento de la instalación, que para un agente autónomo es segundos después de que el modelo inventara el nombre, y mucho antes de que ningún escáner, revisor o fuente de CVE tenga algo que decir. El único lugar donde detenerlo es antes de que se ejecute el comando de instalación.

Cómo prevenir el slopsquatting

Ninguna de estas medidas es exótica. La disciplina está en aplicarlas a agentes que se mueven más rápido que los humanos que los supervisan.

1. Desactive la autoinstalación a ciegas. No ejecute agentes en modos totalmente autónomos de "instalar y ejecutar" contra credenciales reales. Exija aprobación explícita para cualquier dependencia nueva, para que un nombre fabricado tenga que pasar al menos un vistazo humano.

2. Verifique que un paquete existe y es real antes de añadirlo. "Se instaló" no es prueba de legitimidad; el atacante se aseguró de que se instalara. Compruebe que el paquete tiene un historial genuino: antigüedad, trayectoria de descargas, un repositorio de origen real, mantenedores identificados. Un paquete registrado la semana pasada que un modelo jura que es estándar tiene exactamente la forma de este ataque.

3. Fije las versiones y suba lockfiles con hashes de integridad. Un lockfile con hashes significa que una versión sustituida o recién envenenada no puede reemplazarse a sí misma en silencio, y hace que una dependencia nueva sea visible como un cambio revisable en lugar de una descarga transitiva invisible.

4. Acote de dónde pueden venir los paquetes. Use un espejo interno, un registro privado o una lista de permitidos para que el agente solo pueda instalar desde fuentes verificadas. Si un nombre alucinado no está en el espejo, la instalación falla de forma segura en lugar de acudir al registro público.

5. Ejecute análisis de composición de software (SCA) como red de contención. Vale la pena pasar SCA a cada dependencia nueva, pero trátelo como la última red, no la primera. Atrapa paquetes y versiones ya conocidos como maliciosos; no atrapará un paquete malicioso de día cero el día en que se registra.

6. Revise específicamente las dependencias nuevas. Convierta "¿este cambio añade una dependencia?" en un paso de revisión explícito. Una línea añadida a package.json o requirements.txt merece más escrutinio que cien líneas de lógica de negocio, porque importa el código de otra persona con sus privilegios.

7. Aísle el trabajo del agente no confiable. Cuando un agente actúe sobre un repositorio desconocido o contenido de terceros, déle un contenedor sin secretos del host y sin ruta a producción. Los scripts de instalación se ejecutan de inmediato, así que un agente dirigido no debería tener nada valioso al alcance cuando uno se dispare.

8. Trate los paquetes sugeridos por el agente como entrada no confiable. La confianza de la sugerencia no es evidencia. Un nombre que el modelo presenta como obvio es precisamente el nombre que un atacante ya ha comprobado que al modelo le gusta.

Dónde tiene que vivir la prevención: la aplicación en tiempo de agente

Recorra de nuevo esa lista y los controles eficaces comparten una propiedad: actúan antes de que se ejecute el comando de instalación. El escáner que lee un diff, la fuente de SCA, la base de datos de CVE, todos llegan después de que el agente ya ha obtenido y ejecutado el paquete. A ritmo de agente, eso es demasiado tarde. El lugar para hacer cumplir "no instales un paquete que no puedes verificar" es dentro del bucle del agente, en el momento en que el agente alcanza el comando de instalación.

Esa es la capa que añade VibeDefend. Es una CLI de npm gratuita que se instala en unos cinco segundos y conecta sus agentes de programación con IA (Claude Code, OpenAI Codex, Cursor, Windsurf y VS Code Copilot) a un gobierno que corre mientras trabajan, no después.

Dos de las cuatro capas encajan directamente sobre este ataque. Action Guard intercepta la acción arriesgada antes de que se dispare: la instalación de un paquete no verificado, recién creado o ausente de su lista de permitidos se advierte o se bloquea, con la interceptación en el registro de auditoría, así la dependencia fabricada nunca llega al paso de instalación. Las reglas de seguridad cargan la propia disciplina en el contexto del agente antes de que escriba, de modo que "verifica que una dependencia existe y es de confianza antes de añadirla" es una regla que el agente lee en el momento del prompt, en lugar de un ítem de una lista que nadie aplicó. Junto a ellas, Live Findings mantiene en vivo en el contexto del agente cada resultado de los escáneres de CybeDefend (SAST con alcanzabilidad, SCA, secretos, IaC y CI/CD), así un problema de dependencia se tría dentro del bucle en lugar de aflorar días después.

Y el SCA de CybeDefend refresca su inteligencia sobre vulnerabilidades de forma continua, con una nueva descarga cada quince minutos aproximadamente, así que en cuanto se divulga que un paquete es malicioso aflora en el agente en cuestión de minutos y no en el siguiente análisis nocturno, y cada dependencia que el agente incorpora se comprueba dentro del bucle. Las dos capas cierran los huecos de la otra: Action Guard detiene la instalación de un paquete recién creado que nadie ha señalado todavía, y el SCA en constante actualización atrapa los que solo se revelan como maliciosos más tarde.

Es importante destacar que nada de su código cruza la red. Las decisiones ocurren localmente, junto al agente; solo metadatos de gobierno estructurados (la regla que se disparó, la ruta del archivo, la severidad, una marca de tiempo) llegan al backend, y los tenants de EU y US están físicamente separados. Esto no es un reemplazo de los lockfiles, las listas de permitidos y la revisión humana. Es la capa que los vuelve exigibles a la velocidad a la que un agente realmente trabaja, así la instalación de un paquete que nunca fue real se detiene antes de que ocurra, en lugar de investigarse después.

CybeDefend es la capa de AppSec en tiempo de agente construida exactamente para esto. Conecta cada agente de programación con IA de su máquina a sus reglas de negocio, sus marcos de seguridad (OWASP, SOC 2, GDPR, ISO 27001), un Action Guard que bloquea las instalaciones inseguras o sin verificar antes de que se ejecuten, y el análisis en constante actualización de cada dependencia y cada línea que el agente escribe. El slopsquatting solo funciona en el hueco entre un modelo que inventa un nombre y un humano que se da cuenta. CybeDefend cierra ese hueco, dentro del bucle, antes de que el PR llegue siquiera a abrirse.

Preguntas frecuentes

¿Qué es el slopsquatting?

El slopsquatting es un ataque a la cadena de suministro de software que registra un nombre de paquete que un modelo de IA tiene probabilidades de alucinar, de modo que los desarrolladores y los agentes de programación con IA instalen el paquete malicioso del atacante creyendo que es una dependencia real. El término, acuñado por Seth Larson, de la Python Software Foundation, en abril de 2025, combina "AI slop" y "typosquatting". Funciona porque los grandes modelos de lenguaje inventan nombres de paquetes plausibles que no existen, e inventan los mismos de forma consistente, lo que da a los atacantes una lista predecible de nombres que reclamar.

¿Cuál es la diferencia entre slopsquatting y typosquatting?

El typosquatting explota los errores de tecleo humanos al registrar nombres que se parecen mucho a paquetes reales, así que se puede detectar midiendo la distancia de cadenas respecto a las bibliotecas populares. El slopsquatting explota la alucinación de la IA al registrar nombres totalmente fabricados que un modelo inventa, que no son errores de escritura de ningún paquete real y, por tanto, evaden la detección de imitaciones. En resumen, el typosquatting apuesta a que a usted se le resbalen los dedos; el slopsquatting apuesta a que su asistente de IA invente una dependencia y se la instale.

¿Qué es el ataque HalluSquatting?

El HalluSquatting es una escalada de 2026 del slopsquatting descrita en el artículo "Beware of Agentic Botnets" (arXiv, 8 de julio de 2026). En lugar de esperar a que un modelo tropiece con un nombre que el atacante ya posee, usa un detonante adversario universal y transferible para hacer que los agentes de IA alucinen bajo demanda un recurso específico elegido por el atacante, y luego lo encadena con inyección de prompt indirecta para lograr ejecución remota de código y propagar malware de botnet. Los investigadores reportaron tasas de recurso alucinado de hasta el 85% en la clonación de repositorios y del 100% en la instalación de skills, en nueve asistentes que incluyen Cursor, Windsurf, Copilot, Cline y Gemini CLI.

¿Con qué frecuencia se dan las alucinaciones de paquetes de la IA?

Muy comunes. Un estudio de USENIX Security 2025 sobre 2,23 millones de muestras de código generado por IA encontró que el 19,7% referenciaba al menos un paquete alucinado, catalogó 205.474 nombres fabricados únicos y demostró que las alucinaciones son repetibles: el 43% de ellas se repitió en las diez ejecuciones del mismo prompt. Los modelos de código abierto fueron peores (21,7%) que los comerciales (5,2%). La repetibilidad es lo que hace explotable el problema, porque los atacantes pueden predecir y registrar por adelantado los nombres que un modelo favorece.

¿Puede un escáner de SCA o la detección de typosquatting atrapar el slopsquatting?

No de forma fiable, y por dos razones distintas. La detección de typosquatting busca nombres a una pequeña distancia de edición de los paquetes reales, pero un nombre alucinado es fabricado en lugar de una variante casi idéntica, así que no está cerca de nada que el filtro vigile. El análisis de composición de software se ejecuta después de instalar un paquete y busca versiones con vulnerabilidades conocidas, pero un paquete malicioso recién registrado aún no tiene CVE, y su script de instalación ya se ejecutó para cuando el SCA mira. Vale la pena ejecutar ambos como redes de contención; ninguno detiene la instalación en sí.

¿Cómo evito que mi agente de programación con IA instale paquetes alucinados?

No deje que los agentes instalen dependencias sin supervisión, verifique que cualquier paquete nuevo existe de verdad y tiene un historial real antes de añadirlo, acote las instalaciones a un registro privado o a una lista de permitidos y suba lockfiles con hashes de integridad para que las dependencias nuevas sean visibles y revisables. Como estas comprobaciones solo ayudan si algo las hace cumplir antes de que se ejecute el comando de instalación, la solución duradera es la aplicación en tiempo de agente: un control como VibeDefend que intercepta la instalación de un paquete no verificado o inexistente dentro del bucle del agente, en lugar de un escáner que lee el daño después.