Pregúntale a un agente de codificación con IA que obtenga una herramienta. De vez en cuando devuelve un nombre que suena bien pero que no existe. Los desarrolladores solían ignorar este error, asumiendo que un compilador o una prueba lo detendría. Desafortunadamente, esa suposición es peligrosa y errónea.

Efectivamente, ahora estamos dando acceso de root a modelos de lenguaje que a veces adivinan palabras, y los atacantes saben cómo usar eso en nuestra contra.

El ataque funciona así: un atacante puede calcular las URL, nombres de bibliotecas de software y otros resultados que un LLM producirá y que posteriormente podrá acceder. El atacante captura el nombre, luego establece una trampa y espera. No necesitan robar contraseñas, ni enviar correos de phishing, ni que un humano haga clic en un enlace. Solo necesitan que alguien, en algún lugar, dé permiso a un proceso automatizado para obtener algo malicioso.

Investigadores de la Universidad de Tel Aviv, Technion e Intuit publicaron un artículo el 8 de julio de 2026. El equipo, liderado por Aya Spira en el grupo de Ben Nassi, demostró que estos nombres falsos son predecibles.

Probaron múltiples indicaciones en Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI y OpenClaw. Los modelos alucinaron nombres idénticos hasta el 85% de las veces para solicitudes de repositorios. Alucinaron nombres idénticos el 100% de las veces para instalaciones de habilidades.

"Slopsquatting explotó un nombre de paquete falso. Phantom squatting explotó un dominio falso. HalluSquatting explota un repositorio o habilidad falsos", dice Warden. "En cada caso, el agente confía en un nombre que nadie verificó".

Esta vez, la recompensa es una botnet

Esa comparación subestima lo que hay de nuevo aquí. Slopsquatting y phantom squatting consiguen que el código de un atacante llegue a una máquina a la vez. HalluSquatting escala más para los atacantes, porque el agente hace el trabajo de entrega que un operador de botnet solía necesitar comprometiendo máquinas reales.

No hay contraseñas robadas, ni gusanos que se arrastren de dispositivo a dispositivo, ni un solo sistema operativo al que apuntar. Cualquier máquina que ejecute un agente expuesto puede ser un objetivo.

Los investigadores construyeron este ataque específicamente para demostrar que se repite a escala, por lo que tratan sus propios números como un piso más que como un techo: "Los ataques siempre mejoran", escriben. "Nunca empeoran".

Verifica el nombre antes de que tu agente confíe en él

HalluSquatting funciona porque los agentes de codificación con IA obtienen y ejecutan un paquete, repositorio o habilidad alucinado antes de que alguien verifique si es real.

Un catálogo gobernado cierra esa brecha, verificando cada componente antes de que tu agente lo vea.

La tercera vez es un patrón, no una coincidencia

Los equipos de seguridad han visto este fallo tres veces en seis meses.

  • Enero de 2026 (Slopsquatting): Charlie Eriksen de Aikido Security detectó que agentes de IA intentaban instalar un paquete npm falso llamado react-codeshift en 237 proyectos. Registró el nombre para evitar que los atacantes lo tomaran.
  • Junio de 2026 (Phantom Squatting): Unit 42 de Palo Alto Networks encontró 250,000 dominios que los modelos de lenguaje alucinan. Cualquiera podría registrar esos dominios.
  • Julio de 2026 (HalluSquatting): El equipo de investigación de Spira mostró cómo los atacantes pueden tomar el control de agentes de IA reclamando nombres predecibles por adelantado.

Cada ataque se basa en el mismo defecto central. El sistema confía en un nombre que un modelo generó sin verificar si alguien lo validó y lo confirmó.

Fallo del principio de diseño: enlace tardío

Este problema proviene de dos problemas relacionados.

Primero, los modelos de lenguaje generan sus resultados basados en probabilidades. Dadas las entradas correctas, producirán resultados predecibles (no deterministas, por supuesto, pero el documento muestra que son lo suficientemente predecibles como para producir vectores de ataque). Esto me recuerda a las tablas rainbow, donde puedes pre-generar la salida de los hashes de contraseñas.

No tienes que saber la contraseña de alguien si puedes obtener el hash (inseguro) y conoces una entrada que crea ese hash.

Segundo, los desarrolladores construyen y ejecutan código y pipelines que ejecutan comandos basados en la salida generada por estos modelos de lenguaje. A menos que tengas mucho cuidado, tus agentes ejecutarán código u obtendrán datos antes de que tengan la oportunidad de examinar y verificar la fuente de ese código y datos.

En arquitectura de software, este tipo de enlace tardío ofrece flexibilidad. En arquitectura de seguridad, confiar en una fuente de datos externa no verificada crea una vulnerabilidad masiva. El peligro reside en la brecha entre la generación de texto y la ejecución de código. Lo que era seguro y verdadero puede haber cambiado desde la última vez que lo comprobaste ayer (o hace una hora).

Los desarrolladores se apresuran a enviar productos más rápido. Tratan la infraestructura de compilación como herramientas desechables, incluso mientras otorgan a estas herramientas permisos amplios para descargar, cambiar e implementar cosas. Han automatizado el typosquatting y la confusión de dependencias.

Cuando los agentes ahora tienen permiso para obtener y ejecutar código sin suficiente revisión humana, tus riesgos de ataques crecen.

El riesgo se extiende por el árbol de dependencias

