El typosquatting, que consiste en registrar una versión con errores tipográficos de un paquete popular y esperar a que un desarrollador escriba e instale accidentalmente el paquete equivocado, lleva una década existiendo en npm. No es nada nuevo: el registro cuenta con protecciones para ello.
Entonces llegó la IA y volvió a cambiarlo todo. El slopsquatting es la nueva variante del typosquatting basada en la IA. En lugar de apostar por los errores tipográficos humanos, los atacantes apuestan por las alucinaciones de la IA, los nombres de paquetes que los LLM recomiendan con confianza y que en realidad no existen. Durante un tiempo, esto se consideró un riesgo teórico, pero ya no es así. Las alucinaciones de la IA están entre nosotros, al igual que los slopsquatters.
En este artículo, veremos cómo funciona el slopsquatting, qué están descubriendo los investigadores en la actualidad y qué se puede hacer al respecto.
¿Qué es slopsquatting?
El slopsquatting, también llamado hallucination squatting, es lo que ocurre cuando un atacante registra un nombre de paquete que los modelos de IA tienden a alucinar y luego espera a que los desarrolladores lo instalen por recomendación de la IA. Los atacantes que realizan este tipo de ataques se basan en que los asistentes de IA sugieren con confianza nombres de paquetes que no existen y en que los desarrolladores confían en que se trata de un paquete real que ellos mismos han solicitado.
Cuando un desarrollador ejecuta la instalación de este nombre de paquete, obtiene el paquete del atacante. El paquete generalmente ejecutará algún script posterior a la instalación que roba cualquier credencial que se encuentre en el entorno (claves API, tokens en la nube, tokens de autenticación npm) y las reenvía al atacante.
Mientras que algunos paquetes solo incluyen el ataque en un script posterior a la instalación, los paquetes más sofisticados omiten por completo la inclusión de código malicioso en el paquete y, en su lugar, utilizan la compatibilidad de npm con las dependencias basadas en URL para obtener una carga útil de un servidor externo en el momento de la instalación. El paquete parece limpio para cualquier escáner estático ingenuo, ya que no hay código malicioso evidente.
Supongamos que le pides a tu IA que instale un paquete de linter de JavaScript. Te ofrece importaciones no utilizadas y te pregunta si deseas instalarlo (si no lo hace, simplemente omite preguntarte). Parece ser el paquete que has utilizado anteriormente, por lo que lo instalas.
Claude quiere ejecutar: npm install unused-imports
[y] Aceptar [n] Rechazar [e] Editar [Esc] CancelarSin embargo, el paquete real es eslint-plugin-importaciones-no-utilizadas. Resulta que, importaciones no utilizadas es un paquete malicioso, ¡y sorpresa! ¡Acabas de instalar malware! (En realidad, esto es un real paquete malicioso, por cierto, y potencialmente un ataque intencionado de slopsquatting. Puedes buscarlo en Aikido Intel.. npm lo tiene ahora bajo retención por motivos de seguridad).
Los LLM suelen tener muchas alucinaciones con los nombres de los paquetes. Mackenzie Jackson, promotor de desarrolladores en Aikido Security, describió una alucinación que encontró en un episodio del podcast Secure Disclosure. Le pidió a una IA que le ayudara a conectar su proyecto Node.js a una base de datos OrientDB, una combinación técnicamente factible pero poco común, sin una solución de paquete obvia. En lugar de admitir que no sabía qué hacer, el modelo inventó nombres de paquetes. Mackenzie dice sobre el proceso de pensamiento de la IA: «No tengo nada para ti, pero necesito tener algo para ti, así que esto es lo que creo que se llamarían los paquetes para esto».
¿En qué se diferencia el slopsquatting del typosquatting?
El typosquatting es cuando un atacante registra un paquete malicioso con un nombre lo suficientemente parecido al de un paquete popular como para que un usuario lo escriba mal al acceder a él. Los atacantes buscan un paquete muy descargado con un nombre fácil de escribir mal, eliminan un guion, intercambian dos letras, añaden un carácter extra y se «apoderan» del paquete mal escrito antes de que lo haga nadie más. El typosquatting ha sido una constante en npm desde al menos 2017, cuando un atacante publicó crossenv, una ocupación ilegal del popular entorno cruzado paquete. npm ahora cuenta con protecciones contra esto, ya que impide el registro de nombres de paquetes demasiado similares a los ya existentes.
El slopsquatting es similar al typosquatting, pero en lugar de apostar por los dedos torpes de los humanos, los atacantes apuestan por que la IA se equivoque con seguridad. (Sí, así es como se considera la fiabilidad de la IA en la actualidad). La principal diferencia entre el slopsquatting y el typosquatting que hemos tenido en el pasado es que las variantes son totalmente diferentes y, en el primer caso, los atacantes tienen un mayor volumen de nombres entre los que elegir.
Por ejemplo, el 8,7 % de los nombres de paquetes Python alucinados por la IA resultaron ser paquetes JavaScript válidos. En este caso, el modelo establece la conexión correcta con algo real, pero en el ecosistema equivocado. Un terreno fértil para que los atacantes registren nombres de paquetes de otros ecosistemas.
Investigadores de USENIX Security 2025 probaron 16 modelos en 576 000 muestras de código y descubrió que las alucinaciones siguen patrones predecibles: el 38 % son combinaciones como mongoose-exprés, donde el modelo combina dos cosas reales, el 13 % son variantes tipográficas y el 51 % son inventos puros y simples. Se trata de un conjunto de nombres susceptibles de ser usurpados mucho mayor que el que ofrecía la usurpación tipográfica y, a diferencia de esta, ninguno de estos nuevos nombres tiene nada «similar» en el sistema de protección de npm.
¿Se está produciendo ahora mismo el slopsquatting?
Creemos que sí. Estamos viendo paquetes de malware cuyos nombres coinciden con el patrón de slopsquatting, pero no podemos demostrar qué pretenden los atacantes con esos nombres. Tomemos importaciones no utilizadas, el paquete malicioso confirmado del que hablamos anteriormente. A principios de febrero, seguía registrando 233 descargas a la semana. Esos desarrolladores están siguiendo las recomendaciones de la IA que siguen apuntando a este nombre, lo tienen en algún lugar de su árbol de dependencias y lo están reinstalando, o lo han encontrado en la documentación o en Stack Overflow, que no se han actualizado.
Sin embargo, los investigadores están encontrando y demostrando los primeros precursores del slopsquatting en la vida real. A principios de 2024, Bar Lanyado, de Lasso Security, observó que los modelos de IA alucinaban repetidamente con un paquete de Python. llamado huggingface-cli. La herramienta real se instala de forma diferente, ya que pip install -U "huggingface_hub[cli]", pero los modelos seguían sugiriendo la versión más corta, inexistente. Lanyado subió un paquete vacío con ese nombre a PyPI para ver qué pasaba.
huggingface-cli obtuvo más de 30 000 descargas auténticas en tres meses. Alibaba había copiado y pegado el comando de instalación alucinado en el archivo README de uno de sus repositorios públicos. El paquete era inofensivo, pero Lanyado demostró que esta estrategia funciona. Alibaba tuvo suerte de que Lanyado lo descubriera antes que un atacante.
Una alucinación de un paquete de IA que se propagó por sí sola.
Charlie Eriksen, investigador de seguridad en Aikido encontré algo aún más salvaje– un nombre de paquete alucinado que se propagaba por la infraestructura real de IA, con agentes reales que intentaban ejecutarlo, y que nadie había plantado deliberadamente. En enero de 2026, Charlie afirmó que este paquete npm llamado react-codeshift. El paquete no era real, no tenía autor y, sin duda, no se había registrado antes. El nombre es un clásico alucinación por confusión. Existen dos paquetes reales con nombres similares, jscodeshift y react-codemod, que un LLM mezcló para inventar el nombre. react-codeshift.
El paquete había aparecido por primera vez en una única confirmación de 47 habilidades de agente generadas por LLM. Podemos suponer que se pidió a una IA que generara un conjunto de instrucciones para el agente de codificación y, al hacerlo, inventó nombres de paquetes que necesitaría para llevar a cabo esas tareas. Ningún humano revisó el resultado (o al menos no lo probó), por lo que esta invención de la IA quedó inmortalizada a través de GitHub.
Para cuando Charlie lo encontró como parte de su investigación sobre paquetes no reclamados, el nombre de este paquete inexistente se había extendido a 237 repositorios a través de bifurcaciones y se había traducido al japonés. Después de que Charlie lo reclamara, react-codeshift seguía recibiendo un par de descargas diarias. Se trata de agentes de IA que siguen instrucciones de habilidades y activan instalaciones npx en entornos reales. Si un atacante lo hubiera registrado primero, podría haberse producido un ataque de slopsquatting más amplio que se hubiera propagado de forma orgánica.
Cómo protegerse contra los ataques de slopsquatting
Verifique el editor, no solo el nombre.
La respuesta obvia es verificar los nombres de los paquetes antes de instalarlos, pero en realidad no es tan sencillo. El número de descargas no es una señal fiable (hemos visto que los paquetes maliciosos siguen teniendo descargas diarias regulares). Lo que realmente importa es el editor: ¿quién registró este paquete, cuándo y coincide eso con lo que se esperaría de un mantenedor legítimo? Un paquete que dice ser un eslint Un complemento sin información sobre su mantenedor y con fecha de registro del martes pasado es una señal de alerta, independientemente del número de descargas que tenga.
Trate la instalación autónoma de paquetes como una operación privilegiada.
Si estás ejecutando agentes de IA que pueden instalar paquetes sin confirmación, Claude Code en modo de omisión, una configuración de codificación de agentes o canalizaciones de CI con amplios permisos npm, el paso de verificación que normalmente harías como humano desaparece. El agente simplemente continuará si tiene la autoridad. Ese es el modelo de amenaza en el que se basa el slopsquatting, así que delimita esos permisos en consecuencia.
Escanee todo su árbol de dependencias.
Algunos nombres de paquetes alucinados terminan como dependencias anidadas en lugar de instalaciones directas, lo que significa que no aparecerán en tu package.json. Un escáner análisis de composición de software SCA) examina todo tu árbol de dependencias para detectar paquetes maliciosos ocultos y enterrados.
Utiliza SafeChain para obtener protección a nivel de npm.
Aikido SafeChain es un envoltorio de código abierto para npm, npx, hilo, y pnpm que intercepta los comandos de instalación de paquetes y los compara con Aikido Intel antes de que nada llegue a tu máquina.
Conclusión
Los nombres de paquetes no reclamados siempre han sido reclamables, pero ahora contamos con IA que nos proporcionan con confianza nombres de paquetes falsos para instalar y agentes de IA que difunden los nombres por los repositorios.
A medida que la codificación por vibración se convierte en la norma y más agentes de IA con temática de langosta comienzan a codificar sin humanos alrededor (lea nuestro artículo sobre «Por qué es ridículo intentar proteger OpenClaw»), la ventana para que un humano detecte un nombre de paquete incorrecto antes de que se ejecute se reduce cada vez más. Hemos visto que los nombres que alucinan los LLM son consistentes y repetibles, y los atacantes se están dando cuenta.
Comprueba tus árboles de dependencias. Verifica los editores. Y utiliza una herramienta que se sitúe entre tu gestor de paquetes y el registro y realice la comprobación por ti.
