La próxima vez que un asistente de IA recomiende instalar un paquete, ¿verificará si realmente existe? La mayoría de los desarrolladores no lo hacen. Esa brecha entre la sugerencia y la verificación es donde comienzan los ataques de slopsquatting, y en menos de tres años, la amenaza ha evolucionado desde una prueba de concepto de un investigador hasta la ejecución remota de código dentro de agentes de codificación autónomos. Este artículo analiza la evolución del slopsquatting y lo que cada etapa significa para los equipos de seguridad de aplicaciones y DevSecOps.
¿Eres nuevo aquí? Empieza con nuestra introducción a Qué es el slopsquatting y cómo defenderse de él., luego regresa para ver la cronología.
Un ataque de ocupación ilegal en un párrafo
Un ataque de slopsquating Registra un paquete malicioso bajo un nombre que los modelos de IA previsiblemente generan por alucinaciones. Donde el typosquatting explota un error tipográfico humano solicitudes por la solicitudes El slopsquatting explota el propio modelo inventando un nombre plausible que no existe en ningún registro, para luego ser reclamado por un atacante antes de que lo haga cualquier persona legítima. El término fue acuñado por Seth Larson, desarrollador de seguridad residente en la Python Software Foundation, y popularizado por Andrew Nesbitt. Lo que hace que valga la pena seguir de cerca este patrón es la rapidez con la que ha evolucionado.
Evolución del slopsquating
2023: la primera señal de alerta
El investigador de seguridad Bar Lanyado notó que varios LLM seguían recomendando un paquete llamado Huggingface-cli, que no existe (la herramienta real se instala con pip install -U “huggingface_hub[cli]”Para demostrar el riesgo, subió un paquete vacío con ese nombre ficticio. En tres meses, se había descargado más de 30 000 veces, sin ninguna promoción, e incluso el nombre falso apareció en el archivo README de un repositorio vinculado a una investigación de una importante empresa tecnológica. El paquete era inofensivo. La lección no lo fue: basta con que un nombre ficticio sea lo suficientemente consistente para que alguien lo utilice como arma.
2024: de publicación de blog a cobertura generalista
En marzo de 2024, The Register informó sobre modelos de IA que inventaban con seguridad nombres de paquetes de software que los desarrolladores luego descargaban, algunos potencialmente infectados con malware. La cobertura tuvo menos importancia por lo que reveló técnicamente que por lo que indicaba: Huggingface-cli Ya no se trataba de una curiosidad aislada, sino del primer indicio de un patrón lo suficientemente serio como para que la prensa tecnológica generalista lo señalara, antes del estudio a gran escala que confirmaría su alcance un año después.
2025: la primera medición rigurosa
El artículo de USENIX Security 2025 titulado “¡Tenemos un paquete para ti!” (Spracklen et al.) probó 16 modelos de generación de código, tanto comerciales como de código abierto, en 576,000 muestras de Python y JavaScript. Transformó el problema del slopsquatting de una anécdota a datos concretos.
- El 19.7% de los paquetes recomendados no existían.
- Los modelos de código abierto presentaban alucinaciones con mucha más frecuencia (un 21.7% de media) que los comerciales (un 5.2%).
- Los peores infractores, CodeLlama 7B y 34B, presentaban alucinaciones en más de un tercio de sus producciones.
- En todos los modelos, los investigadores registraron más de 205,000 nombres inventados únicos, una cantidad lo suficientemente grande como para alimentar campañas sostenidas en diversos ecosistemas.
El estudio también clasificó cómo se forman las falsificaciones: el 38% eran fusiones que combinan dos nombres de paquetes reales (exactamente el patrón que luego produjo react-codeshift desde jscodeshift y react-codemodEl 13% eran variantes tipográficas de paquetes reales, y el 51% eran invenciones puras, plausibles pero totalmente inventadas. Este primer grupo es el más importante para la defensa, ya que un nombre compuesto a partir de dos herramientas reales es el más difícil de detectar a simple vista.
El hallazgo más importante para los atacantes es que las alucinaciones no son aleatorias ni cambian en cada intento. Cuando los investigadores repitieron las mismas indicaciones diez veces, el 43 % de los nombres alucinados aparecieron en todas las ejecuciones y el 58 % se repitieron más de una vez. Un atacante no necesita adivinar. Observa el comportamiento del modelo, anota los nombres que se repiten y los registra primero. Esa repetibilidad es lo que convierte una alucinación aislada en un ataque escalable.
2026: de paquetes aislados a agentes autónomos
Este año se ha producido la evidencia más clara hasta el momento de que la ocupación ilegal de terrenos ya no se limita a que un promotor inmobiliario copie y pegue una sugerencia. npm instalar.
En enero de 2026, el investigador de seguridad Charlie Eriksen encontró un paquete npm alucinado, react-codeshift, que las instrucciones del agente generadas por IA ya se habían extendido por 237 repositorios a través de bifurcaciones, y los agentes seguían intentando instalarlo diariamente. Se originó en un único commit de archivos de habilidades de agentes escritos por IA que ningún humano había revisado. Eriksen registró el nombre él mismo, de forma defensiva, antes de que un atacante pudiera usarlo como arma.
Por otra parte, un paquete genuinamente malicioso llamado importaciones no utilizadas, alucinado en lugar de lo legítimo eslint-plugin-importaciones-no-usadas, siguió generando instalaciones incluso después de que npm lo pusiera bajo una retención de seguridad, lo que demuestra cuánto tiempo puede un ataque de slopsquatting seguir encontrando víctimas después de haber sido marcado.
En julio de 2026, investigadores describieron una técnica relacionada, denominada "HalluSquatting", que combina una alucinación con una inyección de código: un agente de codificación de IA que busca un recurso alucinado en nombre del usuario puede ser manipulado para ejecutar código proporcionado por el atacante. Esto transforma la técnica de "slopsquatting", pasando de ser un riesgo de instalación pasiva a un vector activo de ejecución remota de código dentro de los flujos de trabajo de desarrollo basados en agentes.
Por qué la "codificación de vibraciones" amplió la superficie de ataque.
El slopsquatting no importaría mucho si el código generado por IA fuera un nicho. Pero no lo es. El auge de los asistentes de codificación, los agentes autónomos y los flujos de trabajo de "codificación intuitiva", donde los desarrolladores revisan menos el código antes de ejecutarlo, ha modificado la superficie de ataque de dos maneras concretas.
En primer lugar, el punto de entrada ya no es solo el desarrollador. Un ataque de typosquatting dependía de que una persona cometiera un error tipográfico. Ahora, el error se origina dentro del modelo y se propaga a cientos de desarrolladores que hacen preguntas similares y reciben la misma recomendación errónea.
En segundo lugar, la superficie de ataque se desplazó hacia arriba en la cadena. Ya no basta con supervisar el código que escribe un humano. Los equipos deben supervisar las dependencias que sugiere un asistente de IA, los servidores MCP a los que se conecta y los agentes que instalan paquetes sin intervención humana. La seguridad de aplicaciones tradicional, diseñada para revisar repositorios y código humano, commits, nunca fue diseñado para observar esa interacción entre desarrollador, IA y registro, que es precisamente donde ahora se esconde el slopsquating.
¿Qué significa esto para la prevención?
Nada de esto hace que la IA generativa sea inherentemente insegura. Introduce un riesgo en la cadena de suministro que las herramientas tradicionales no fueron diseñadas para detectar, y requiere los principios de verificación que ya aplicamos a cualquier dependencia externa: no confiar por defecto, verificar la fuente y automatizar esa verificación en lugar de depender de la memoria de cada desarrollador. El manual de defensa completo se encuentra en nuestra guía para Seguridad de la cadena de suministro mediante IAPero, en resumen, la verificación manual, si bien sigue siendo necesaria, deja de ser viable en el momento en que un nombre inventado puede llegar a miles de desarrolladores a la vez, o un agente puede instalarlo sin ninguna revisión humana.
Detén los paquetes alucinantes antes de que un agente los instale.
Los casos de 2026 comparten una característica: la instalación peligrosa se realiza sin intervención humana. Esa es la brecha exacta. xygeni Shield Está diseñado para. Shield es un agente ligero en el punto final del desarrollador que bloquea paquetes maliciosos en el momento de la instalación, utilizando Alerta temprana de malware (MEW) veredictos que funcionan antes de que exista cualquier firma. Cuando un asistente de IA o un agente autónomo intenta instalar un paquete recién registrado y alucinado, Shield lo evalúa a medida que se obtiene y lo bloquea, por lo que el script de instalación nunca se ejecuta, independientemente de si un humano lo estaba observando o no. Cada bloque fluye hacia el mismo xygeni consola como su código, compilación y hallazgos de tiempo de ejecución, y Shield Funciona en paralelo con su sistema EDR existente, en lugar de oponerse a él.
Empieza gratis. El plan para desarrolladores de Xygeni cuesta 0 €: 10 repositorios, 200 escaneos al mes, hasta 5 colaboradores, sin necesidad de tarjeta de crédito. Sign up with GitHub, GitLab o Google y ejecuta tu primer escaneo en menos de 10 minutos; Shield La protección de endpoints estará disponible próximamente en el plan para desarrolladores.
Preguntas Frecuentes
¿Puede un gestor de paquetes prevenir el slopsquating por sí solo?
No del todo. La detección de colisiones de npm bloquea los nombres demasiado similares a los de paquetes existentes, lo que ayuda a prevenir el typosquatting, pero un nombre ficticio es una cadena completamente nueva sin colisión que detectar. Si un atacante registra el paquete ficticio antes de que un desarrollador lo instale, la instalación se completa sin errores porque el paquete existe realmente. La prevención requiere verificar el origen y el comportamiento del paquete, no solo las comprobaciones del registro.
¿Qué diferencia los casos de agentes de 2026 de los casos anteriores de ocupación ilegal de terrenos?
Los incidentes anteriores dependían de que un humano copiara y pegara un comando de instalación sugerido. En los casos de 2026, los agentes autónomos instalaron o intentaron instalar paquetes ficticios sin que ningún humano revisara el paso, y la técnica HalluSquatting fue más allá al encadenar una alucinación con una inyección de mensajes para lograr la ejecución remota de código dentro del flujo de trabajo del agente.
