El slopsquatting convierte paquetes generados por IA en ataques a la cadena de suministro

El slopsquatting ocurre cuando un atacante registra un nombre de paquete que una herramienta de codificación AI inventó, y luego distribuye malware bajo ese nombre. El desarrollador pide código a un asistente, el asistente recomienda una biblioteca que no existe, y el desarrollador ejecuta el comando de instalación. Si el atacante registró ese nombre primero, el código del atacante ahora está en la máquina del desarrollador.

El nombre combina “slop”, la jerga para salida de IA de baja calidad, con “squatting”, la antigua costumbre de reclamar nombres que no posees. Los equipos de seguridad reconocerán el patrón de typosquatting, donde los atacantes registran errores ortográficos de paquetes populares. Slopsquatting usa nombres que nunca existieron hasta que un modelo los inventó. Ambos son ataques a la cadena de suministro de software y ambos introducen código malicioso en una compilación.

Los modelos de IA inventan nombres de paquetes, y los nombres se repiten

Investigadores de la University of Texas at San Antonio, la University of Oklahoma y Virginia Tech generaron 576,000 muestras de código Python y JavaScript en 16 modelos de lenguaje, y el 19.7% de los paquetes recomendados por esas muestras no existían. Los modelos comerciales tuvieron un promedio de al menos 5.2% de paquetes inventados y los modelos de código abierto un promedio de 21.7%. En todos los modelos, el estudio registró 205,474 nombres únicos inventados.El estudio se presentó en USENIX Security 2025. Probó modelos disponibles a principios de 2024, y los autores señalan que los modelos más nuevos pueden comportarse de manera diferente.

Vuelven los mismos nombres falsos. Cuando los investigadores volvieron a ejecutar 500 indicaciones que habían producido una alucinación, el 43 % de los paquetes inventados aparecieron en las 10 ejecuciones repetidas, y el 58 % apareció más de una vez. Eso le da a un atacante una lista corta y predecible de nombres que vale la pena registrar.

Pocos de los nombres inventados se parecen a los reales. Entre las alucinaciones de Python, solo el 13,4 % estaba a uno o dos caracteres de un paquete real, y el 48,6 % era muy diferente a cualquier nombre real.

Comprobar un nombre sugerido contra una lista de paquetes conocidos no lo resuelve. Un atacante puede haber publicado malware con ese nombre, por lo que el paquete parecerá existir.

Los atacantes registran los nombres y esperan

Un atacante hace preguntas comunes de codificación a modelos populares y anota cada nombre de paquete que no existe. Luego registran esos nombres en registros públicos como npm o PyPI y publican un paquete que hace aproximadamente lo que un desarrollador esperaría, con una carga oculta añadida.

Eventualmente, un desarrollador recibe la misma recomendación y pega el comando de instalación. Instalar un paquete open source de Python o JavaScript puede permitir que su autor ejecute código arbitrario en la máquina, por lo que la carga útil puede activarse durante la instalación, antes de que alguien lea una línea del código del paquete.

Un portátil de desarrollador contiene claves de cloud, tokens de API, claves SSH, código fuente y acceso VPN. Si se compromete uno, el atacante obtiene una base en la cadena de compilación, con una ruta hacia producción detrás.

La codificación Vibe elimina el último punto de control

Programar con Vibe significa aceptar código generado por IA con poca revisión, y la revisión es el único paso que podría detectar un nombre de paquete malicioso. El ataque depende de un usuario que instala paquetes recomendados sin suficiente verificación, confiando en que el modelo solo nombrará paquetes reales. Nadie lee la lista de dependencias, por lo que una biblioteca desconocida se instala sin una segunda revisión. Las personas que crean herramientas internas con un asistente pueden no saber cómo es una biblioteca legítima, por lo que es aún menos probable que lo noten. Las revisiones que solo leen el código generado nunca ven la dependencia, un punto ciego en la seguridad del código IA.

Los endpoints de desarrolladores necesitan sus propios límites

Los controles de pipeline reducen la entrada de paquetes maliciosos. No pueden garantizar cero, y un paquete que pase se ejecuta en el endpoint de un desarrollador.

Netwrix PolicyPak aplica controles de endpoint mediante Group Policy, MDM o su servicio en la nube. PolicyPak elimina los derechos de administrador local y usa reglas de elevación seguras, para que los desarrolladores tengan solo el acceso que las tareas aprobadas requieren. Su lista blanca, basada en la propiedad del archivo, bloquea aplicaciones y scripts no confiables, limitando lo que un paquete malicioso puede hacer al llegar a una máquina.