Bloom Security halla una vulnerabilidad en la publicación de paquetes y los agentes de IA multiplican el riesgo

En 2025, unos investigadores analizaron 576 mil fragmentos de código escritos por 16 modelos. De media, el 19,7% de los paquetes recomendados no existía. Esos nombres pueden registrarse y rellenarse con código malicioso, y bastaría con esperar a que un asistente de IA los incorpore por sí solo a un proyecto. Ahora el problema tiene una capa más: la empresa Bloom Security ha descrito una vulnerabilidad en la infraestructura de publicación de software que, combinada con las instalaciones automáticas, puede llevar código malicioso a un entorno corporativo. Lo publica The Next Web.

Qué se sabe de la vulnerabilidad

Los detalles técnicos en la parte accesible de la publicación son limitados, así que conviene no especular. Esto es lo que se sabe: Bloom Security ha encontrado un punto débil en los mecanismos de publicación de paquetes, y este se vuelve más peligroso cuando quien instala las dependencias no es una persona, sino un agente de IA. A juzgar por la dirección del artículo, se trata del mecanismo Trusted Publishing de npm.

Es un esquema en el que el paquete se publica desde un proceso de CI de confianza, sin tokens de larga duración. La idea es razonable: los tokens se roban con regularidad, y tras la oleada de ataques a npm en 2025, incluido el gusano Shai-Hulud, que afectó a cientos de paquetes, el ecosistema revisó a fondo sus prácticas de publicación.

Una vulnerabilidad en el propio mecanismo de confianza golpea el supuesto básico: si un paquete se ha publicado de la forma «correcta», se puede confiar en él. El agente comparte ese supuesto y no lo va a comprobar.

Por qué los agentes cambian la escala

Una persona que instala una dependencia suele echar al menos un vistazo rápido al nombre, al número de descargas y al repositorio. El agente funciona de otra manera: necesita que pasen los tests y que la compilación termine bien. Si un paquete resuelve la tarea, acabará en `package.json` en cuestión de segundos.

Tres factores se refuerzan entre sí:

• Velocidad. Un agente puede instalar decenas de dependencias en una sola sesión, y cada una se convierte en un punto de entrada.
• Alucinaciones de nombres. Alrededor del 20% de paquetes inexistentes en las respuestas de los modelos, según el estudio de 2025, crea un terreno propicio para atacar mediante el registro de nombres similares.
• Permisos. Los agentes suelen trabajar en entornos con acceso a secretos, CI y repositorios internos, y los scripts de instalación de npm se ejecutan de inmediato.

La vulnerabilidad en la publicación añade a todo esto un vector más: ni siquiera un nombre de paquete correcto garantiza ya la seguridad.

A quién afecta

Corren más riesgo los equipos donde la programación con IA está integrada en el flujo de trabajo sin una política específica para las dependencias: startups con ciclos de lanzamiento rápidos, contratistas y equipos internos de plataforma. Los servicios de seguridad corporativos están acostumbrados a controlar a las personas y los pipelines, pero el agente se sitúa entre ambos y elude los dos niveles de control.

Por ahora no está claro hasta qué punto se ha explotado la brecha en la práctica ni qué versiones están afectadas. Son preguntas que conviene plantear al proveedor del registro y a los propios investigadores.

Qué hacer ya

Lo primero es averiguar qué agentes de la empresa pueden ejecutar `npm install` y en qué entorno. Si se trata del equipo de un desarrollador con tokens y acceso a repositorios privados, esa es la primera zona que restringir.

Después, funcionan medidas ya probadas:

• activar los lock-files y prohibir que los agentes los modifiquen sin revisión;
• desactivar la ejecución de scripts de instalación (`--ignore-scripts`) donde no hagan falta;
• crear una allowlist de dependencias o un espejo interno del registro con retraso para las versiones nuevas;
• comprobar los paquetes nuevos por antigüedad, número de mantenedores y origen de la compilación;
• ejecutar los agentes en sandboxes aislados, sin secretos permanentes.

La conclusión principal es sencilla: la confianza en el registro hay que verificarla igual que la confianza en el código, y la velocidad del agente no debe superar la velocidad de la revisión.