Cuando tu asistente de programación inventa un paquete, los atacantes lo registran primero

Pídele a un asistente de programación con IA que ordene las importaciones y puede que te entregue el nombre de un paquete que no existe. El nombre parecerá verosímil. Combinará dos herramientas reales o seguirá una convención de nombres que reconozcas. Pegas el comando de instalación y, si alguien ya ha registrado ese nombre, acabas de instalar lo que sea que haya publicado.

Los investigadores de seguridad lo llaman slopsquatting. Es pariente del typosquatting, salvo que el atacante no necesita que escribas mal nada. Solo necesita saber qué tiende a inventar el modelo y luego ser el primero en reclamarlo.

La escala no es anecdótica

Un estudio de USENIX Security de 2025 probó 16 modelos de generación de código con 576.000 muestras de código en Python y JavaScript. Encontró más de 205.000 nombres de paquetes únicos que no existían en ningún registro. La tasa de alucinación fue de al menos el 5,2 % en los modelos comerciales y del 21,7 % en los de código abierto. Un seguimiento de 2026 probó cinco modelos de frontera más recientes y midió tasas de entre el 4,62 % y el 6,10 %, lo que es más bajo, pero sigue presente en todos los modelos evaluados.

Lo que convierte una peculiaridad en una superficie de ataque es la repetibilidad. Cuando los investigadores volvieron a ejecutar prompts idénticos, una gran parte de los nombres alucinados reaparecía cada vez. Los modelos no adivinan al azar; convergen en las mismas respuestas incorrectas porque aprendieron los mismos patrones de los mismos datos de entrenamiento. Esa predictibilidad es la vulnerabilidad. Un atacante puede ejecutar los mismos prompts, recopilar los nombres que se repiten y registrarlos antes que nadie.

El estudio de 2026 identificó 127 nombres de paquetes que los cinco modelos evaluados produjeron a pesar de no existir, y 53 seguían disponibles para su registro después de aplicar las protecciones del registro.

Paquetes reales, instalaciones reales

Esto ya ha ocurrido. A principios de 2026, los investigadores encontraron un paquete llamado react-codeshift referenciado en 237 repositorios de GitHub. El nombre combina dos herramientas reales, jscodeshift y react-codemod. Nunca se había publicado. Una skill generada por IA que contenía el paquete ficticio se había copiado y bifurcado, lo que permitió que la referencia se propagara por sí sola.

Un paquete llamado metro-evaluator en npm contenía código malicioso en cuatro versiones publicadas en diciembre de 2025 antes de que se eliminara cinco días después y se sustituyera por un marcador de seguridad. Los modelos evaluados habían sugerido ese nombre diez veces. Otro, unused-imports, imitaba al real eslint-plugin-unused-imports y siguió acumulando instalaciones de desarrolladores cuyo asistente los dirigía hacia él.

La operación mayor es una campaña que la firma de seguridad Koi Security llama PhantomRaven, activa desde al menos agosto de 2025. Koi le atribuye 126 paquetes npm maliciosos y más de 86.000 descargas. El truco allí es distinto del de un nombre alucinado. El package.json parece limpio, a veces contiene poco más que una línea de log, pero apunta a una dependencia alojada en una URL HTTP sin cifrar en lugar de a otro paquete npm. La mayoría de los escáneres no siguen URL sin procesar, por lo que el payload que recolecta tokens de npm, credenciales de GitHub y secretos de CI se carga de forma invisible en el momento de la instalación. Endor Labs documentó tres oleadas más de la misma campaña entre noviembre de 2025 y febrero de 2026, que añadieron 88 paquetes más subidos a través de unas 50 cuentas desechables.

Los registros bloquearon la mayoría de los nombres, no todos

Hay una buena noticia en la investigación. Los registros de paquetes han mejorado a la hora de bloquear los nombres que los modelos tienden a inventar. Normalizan nombres similares, mantienen listas de prohibición y vigilan los patrones que aparecen en muchas muestras generadas. Cuando el estudio de 2026 revisó su lista de 127 nombres alucinados compartidos, la mayoría ya habían sido reclamados o bloqueados por proyectos legítimos y por las defensas de los registros.

