HalluSquatting: cuando la IA instala malware sin saberlo

El HalluSquatting —también llamado slopsquatting— es un ataque de cadena de suministro en el que un ciberdelincuente registra en npm, PyPI o crates.io un paquete que no existe realmente, pero que los agentes de codificación con IA recomiendan por error al alucinar su nombre. Cuando el agente instala esa dependencia inventada creyendo que es legítima, en realidad descarga el paquete malicioso que el atacante ya había preparado con ese nombre exacto.

El typosquatting lleva años en el radar de cualquier equipo de desarrollo: un atacante registra 'reqeusts' o una variante con guion de más esperando que un humano teclee mal el nombre real. El HalluSquatting invierte la lógica. Aquí no hace falta que nadie se equivoque al escribir: el propio modelo de lenguaje genera un nombre de paquete que suena plausible y coherente con las convenciones del ecosistema, pero que no corresponde a ningún proyecto real. El atacante no necesita adivinar errores tipográficos; le basta con lanzar los mismos prompts que usaría cualquier desarrollador —'librería para validar JWT en Node', 'cliente REST para Stripe en Python'— contra varios modelos, anotar qué nombres inventados se repiten y registrarlos antes de que lo haga nadie más. A partir de ahí, cada vez que un agente de codificación sugiera esa misma dependencia alucinada, instalará silenciosamente el paquete del atacante.

El mecanismo que casi nadie explica: por qué la alucinación no es aleatoria

Es tentador pensar que un nombre de paquete inventado es ruido estadístico, un fallo puntual que cambia cada vez que se relanza el mismo prompt. La investigación académica muestra lo contrario. Un estudio de la Universidad de Texas en San Antonio, Virginia Tech y la Universidad de Oklahoma, presentado en USENIX Security 2025 bajo el título 'We Have a Package for You!', analizó más de 576.000 muestras de código generadas por 16 modelos distintos y confirmó que una parte significativa de los nombres alucinados se repite de forma consistente cuando se relanza el mismo prompt varias veces. Eso convierte la alucinación en un objetivo predecible y rentable para un atacante: no necesita cazar una coincidencia rara, necesita catalogar los nombres que el modelo genera casi siempre para una intención de código concreta.

El code review tradicional está diseñado para detectar lógica incorrecta, no para verificar la existencia de un paquete en un registro público. Un desarrollador que revisa un diff con una línea nueva en package.json o requirements.txt no tiene forma de saber, con solo mirar el nombre, si ese paquete es real, si lleva tres años activo o si se publicó hace dos días con un script de postinstalación que exfiltra variables de entorno. El typosquatting al menos deja una pista visual —una letra de más, un guion cambiado— que un ojo entrenado puede pescar. El HalluSquatting no deja esa pista porque el nombre no imita nada: simplemente suena bien. A esto se suma un problema de configuración muy extendido en equipos pequeños: muchos agentes de codificación se ejecutan en modo de auto-aprobación para acelerar el flujo, lo que significa que comandos como npm install o pip install se lanzan sin que nadie confirme manualmente qué se está instalando.

La buena noticia es que la defensa contra el HalluSquatting no depende de una herramienta cara ni de un equipo de seguridad dedicado: depende de tratar cada dependencia nueva que introduce un agente de IA como si viniera de un proveedor externo sin verificar, no como si fuera código propio. Con un equipo de desarrollo de 5 o 10 personas, unas pocas reglas de proceso cierran la mayor parte del riesgo sin coste de licencia.

• Congela y versiona el lockfile (package-lock.json, poetry.lock, Pipfile.lock) y haz que el pipeline de CI falle si el lockfile cambia sin una revisión explícita.
• Añade un proxy de registro (Verdaccio, Artifactory, o el flag de antigüedad mínima de npm) que bloquee la instalación de paquetes publicados hace pocos días — la mayoría de los paquetes de HalluSquatting se registran ad hoc tras detectar la alucinación.
• Crea una 'cuarentena de primera aparición': cualquier dependencia que no exista ya en el lockfile del repositorio dispara una aprobación manual antes de mergear, aunque el agente de IA la haya instalado sin errores.
• Desactiva la auto-aprobación del agente específicamente para comandos de instalación (npm install, pip install, cargo add), aunque la dejes activa para edición de código.
• Antes de aceptar una dependencia nueva sugerida por IA, comprueba en el registro público la fecha de publicación y el número de descargas — un paquete con días de antigüedad y descargas mínimas es motivo de sospecha, no de confianza automática.

Cuándo sí compensa invertir en SCA dedicado

Aquí conviene ser honestos: no todas las pymes necesitan una plataforma de software composition analysis desde el primer día. Para un equipo pequeño con un repositorio y un proceso de revisión disciplinado, el lockfile más la cuarentena de primera aparición cubren la mayor parte del riesgo real y no cuestan una licencia. La conversación cambia cuando hay varios repositorios y equipos, cuando entra en juego un marco de cumplimiento como el ENS o ISO 27001 que exige trazabilidad de la cadena de suministro de software, o cuando el volumen de dependencias nuevas por semana hace inviable la revisión manual. En Blurtek no recomendamos contratar una herramienta de SCA a un cliente que resolvería el 80% del problema con dos reglas de CI bien puestas; recomendamos escalar la inversión cuando el proceso manual deja de sostenerse.

El patrón que vemos en auditorías de pipelines de desarrollo no es que los equipos ignoren la seguridad de las dependencias — es que confían en un proceso de revisión pensado para errores humanos, aplicado ahora a un tipo de error que solo comete una máquina y que no deja ninguna pista visual.