HalluSquatting: Cómo una alucinación de IA puede convertir agentes de código en una botnet

Resumen: HalluSquatting convierte en arma un fallo conocido de la IA: inventar un nombre que parece real. Un atacante registra el nombre de un repositorio o una skill que un LLM probablemente alucinará, introduce instrucciones hostiles y espera a que un agente de IA lo descargue. Los investigadores demostraron la cadena en nueve herramientas agénticas, incluidos conocidos asistentes de programación. No hay evidencia pública de explotación real, pero los desarrolladores deberían verificar cada repositorio y skill antes de que un agente los descargue o ejecute.

El peligroso salto de una “respuesta incorrecta” a una “acción incorrecta”

Que un chatbot invente el título de un libro es molesto. Que un agente de programación invente una dirección de GitHub es distinto: el agente puede tener terminal, acceso a internet, credenciales locales y permiso para ejecutar lo que descargue.

Esa diferencia es la base de HalluSquatting, abreviatura de adversarial hallucination squatting. En un trabajo publicado el 8 de julio de 2026, investigadores de la Universidad de Tel Aviv, Technion e Intuit mostraron cómo las alucinaciones predecibles de nombres de repositorios y skills pueden convertirse en un canal escalable para distribuir instrucciones maliciosas. Leer el estudio de HalluSquatting en arXiv

El atacante no necesita escribir a una víctima concreta, comprometer un proyecto famoso ni saber qué desarrollador caerá. Registra un recurso falso que muchos modelos probablemente inventarán y espera a que los agentes lleguen hasta él.

Eso hace que la investigación sea tan oportuna. Durante años, la industria trató las alucinaciones como un problema de calidad. Cuando los modelos pueden clonar repositorios, instalar skills y ejecutar comandos, el mismo error se convierte en un fallo de seguridad.

HalluSquatting en términos sencillos

Imagina que una nueva herramienta open source se vuelve popular. Un desarrollador le pide a un agente:

Clona el repositorio de PopularTool y configúralo.

El modelo reconoce el nombre, pero no conoce de forma fiable el propietario y la URL exacta. En vez de buscar y confirmar la ubicación oficial, construye una dirección plausible:

github.com/propietario-plausible/popular-tool

La dirección parece correcta, pero no lo es. Un atacante ya ha medido qué dirección incorrecta tienden a generar los modelos, la ha registrado y ha colocado instrucciones de prompt injection en el README o en la configuración del agente.

Cuando el agente clona y lee el repositorio, el texto hostil entra en su contexto. Si considera fiables esas instrucciones externas y dispone de herramientas potentes, puede ejecutar comandos del atacante o exponer datos.

La investigación aplica la misma idea a las skills de agentes. El usuario pide instalar una skill; el modelo adivina un identificador inexistente del marketplace; el atacante controla ese identificador; el asistente descarga la skill envenenada.

El error del modelo se convierte en el sistema de distribución del atacante.

La cadena de ataque en siete pasos

1. Encontrar un objetivo popular. El atacante observa repositorios, herramientas y skills que los usuarios probablemente pedirán.
2. Mapear alucinaciones predecibles. Pregunta repetidamente a los modelos por la ubicación y registra los nombres incorrectos más frecuentes.
3. Registrar el mejor candidato. Reclama un nombre de repositorio o skill que todavía esté disponible.
4. Esperar una petición normal. Un desarrollador pide al agente clonar o instalar el recurso real.
5. Dejar que el modelo adivine. En vez de resolver el nombre con una búsqueda o registro fiable, genera el identificador del atacante.
6. Envenenar el contexto. El agente descarga el recurso falso y lee las instrucciones maliciosas incluidas.
7. Abusar de las herramientas. Las instrucciones intentan activar comandos, acceso a datos, robo de credenciales, persistencia o incorporación a una botnet.

Es un ataque no dirigido y basado en pull. El atacante publica una trampa y agentes sin relación entre sí pueden llevarla a muchos entornos.

Qué encontraron realmente los investigadores

Las cifras llaman la atención, pero necesitan contexto.

En sus experimentos, los recursos alucinados aparecieron con tasas de hasta el 85 % al clonar repositorios y hasta el 100 % al instalar skills. Los recursos recientes eran especialmente difíciles porque los modelos tenían menos información fiable sobre su ubicación canónica.

El equipo probó Cursor, Cursor CLI, Windsurf, GitHub Copilot y Cline, además de Gemini CLI y los asistentes OpenClaw, ZeroClaw y NanoClaw. Según el producto, modelo, versión y escenario, los experimentos lograron invocación de herramientas o ejecución remota de código. Los investigadores informan de tasas de RCE de entre el 20 % y el 65 % en los escenarios de agentes de código y de entre el 40 % y el 100 % en los escenarios de asistentes personales evaluados. Ver la página del proyecto y su metodología

Esto no significa que cualquier instalación actual de esos productos esté comprometida automáticamente. El estudio probó versiones concretas, prompts controlados y muestras pequeñas por configuración. Los proveedores y responsables de marketplaces fueron avisados antes de la publicación, se ocultaron detalles directamente reutilizables y el comportamiento de los productos puede haber cambiado.

También se trata de una técnica demostrada, no de una campaña masiva confirmada. Al publicar este artículo, los investigadores no habían presentado pruebas de una botnet real creada con HalluSquatting.

La conclusión defendible es más estrecha y sigue siendo importante: agentes de varias arquitecturas descargaron recursos alucinados bajo control del atacante, y algunos siguieron sus instrucciones hasta ejecutar código.

