Slopsquatting: cuando la IA inventa un paquete

La medición

La investigación de referencia sobre el tema recibió una distinción destacada en una conferencia de seguridad de 2025, y su muestra es lo bastante grande como para tomársela en serio.

576.000 muestras de código generadas, 16 modelos, dos lenguajes, treinta pruebas distintas. De ahí salieron en total 2,23 millones de referencias a paquetes, y de ellas 440.445, o sea el 19,7 %, apuntaban a un paquete que no existe. El número de nombres inventados únicos: 205.474.

El desglose te dice dónde está el riesgo:

Entre los modelos cerrados y los de pesos abiertos la diferencia es de cuatro veces. Una réplica más reciente, de 2026, sobre cinco modelos nuevos, comprimió esa dispersión en un orden de magnitud — entre el 4,62 % y el 6,10 % —, pero no hizo desaparecer el fenómeno.

La repetición que convierte esto en un ataque

Esta es la cifra más importante del artículo, y se cae de casi todos los resúmenes.

Los investigadores eligieron al azar 500 prompts que habían provocado una alucinacióny volvieron a ejecutar cada uno diez veces. Las tres proporciones de abajo salen de cortes distintos del estudio, y por eso no suman exactamente cien.

• El 43 % de los nombres inventados volvió en las diez ejecuciones, igual.
• El 39 % no se repitió ni una vez.
• En conjunto, en el 58 % de los casos el nombre inventado salió al menos dos veces.

Si la alucinación fuese ruido aleatorio, el slopsquatting no funcionaría: para cuando el atacante registrara el nombre, el modelo ya se estaría inventando otro. Pero no es aleatoria. Casi la mitad de los nombres los inventa de forma fiable, una y otra vez, igual.

Eso es lo que lo vuelve previsible, y por eso se puede registrar.

Y esto no es una errata

Aquí llega la segunda sorpresa, la que además reescribe la defensa.

Solo el 13,4 % de los nombres inventados está a uno o dos caracteres de distancia de edición de un nombre de paquete real. La mayoría no es una versión mal escrita de un nombre existente, sino un nombre verosímil que nunca existió.

El reparto por tipos: alrededor de la mitad es invención pura, más de un tercio es cruce (los nombres de dos paquetes reales mezclados) y solo el resto se parece a una errata. Dentro de esos tipos hay además un subtipo más taimado: el 8,7 % de los nombres inventados para Python existe de verdad, solo que en el ecosistema de JavaScript. El modelo se lleva el nombre de un registro al otro.

Esto tiene una consecuencia muy concreta: la defensa construida contra el typosquatting — el filtrado por distancia de nombres — deja pasar la mayor parte de esto. Lo que los registros de paquetes tienen montado para ese fin aquí no te protege.

Qué ha pasado hasta ahora en la realidad

Hay tres casos que conviene conocer, y un cuarto hallazgo que importa más que todos ellos.

La prueba de concepto que se llevó 30.000 descargas. En 2024, un investigador de seguridad subió un paquete completamente vacío con un nombre que se alucinaba a menudo. En tres meses recibió más de 30.000 descargas reales, y una gran empresa tecnológica copió el comando de instalación en la descripción de su propio repo. No hizo falta ni mala intención ni marketing: bastó con que el modelo lo recomendara con aplomo.

El giro de 2026: los archivos de instrucciones para agents. En enero de 2026, un investigador registró de forma defensiva un nombre nacido del cruce de dos paquetes reales. El nombre se propagó a través de archivos de instrucciones para agents generados por IA, llegó copiado por forks a 237 repos y hasta lo tradujeron. Los agents intentaban instalarlo a diario. Contenido malicioso no había.

Esta es la parte del «por qué justo ahora»: el nombre inventado ya no sale de la ventana de chat de un desarrollador, sale de archivos de instrucciones que nadie lee y que los forks multiplican.

Un paquete sospechoso. En la primera mitad de 2026, el registro puso en cuarentena de seguridad un paquete de JavaScript: una versión alucinada y acortada de un plugin real. Iba por unas doscientas descargas semanales. Quien lo descubrió es prudente con las palabras: «un ataque de slopsquatting potencialmente deliberado». La intención no se pudo demostrar.

Y el cuarto hallazgo: hasta julio de 2026 no se ha notificado ningún caso en el que el slopsquatting se haya usado realmente como ciberataque.

Esto hay que decirlo. El slopsquatting es hoy un mecanismo demostrado sin explotación documentada.

¿Cuál es el riesgo real?

Conviene poner dos cifras una al lado de la otra.

Por el lado «tradicional» de la cadena de suministro, durante 2025 se identificaron más de 454.600 paquetes maliciosos nuevos, y más del 99 % de ellos apareció en el mismo ecosistema. Frente a eso, el slopsquatting tiene un único paquete sospechoso.

O sea que el slopsquatting no es hoy el mayor riesgo. Pero hay algo en lo que se diferencia de todo lo demás: escala con el uso de modelos, no con el trabajo del atacante. Cuanta más gente pida código, más nombres inventados entran en circulación, y al atacante le sigue bastando con preguntarle al modelo.

