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, ha existido durante una década en npm. No es nada nuevo; el registro tiene protecciones para ello.
Entonces llegó la IA y lo cambió todo de nuevo. El slopsquatting es la nueva variante de typosquatting impulsada por la IA. En lugar de apostar por 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 con nosotros, y también los slopsquatters.
En este artículo, analizaremos cómo funciona el slopsquatting, qué están encontrando los investigadores en la práctica actualmente y qué puedes hacer al respecto.
¿Qué es el 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 una IA. Los atacantes que realizan 'squatting' confían en que los asistentes de IA sugieran con confianza nombres de paquetes que no existen, y en que los desarrolladores confíen en que es un paquete real que han solicitado.
Cuando un desarrollador ejecuta la instalación con este nombre de paquete, obtiene el paquete del atacante. El paquete generalmente ejecutará algún script post-instalación que robará cualquier credencial presente en el entorno (claves API, tokens de cloud, tokens de autenticación npm) y las reenviará al atacante.
Mientras que algunos paquetes simplemente incluyen el ataque en un script post-instalación, los paquetes más sofisticados evitan por completo incluir código malicioso en el paquete, utilizando en su lugar el soporte de npm para 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 porque no hay código obviamente malicioso.
Supongamos que le pides a tu IA que instale un paquete linter de JavaScript. Ofrece unused-imports y te pregunta si quieres instalarlo (si no omite la pregunta por completo). Esto suena como el paquete que has usado antes, así 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-unused-imports. Resulta que, unused-imports es un paquete malicioso, ¡y sorpresa! ¡Acabas de instalar malware! (De hecho, este es un real paquete malicioso, por cierto, y potencialmente un ataque intencionado de slopsquatting. Puedes consultarlo en Aikido Intel. npm lo tiene ahora bajo una retención de seguridad).
Los LLM (modelos de lenguaje grandes) en realidad alucinan bastantes nombres de paquetes. Mackenzie Jackson, Developer Advocate 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 estaba atascado, 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 aquí tienes cómo creo que se llamarían los paquetes para esto".
¿En qué se diferencia el slopsquatting del typosquatting?
El typosquatting ocurre cuando un atacante registra un paquete malicioso con un nombre lo suficientemente parecido a un paquete popular como para que un usuario, al escribirlo mal, acceda a él. Los atacantes buscan un paquete con muchas descargas y un nombre fácil de escribir incorrectamente, eliminan un guion, intercambian dos letras, añaden un carácter extra y "ocupan" el paquete mal escrito antes que nadie. El typosquatting ha sido una constante en npm desde al menos 2017, cuando un atacante publicó crossenv, una apropiación del popular cross-env paquete. npm ahora tiene protecciones contra esto, al evitar el registro de nombres de paquetes demasiado similares a los existentes.
El slopsquatting es typosquatting, pero en lugar de apostar por los errores de escritura de un humano, los atacantes apuestan por que una IA se equivoque con confianza. (Sí, así de fiable se considera la IA ahora mismo). La principal diferencia entre el slopsquatting y el typosquatting que hemos tenido en el pasado es que las variantes se ven totalmente diferentes, y con el primero, hay un mayor volumen de nombres entre los que los atacantes pueden 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 en USENIX Security 2025 probaron 16 modelos en 576.000 muestras de código y descubrieron que las alucinaciones siguen patrones predecibles: el 38% son fusiones como express-mongoose, donde el modelo mezcla dos cosas reales, el 13% son variantes tipográficas y el 51% son fabricaciones puras. Eso es un conjunto mucho mayor de nombres "ocupables" de lo que el typosquatting jamás ofreció, y a diferencia del typosquatting, ninguno de estos nuevos nombres tiene nada a lo que ser "similar" en el sistema de protección de npm.
¿Está ocurriendo el slopsquatting ahora?
Creemos que sí. Estamos viendo paquetes de malware cuyos nombres son consistentes con el patrón de slopsquatting, pero no podemos probar cuál es la intención de los atacantes con esos nombres. Tomemos unused-imports, el paquete malicioso confirmado del que hablamos antes. A principios de febrero, todavía registraba 233 descargas a la semana. Esos desarrolladores o bien están siguiendo recomendaciones de IA que aún apuntan a este nombre, o lo tienen en algún lugar de su árbol de dependencias y lo están reinstalando, o lo encontraron 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 de slopsquatting en entornos reales. A principios de 2024, Bar Lanyado, de Lasso Security, observó que los modelos de IA alucinaban repetidamente un paquete de Python llamado huggingface-cli. La herramienta real se instala de forma diferente, como pip install -U "huggingface_hub[cli]", pero los modelos seguían sugiriendo la versión más corta e 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 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 paquete de IA que se propagó por sí sola
Charlie Eriksen, Investigador de Seguridad en Aikido encontró algo aún más sorprendente– un nombre de paquete alucinado que se propagaba a través de infraestructura de IA real, con agentes reales intentando ejecutarlo, y que nadie había plantado deliberadamente. En enero de 2026, Charlie reclamó este paquete npm llamado react-codeshift. El paquete no era real, no tenía autor y definitivamente no se había registrado antes. El nombre es una clásica alucinación por confluencia. Existen dos paquetes reales con nombres similares, jscodeshift y react-codemod, que un LLM combinó para inventar el nombre react-codeshift.
El paquete había hecho su primera aparición en un único commit de 47 Habilidades de Agente generadas por LLM. Podemos suponer que se le pidió a una IA que generara un conjunto de instrucciones para agentes de codificación y, al hacerlo, alucinó nombres de paquetes que necesitaría para llevar a cabo esas tareas. Ningún humano revisó la salida (o al menos no la probó), por lo que esta alucinación de IA fue 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 forks y había sido traducido al japonés. Después de que Charlie lo reclamara, react-codeshift seguía recibiendo un par de descargas diarias. Esos son agentes de IA que siguen instrucciones de habilidades y que activan instalaciones de npx en entornos reales. Si un atacante lo hubiera registrado primero, podría haber habido un ataque de slopsquatting más grande que se hubiera propagado orgánicamente
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 (vimos 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 cabría esperar de un mantenedor legítimo? Un paquete que afirma ser un eslint plugin sin información del mantenedor y con una fecha de registro del martes pasado es una señal de alarma, independientemente de su número de descargas.
Trate la instalación autónoma de paquetes como una operación privilegiada
Si está ejecutando agentes de IA que pueden instalar paquetes sin confirmación, Claude Code en modo bypass, una configuración de codificación agéntica o pipelines de CI con amplios permisos de npm, el paso de verificación que normalmente haría como humano desaparece. El agente simplemente procederá si tiene la autoridad. Ese es el modelo de amenaza en torno al cual se construye el slopsquatting, así que delimite esos permisos en consecuencia.
Escanee su árbol de dependencias completo
Algunos nombres de paquetes "alucinados" están terminando como dependencias anidadas en lugar de instalaciones directas, lo que significa que no aparecerán en su package.json. Un escáner de análisis de composición de software (SCA) examina su árbol de dependencias completo para detectar paquetes maliciosos ocultos o enterrados.
Utilice SafeChain para la protección a nivel de npm
Aikido SafeChain es un wrapper de código abierto para npm, npx, yarn, y pnpm que intercepta los comandos de instalación de paquetes y los verifica contra Aikido Intel antes de que nada llegue a su máquina.
Conclusión
Los nombres de paquetes no reclamados siempre han sido reclamables, pero ahora tenemos IAs que nos dan con confianza nombres de paquetes falsos para instalar y agentes de IA que difunden esos nombres por los repositorios.
A medida que el "vibe coding" se convierte en la norma y más agentes de IA con temática de langosta empiezan a codificar sin humanos alrededor (lea nuestro artículo sobre 'Por qué intentar asegurar OpenClaw es ridículo'), la ventana para que un humano detecte un nombre de paquete malicioso antes de que se ejecute se reduce cada vez más. Hemos visto que los nombres que las LLM "alucinan" son consistentes y repetibles, y los atacantes están aprovechando esto.
Revise sus árboles de dependencias. Verifique los editores. Y utilice una herramienta que se sitúe entre su gestor de paquetes y el registro y realice las comprobaciones por usted.