El problema es que «la mayoría» no es «todos». El mismo estudio encontró 53 nombres aún disponibles para su registro después de aplicar las protecciones. Un solo nombre registrable en el que coincidan varios modelos de frontera basta para construir un ataque alrededor de él, porque el atacante solo necesita adivinar el modelo, no al desarrollador. Los operadores de los registros han cerrado la mayor parte de la puerta; el hueco restante es estrecho, pero está abierto.

El mismo patrón se ha extendido ahora más allá de los gestores de paquetes. Los investigadores de seguridad han documentado atacantes que registran dominios que los modelos alucinan, y repositorios y skills que los agentes probablemente inventen. El mecanismo es idéntico en cada caso: un modelo predice un nombre verosímil y un sistema construido para confiar en esa predicción actúa en consecuencia. Cada nueva superficie a la que puede llegar un agente se convierte en otro lugar donde plantar un nombre que el agente buscará.

Por qué los agentes lo empeoran

Un desarrollador humano podría advertir un nombre de paquete sospechoso. Un agente no. Los agentes instalan dependencias de forma autónoma, a menudo sin que un humano lea antes el comando. Los investigadores han demostrado técnicas de inyección de prompts que engañan a los agentes para que soliciten nombres de paquetes controlados por el atacante, con tasas de éxito reportadas de hasta el 100 % en herramientas como Cursor, Windsurf y GitHub Copilot.

Esa combinación es lo que cambió el perfil de riesgo. La alucinación proporciona el nombre. El agente proporciona la ejecución. El atacante solo tiene que esperar a que ambos se encuentren.

El problema de las filtraciones es el mismo problema

Un informe relacionado de la firma Glow encontró agentes que exponían más de 13.000 imágenes internas en GitHub, procedentes de más de 300 organizaciones. El mecanismo es mundano: los agentes y sus usuarios colocan capturas de pantalla, diagramas y documentos en repositorios públicos, a veces sin entender que «público» significa indexable y permanente. Las mismas herramientas que hacen más rápidos a los desarrolladores también facilitan mover material interno a un lugar donde no debería ir.

Ambos problemas comparten una causa raíz. Los agentes actúan a velocidad de máquina siguiendo instrucciones que pueden ser erróneas (un nombre alucinado) o sensibles (una captura de pantalla interna). El punto de control humano que solía situarse entre la intención y la acción es exactamente lo que el agente elimina.

Qué hacer en la práctica

Las defensas no son complicadas, lo cual es una buena noticia dada la rapidez con la que se movió la amenaza.

Trata cada comando de instalación que produzca un agente como una entrada no confiable. Comprueba que el paquete exista antes de instalarlo. Comprueba su antigüedad; un nombre alucinado que se haya registrado será reciente. Comprueba que el publicador tenga historial. Para npm y PyPI, una consulta rápida de metadatos responde a las tres preguntas en segundos.

Exige aprobación humana antes de que un agente añada una dependencia. Este es el cambio de mayor valor, porque atrapa de una sola vez los nombres alucinados, los registros maliciosos y las solicitudes con inyección de prompts. Ralentiza un poco al agente y cierra el mayor agujero.

Mantén pequeño el alcance del agente. Un agente de programación necesita acceso al repositorio; rara vez necesita credenciales de producción, y no debería tener un gestor de paquetes apuntando a un registro privado sin una comprobación. Herramientas como Socket y Snyk pueden automatizar la consulta al registro dentro del IDE o de la canalización de CI, lo que merece la pena una vez que un equipo usa agentes en muchos repositorios.

La parte incómoda es que nada de esto es un error que se parchee. La alucinación está integrada en cómo estos modelos predicen texto: generan el siguiente nombre verosímil, no uno verificado. La solución tiene que vivir en el flujo de trabajo en torno al modelo, y ese es un proceso que la mayoría de los equipos puede empezar esta semana.