HalluSquatting no es simplemente slopsquatting con otro nombre

Los términos se solapan, pero el objetivo y la ejecución cambian.

El slopsquatting suele comprometer la cadena de suministro mediante una dependencia falsa. HalluSquatting ataca al agente en vivo durante la inferencia. El recurso hostil ni siquiera necesita un binario malicioso tradicional: las instrucciones en lenguaje natural pueden ser el payload porque el agente es lector y ejecutor.

Además, HalluSquatting complementa al prompt injection. Resuelve el problema de distribución: cómo introducir contenido envenenado en muchos agentes sin contactar con cada víctima.

Qué deberían hacer hoy los desarrolladores

1. No permitas que el modelo invente una URL de clonación

Abre el sitio oficial del proyecto o la página de su organización verificada y copia la URL desde allí. La propia guía de GitHub recomienda copiar la URL desde la página del repositorio en vez de reconstruirla de memoria. GitHub: solucionar errores de clonación

En una copia existente, inspecciona el origen antes de pedir al agente que ejecute la instalación:

git remote get-url origin
git log -1 --format='%h %ad %an %s' --date=short

Comprueba el propietario, el historial, los enlaces de versiones y si el dominio oficial referencia ese repositorio. Las estrellas y un README familiar son señales débiles: se pueden copiar o manipular.

2. Trata las skills como dependencias ejecutables

Una skill no es solo una plantilla de prompt. Puede dirigir comandos, llamadas a herramientas, peticiones de red y acceso a archivos. Instálala únicamente desde un marketplace canónico o un enlace publicado por el mantenedor y revisa sus instrucciones antes de activarla.

No apruebes una skill porque su nombre “parece suficientemente cercano”. Esa similitud es precisamente lo que explota el ataque.

3. Separa el descubrimiento de la ejecución

Pide al agente que primero encuentre y muestre el recurso canónico. Verifícalo tú. Después autoriza por separado la clonación o instalación.

Un flujo seguro tiene una frontera visible:

Buscar → mostrar fuente y propietario → verificar → descargar → inspeccionar → ejecutar

Evita órdenes como “encuéntralo, instálalo y sigue todas las instrucciones” cuando no conoces la fuente.

4. Aísla las instalaciones no confiables

Ejecuta repositorios y skills desconocidos en un contenedor desechable, una máquina virtual, un entorno remoto o un sandbox limitado. Elimina de ese entorno credenciales de producción, claves SSH personales, tokens cloud, claves de firma y variables sensibles.

Restringe la salida a internet cuando sea posible. Un recurso envenenado pierde poder si el agente no puede contactar hosts arbitrarios ni enviar secretos.

5. Exige aprobación para herramientas de alto impacto

Clonar no es el riesgo final; lo importante ocurre después. Exige aprobación explícita para comandos de shell, instalación de paquetes, acceso a credenciales, escrituras fuera del workspace y conexiones a dominios nuevos.

OWASP recomienda mínimo privilegio, aprobación humana para acciones de riesgo y separar el contenido externo no confiable de las instrucciones fiables como defensas básicas contra prompt injection. OWASP LLM01: Prompt Injection

6. Verifica la procedencia de paquetes cuando esté disponible

En npm, la procedencia puede vincular un paquete con su repositorio y workflow de compilación. No demuestra que el código sea inocuo, pero aporta evidencia sobre su origen. El CLI de npm puede verificar firmas y attestations:

npm audit signatures

Documentación de npm sobre procedencia de paquetes

Qué deben cambiar los creadores de agentes y marketplaces

La cautela individual no resuelve por sí sola un problema de plataforma. Los sistemas agénticos deberían:

• Resolver repositorios y skills mediante APIs de búsqueda autorizadas, no generando URLs libremente.
• Negarse a descargar un recurso cuya identidad o propiedad no pueda verificarse.
• Marcar todo contenido descargado como datos no confiables, nunca como instrucciones prioritarias.
• Mostrar propietario, URL, antigüedad y efectos de las herramientas antes de pedir aprobación.
• Separar descarga, lectura y ejecución en pasos autorizados de forma independiente.
• Ejecutar skills externas con privilegio mínimo, credenciales limitadas y allowlists de red.
• Detectar recursos recientes con nombres parecidos alrededor de proyectos populares.
• Conservar registros que conecten la petición, el recurso resuelto, el contenido, la aprobación y las llamadas realizadas.

La regla esencial es sencilla: un modelo de lenguaje no debe ser la fuente de verdad sobre la identidad de un recurso.

La lección de fondo: el grounding ya es un control de seguridad

En un chatbot, el grounding mejora la exactitud. En un agente, decide qué código entra en tu máquina y qué instrucciones obtienen autoridad.

HalluSquatting funciona cuando coinciden tres debilidades:

1. El modelo inventa un identificador plausible.
2. La aplicación lo descarga sin verificarlo con una fuente autorizada.
3. El agente trata el texto descargado como instrucciones y tiene poder suficiente para actuar.

Romper cualquiera de esos enlaces reduce el riesgo. Romper los tres—resolución verificada, fronteras para contenido no confiable y ejecución con mínimo privilegio—es la respuesta duradera.

Los agentes de IA son cada vez más rápidos y autónomos. Por eso, “creo que este es el repositorio correcto” ya no es una decisión de seguridad aceptable. Antes de descargar código, instalar una skill o seguir un README, la identidad debe verificarse con algo más fiable que la predicción del siguiente token.