Alucinaciones que infectan: el slopsquatting y los nuevos ataques a la cadena de suministro en la era de los agentes de IA

Introducción

La integración de los agentes de programación basados en grandes modelos de lenguaje (LLM) ha alcanzado un punto de no retorno: herramientas como GitHub Copilot, Cursor o Gemini CLI escriben, instalan dependencias e incluso ejecutan comandos de forma autónoma. Precisamente esta autonomía esconde una vulnerabilidad sistémica que tres campañas recientes – denominadas Slopsquatting, Phantom Squatting y HalluSquatting – han sacado a la luz. El mecanismo es tan simple como devastador: los modelos “alucinan” identificadores (nombres de paquetes, dominios, repositorios) y, si un atacante los ha registrado por adelantado, el agente ejecuta código malicioso sin interacción humana alguna. Nada de phishing, nada de robo de credenciales: basta con la previsibilidad estadística de las alucinaciones.

Análisis técnico

Un equipo de investigación liderado por Ben Nassi (Universidad de Tel Aviv, Technion, Intuit) ha demostrado cuantitativamente el problema: las solicitudes de repositorios generadas por LLM pueden adivinarse hasta en un 85% de los casos, mientras que para las instalaciones de habilidades (skills) se alcanza el 100%. Esto significa que un atacante puede anticipar los nombres inexistentes que un Copilot o un Cline intentarán utilizar, registrarlos y poblarlos con cargas maliciosas. Los tres ataques explotan el mismo principio, aplicándolo en superficies diferentes:

• Slopsquatting (enero de 2026): el agente sugiere un paquete inexistente para resolver una solicitud; el nombre es tan “típico” que el atacante ya lo ha publicado en un registro público (por ejemplo, PyPI, npm) con malware en su interior.
• Phantom Squatting (junio de 2026): la predicción se refiere a dominios o endpoints de API alucinados; el agente los contacta, descarga scripts y los ejecuta, convencido de que son legítimos.
• HalluSquatting (julio de 2026): compromete la instalación de “skills” o extensiones que la IA considera útiles para completar la tarea; también aquí los nombres son precalculables y están listos para alojar código hostil.

En todos los casos, la confianza implícita en el modelo convierte una alucinación en un vector de ataque determinista. Y dado que los agentes suelen operar con permisos elevados y dentro de canalizaciones CI/CD, el daño se propaga en profundidad. La investigación ha detectado que las herramientas de seguridad tradicionales – antivirus, escáneres de dependencias, firmas digitales – no interceptan la amenaza: no hay un único archivo infectado que localizar, sino un flujo de trabajo que integra dinámicamente código de fuentes no verificadas, posiblemente incluso a través de dependencias transitivas de paquetes aparentemente inofensivos.

Impacto

La gravedad es alta, y los investigadores advierten que lo observado representa el nivel mínimo de riesgo. La previsibilidad de las alucinaciones permite construir cadenas de infección completamente automatizadas: registrar nombres futuros, esperar a que un agente los enganche y obtener ejecución remota de código sin necesidad de convencer a una víctima humana. Las consecuencias inmediatas incluyen:

• Compromiso de entornos de desarrollo, máquinas locales y servidores de CI/CD, con acceso a secretos, código fuente e infraestructuras de producción.
• Creación de botnets silenciosas, donde miles de agentes de IA actúan como nodos sin los vectores de propagación clásicos.
• Contaminación en cascada en las cadenas de suministro de software: un componente malicioso introducido por una alucinación puede ser heredado por todos los proyectos que dependen de esa build, anulando las políticas de control estático.
• Dificultad de detección y atribución, porque el evento malicioso se confunde con el comportamiento normal del agente y no deja rastros de exploits tradicionales.

Mitigación

Defenderse requiere un cambio de paradigma: ya no se puede confiar ciegamente en las sugerencias automáticas, ni limitarse a escanear los paquetes ya instalados. Las contramedidas propuestas por investigadores y empresas como ActiveState incluyen:

1. Verificación preventiva de los identificadores – Antes de instalar, clonar o ejecutar cualquier recurso indicado por un LLM, es necesario verificar su existencia real y su autoría. Las consultas a los registros oficiales, las comprobaciones de propiedad de los dominios y la reputación de los repositorios deben convertirse en operaciones estándar.
2. Gobernanza “en origen” de la cadena de suministro – Integrar controles que validen todo lo que entra en la build antes de los escaneos de seguridad, desplazando el foco de la detección posterior a la prevención.
3. Limitación de los privilegios de los agentes de IA – Ejecutar los agentes en sandbox con permisos mínimos, prohibir el acceso directo a sistemas críticos e introducir una autorización humana obligatoria para cada acción que implique la descarga y ejecución de código.
4. Inspección de todo el árbol de dependencias – A menudo el código malicioso procede de dependencias transitivas no monitorizadas. Es necesario analizar cada rama del árbol, no solo el primer nivel, y vigilar a lo largo del tiempo las modificaciones sospechosas.
5. Vinculación anticipada (Binding) – Reducir al mínimo la resolución tardía de los identificadores generados por la IA. Siempre que sea posible, utilizar nombres autorizados explícitamente y verificados antes de la ejecución, bloqueando cualquier intento de búsqueda dinámica no prevista.
6. Monitoreo predictivo – Construir listas de nombres que los propios modelos tienden a alucinar en contextos específicos. Estos nombres pueden ser pre-registrados en un registro interno ficticio para interceptar intentos de ejecución, o añadidos a listas negras para impedir solicitudes externas.

FAQ

1. ¿Qué es exactamente el slopsquatting y en qué se diferencia del typosquatting tradicional?
El slopsquatting explota las alucinaciones de los modelos lingüísticos en lugar de los errores tipográficos. En el typosquatting, el atacante registra un nombre similar a uno legítimo (por ejemplo, “googel.com”) con la esperanza de un error humano; en el slopsquatting, el nombre es totalmente inventado por el modelo pero estadísticamente probable, y el atacante lo registra antes de que el agente lo busque, logrando la ejecución sin error humano alguno.

2. ¿Cuáles son los primeros signos que una organización debería monitorear para detectar un ataque de este tipo?
Hay que prestar atención a las solicitudes a dominios o registros de paquetes de nombres inexistentes generadas por herramientas de IA; un pico de intentos hacia recursos alucinados puede indicar que un agente está ejecutando código no autorizado. También las modificaciones anómalas en las dependencias transitivas o la ejecución de scripts desde fuentes desconocidas representan señales de alarma.

3. ¿Basta con desactivar la ejecución automática para estar a salvo?
No, porque el slopsquatting y sus variantes se basan en la capacidad de la IA de convencer al usuario (o a un sistema automatizado) para que integre el recurso malicioso. Incluso con un control humano, si el nombre sugerido no se verifica manualmente contra registros oficiales, un paquete “alucinado” puede ser instalado voluntariamente. La mitigación más eficaz es la verificación preventiva de cada identificador, independientemente de quién pulse el botón de ejecución.