Cuál es tu exposición

Calculémoslo. Supongamos que un desarrollador hace al mes cincuenta preguntas que acaban en una sugerencia de instalar un paquete.

CON MODELO DE PESOS ABIERTOS (21,7 %):
  sugerencia alucinada:        50 × 0,217 = ~11 / mes
  repetición estable:          11 × 0,43  =  ~5 / mes

CON MODELO CERRADO (5,2 %):
  sugerencia alucinada:        50 × 0,052 = ~2,6 / mes
  repetición estable:         2,6 × 0,43  = ~1,1 / mes

(Cálculo propio, con las proporciones de la medición anterior.)

Cinco nombres inventados al mes que el modelo va a volver a inventar de forma fiable una y otra vez, o sea nombres que un atacante puede predecir de antemano y registrar. La elección del modelo supone una diferencia de cuatro veces. A cero no lo lleva ninguno.

La defensa que sí funciona

La buena noticia es que la protección más eficaz no es nueva y probablemente ya la tienes a medias.

Lockfile y verificación de hash. Funciona porque se apoya en una lógica simple: un nombre de paquete inventado, por definición, no está en el lockfile. Si el build instala solo desde el lockfile, el paquete inventado del agent no entra: el build se rompe. Que es exactamente el comportamiento deseado.

En los dos grandes ecosistemas esto se ve así:

• Por el lado de JavaScript, en el CI hay que usar la variante basada en el lockfile en lugar de la instalación normal. Esa exige que exista el lockfile, se detiene con error si difiere del descriptor del paquete y nunca sobrescribe ninguno de los dos: la instalación queda prácticamente congelada.
• Por el lado de Python, el equivalente es el modo de verificación de hash. Ahí cada requisito necesita hash, no hay hashing parcial; lo que no esté escrito y hasheado provoca un error; y hay que fijar todas las versiones.

Cuatro medidas más, baratas:

• La fecha de registro. Es sospechoso que un paquete se creara entre treinta y noventa días antes de arrancar tu proyecto y apenas tenga descargas.
• Un registro proxy interno con lista de permitidos. Lo que no está en la lista no entra.
• Que el agent no pueda instalar un paquete sin aprobación humana. Esto es un ajuste de permisos, no una cuestión de normativa interna.
• Temperatura más baja para generar código. Menos creatividad al poner nombres.

Lo que hacen los registros — y lo que no

Entre 2025 y 2026, los dos grandes registros de paquetes endurecieron mucho las cosas: por el lado de JavaScript se revocaron todos los tokens de acceso del tipo antiguo, el inicio de sesión da un tokende sesión de dos horas, los tokens de CI duran noventa días como máximo y la publicación de confianza sin token pasó a ser el camino recomendado. Por el lado de Python, en 2025 ya la usaban más de cincuenta mil proyectos, una quinta parte de las subidas llegaba así y dos tercios de los avisos maliciosos se atendieron en menos de cuatro horas.

Pero hay algo que hay que decir con precisión: no hemos encontrado ninguna medida del lado de los registros dirigida específicamente contra el slopsquatting. Todo lo anterior es endurecimiento general de la cadena de suministro. Y la detección de typosquatting del lado de Python se basa en la distancia entre nombres, y a estas alturas ya sabes por qué no lo va a atrapar: el 86,6 % de los nombres inventados ni siquiera está a uno o dos caracteres de un nombre real.

Malentendidos habituales

• «Esto solo pasa con los modelos abiertos malos.» La diferencia es de cuatro veces, pero incluso con los cerrados salen uno o dos nombres inventados previsibles por desarrollador y mes.
• «La defensa contra el typosquatting también atrapa esto.» No. El 86,6 % de los nombres inventados no son erratas, sino nombres que nunca existieron.
• «Es aleatorio, así que no se puede explotar.» El 43 % de los nombres sale igual en diez ejecuciones de diez.
• «Ya ha habido un ataque grande de esto.» Hasta julio de 2026 no se notificó ninguno. Mecanismo demostrado, sin explotación documentada.
• «Ya lo resolverán los registros.» Han endurecido mucho, pero no hay ninguna medida dirigida específicamente a esto, y el filtro de distancia entre nombres que existe lo deja pasar.

Lo que conviene llevarse

El slopsquatting no es peligroso porque el modelo alucine, sino porque alucina lo mismo de forma previsible. Eso es lo que hace registrable el nombre. La defensa, en cambio, es barata y antigua: lockfile, verificación de hash y comprobar el nombre antes de instalar nada, con el agent sin poder instalar por su cuenta. El lockfile y el hash protegen el build: ahí el paquete inventado no entra, el build se rompe por ti. El caso principal del artículo es otro, que lances a mano el comando de instalación sugerido, y eso solo lo atrapa la comprobación previa a la instalación: en cuanto lanzas el comando, el script de instalación ya se ha ejecutado.

El panorama de seguridad más amplio lo expone el post la factura de seguridad del código de IA , con el cálculo; y los pasos de la revisión manual los recorre el post revisar el código generado , uno a uno.