El riesgo se extiende más allá de los paquetes de nivel superior. Un agente podría seleccionar un paquete real con un nombre real. Las herramientas de seguridad modernas pueden verificar ese paquete de nivel superior. ¿Sabes que rara vez inspeccionan las dependencias transitivas tres o cuatro niveles más abajo en el árbol?

Los desarrolladores no pueden inspeccionar esas dependencias simplemente leyendo el código fuente de nivel superior o diciendo "Eso se ve correcto" y presionando Enter. Peor aún, si una dependencia está comprometida pero las versiones anteriores estaban bien, las reglas que tenías ayer pueden no protegerte hoy.

Si un atacante puede comprometer una dependencia profunda o cualquier cosa de la que dependa, un pipeline automatizado puede llevar ese compromiso a tus sistemas.

Los respaldos de seguridad tradicionales fallan

Los investigadores señalan que sus hallazgos representan un nivel de riesgo mínimo. Estos ataques serán más rápidos y precisos en su objetivo. Las herramientas de seguridad existentes fallan contra estos patrones de ataque.

En junio de 2026, Trail of Bits eludió los escáneres de tiendas de habilidades de agentes en menos de una hora. Los escáneres examinan las afirmaciones declaradas en lugar de los payloads ocultos.

Los certificados SSL y DNSSEC no detienen esta amenaza. Un atacante que registra un dominio falso puede obtener fácilmente un certificado gratuito de Let's Encrypt. El certificado prueba quién es el propietario del dominio, pero no puede probar que el usuario pretendía conectarse a él o que el dominio es seguro.

DNSSEC evita que otras personas tomen el control de un dominio, pero ¿qué pasa si el dominio se registró ayer porque un atacante predijo que el último modelo enviaría a la gente allí?

Arreglando el pipeline de ingesta

Para asegurar tus sistemas, debes asegurarte de que ninguno de tus pipelines ejecute código o datos no examinados. Esa verificación y validación debe ocurrir automáticamente, a la velocidad de la IA. La revisión humana no puede seguir el ritmo de las herramientas automatizadas de IA.

Los equipos de ingeniería deben abordar este problema directamente. Pueden pasar un tiempo significativo construyendo pipelines de verificación internos, o pueden adoptar una solución de gobernanza existente.

Los equipos que parchean herramientas individuales pasarán años persiguiendo nuevas variaciones de este exploit. Los equipos que corrigen el defecto de diseño subyacente detendrán el ataque antes de que el modelo ejecute un comando no confiable.

Las organizaciones deben resolver las dependencias de código abierto a través de algo como el Catálogo Curado de ActiveState, un repositorio privado y gobernado por políticas de componentes examinados. El catálogo verifica el paquete antes de que el agente lo descargue. Un paquete que falla esta verificación es completamente invisible para el agente, causando un fallo antes de que cualquier código malicioso pueda entrar en tus sistemas.

Esta es una defensa diferente al escaneo. Trail of Bits rompió los escáneres porque los escáneres inspeccionan una carga desconocida en el momento de la obtención, exactamente cuando un atacante ha optimizado el payload para escapar.

El Catálogo Curado elimina ese momento por completo: solo sirve componentes que fueron examinados y verificados antes de que cualquier agente los solicitara, por lo que no hay carga desconocida que sortear. Este único paso convierte una suposición estadística en un recurso confiable o en un fallo deliberado que requiere investigación humana.

Si quieres ver cuántas de las solicitudes actuales de tu equipo pasarían sin verificación hoy, solicita una Evaluación de Riesgo de OSS de ActiveState y descúbrelo antes de que un atacante lo haga.

Preguntas frecuentes

¿Qué es HalluSquatting? HalluSquatting es un ataque donde los investigadores precomputan los nombres falsos de repositorios, paquetes o habilidades que los agentes de codificación con IA inventan predeciblemente, registran esos nombres primero y los cargan con instrucciones maliciosas antes de que el agente de un usuario real vaya a buscarlos.

¿En qué se diferencia de slopsquatting o phantom squatting? Los tres explotan el mismo fallo (un agente que confía en un nombre que nadie verificó), pero apuntan a recursos diferentes. Slopsquatting apunta a nombres de paquetes npm, phantom squatting apunta a dominios web y HalluSquatting apunta a repositorios y habilidades de agentes, ejecutando el payload directamente a través de los permisos de uso de herramientas del propio agente.

¿Pueden los escáneres de seguridad existentes detectar esto? No de forma confiable. Trail of Bits eludió todos los escáneres públicos de tiendas de habilidades que probaron en menos de una hora, porque los escáneres inspeccionan el contenido declarado de una carga desconocida en lugar de su payload oculto. Un escaneo estático posterior al hecho está compitiendo contra un atacante que construyó el payload específicamente para derrotar ese escaneo.

¿Qué deberían hacer los equipos de ingeniería esta semana? Activa la verificación previa a la obtención donde exista; la mayoría de los marcos de agentes la traen desactivada por defecto. Dirige la resolución de dependencias de código abierto a través de un catálogo gobernado y previamente examinado en lugar de permitir que los agentes obtengan directamente de registros públicos.

¿Esto afecta a todos los agentes de codificación con IA por igual? Los investigadores encontraron que los nombres alucinados eran consistentes en herramientas construidas sobre diferentes modelos subyacentes, incluyendo Cursor, Windsurf, GitHub Copilot, Cline, Gemini CLI y OpenClaw. Este es un patrón en cómo se construyen y autorizan los agentes, no un fallo aislado de un proveedor.