npm Trusted Publishing: el fallo SlugFest exponía 1.500 paquetes

Los investigadores de Bloom Security descubrieron que Trusted Publishing, el mecanismo de npm que sustituye a los tokens de publicación de larga duración, permitía publicar nuevas versiones de un paquete ajeno sin robar ninguna credencial: bastaba con registrar en GitHub el nombre de un repositorio que el mantenedor había dejado libre. Según Bloom, los paquetes expuestos eran más de 1.500. La vulnerabilidad, llamada SlugFest, ha sido corregida por GitHub, propietaria de npm, con un cambio anunciado el 2 de octubre de 2026. Help Net Security, CSO Online y The Hacker News informaron de ello el 13 de octubre.

Qué ha pasado

Trusted Publishing, disponible para todos desde julio de 2025, se basa en OpenID Connect: el mantenedor indica a npm qué repositorio de GitHub y qué archivo de workflow pueden publicar el paquete. Cuando el workflow se ejecuta, GitHub le emite un token de identidad firmado, que npm canjea por una credencial de publicación válida durante pocos minutos.

El problema, según Bloom, estaba en cómo npm verificaba el repositorio: solo con el nombre legible owner/repo (el slug) y el nombre del archivo de workflow. GitHub asigna también a cada repositorio y a cada propietario un identificador numérico permanente, que no cambia con los cambios de nombre ni las transferencias y que ya está presente en el token, pero npm no lo comprobaba.

Bloom demostró el ataque de principio a fin con un paquete y repositorios bajo su propio control, publicando una nueva versión desde el repositorio de otra organización que había ocupado el nombre liberado. Según CSO Online, los investigadores afirman no haber observado explotación real; a Help Net Security le precisaron que no se sabe si alguien ha usado el fallo.

Detalles técnicos

La cadena descrita por las fuentes es esta:

1. el mantenedor renombra, transfiere o elimina el repositorio vinculado al paquete, o renombra o elimina la cuenta propietaria, sin quitar la configuración de Trusted Publishing;
2. el antiguo slug vuelve a estar disponible;
3. el atacante crea un repositorio con ese nombre y añade un workflow de GitHub Actions con el mismo nombre de archivo previsto por la configuración;
4. npm acepta el token y emite la credencial de publicación: el atacante publica una nueva versión del paquete.

No hace falta comprometer la cuenta de GitHub o npm del mantenedor ni robar credenciales. La versión publicada de este modo tiene además una atestación de procedencia válida y firmada, que sin embargo indica el repositorio del atacante. Una versión maliciosa puede contener un script postinstall, que npm ejecuta automáticamente en cada máquina que instala la actualización, incluidas las pipelines de CI.

Según Help Net Security, GitHub ya retira los nombres de los repositorios con más de 100 clonaciones en la semana anterior al cambio de nombre o la eliminación de la cuenta propietaria: esto protegía a una parte de los paquetes, y Bloom dice haberlo tenido en cuenta contando solo los slugs que realmente se podían registrar.

Las cifras de Bloom: más de 1.500 paquetes, más de 10 millones de descargas en total y más de un millón al mes. Según CSO Online, un solo paquete superaba las 200.000 descargas mensuales, y entre los paquetes expuestos hay escáneres de seguridad, herramientas de autenticación y bibliotecas criptográficas. Bloom no publica los nombres de los paquetes. También según Bloom, información que recoge solo Help Net Security, la integración de Trusted Publishing con GitLab tiene la misma debilidad.

En nuestra lectura, la técnica MITRE ATT&CK pertinente es T1195.001 (Compromise Software Dependencies and Development Tools).

La corrección y los plazos

Según lo que Bloom contó a Help Net Security, el informe se envió a través del programa de bug bounty de GitHub en HackerOne el 6 de junio y se validó el 9 de junio; la última respuesta recibida es del 8 de julio, y seis recordatorios posteriores, incluida una solicitud de mediación a HackerOne, quedaron sin respuesta.

Los cambios, según GitHub y la documentación de npm citadas por las fuentes:

• las configuraciones de Trusted Publishing no validadas caducan a las 48 horas de su creación y ya no autorizan publicaciones;
• la primera publicación correcta vincula la configuración a la identidad inmutable del repositorio;
• según CSO Online, npm rechaza ahora también los tokens emitidos por workflows activados por el evento issue_comment, además de la restricción ya existente sobre pull_request_target.

Help Net Security señala que la declaración de GitHub no aclara si las configuraciones que ya habían publicado antes del cambio se vincularon a la identidad de forma retroactiva. Por eso Bloom pide a los mantenedores que revisen igualmente las configuraciones existentes.

Impacto para las empresas europeas e italianas

npm es el registro de referencia para JavaScript y TypeScript: lo usan aplicaciones web, herramientas de desarrollo y pipelines de compilación en casi todas las empresas que desarrollan software. Un paquete secuestrado ejecuta código en los equipos de los desarrolladores y en los runners de CI, donde se encuentran tokens, claves y accesos a los sistemas de producción.

Bloom subraya el papel de los agentes de IA de programación: a partir de datos recogidos en unas decenas de organizaciones, estima unos 70 paquetes instalados por los agentes cada mes por endpoint, y unos 350 en las máquinas de los desarrolladores, sin contar las dependencias, normalmente sin ninguna revisión del paquete o de su mantenedor.

Para las entidades sujetas a NIS2, la seguridad de la cadena de suministro y del desarrollo es una de las medidas exigidas: un caso como este debe considerarse tanto para el software que la empresa publica en npm como para el que utiliza.

Qué hacer ya

1. Si publicas paquetes con Trusted Publishing: ejecuta npm trust list y comprueba que cada repositorio indicado sigue existiendo y está bajo tu control. Elimina y vuelve a crear las configuraciones que apuntan a repositorios renombrados o transferidos, y quita la configuración antes de eliminar un repositorio o renombrar una cuenta.
2. Revisa el historial de versiones de tus paquetes: las versiones que no reconozcas, o con una atestación de procedencia que indique un repositorio distinto del tuyo, deben retirarse y notificarse.
3. Si usas paquetes npm: como no hay una lista con la que comparar, comprueba que la atestación de procedencia de las versiones nuevas indique el repositorio del que debería proceder el proyecto.
4. Reduce el impacto de los scripts de instalación: fija las versiones con el archivo de bloqueo y, cuando sea posible, desactiva los scripts de instalación en las pipelines (--ignore-scripts).
5. Controla las instalaciones de los agentes de IA, como recomienda Bloom: decide qué pueden instalar los desarrolladores y los agentes y mantén un inventario de las dependencias y herramientas en uso.

Cómo ayuda ARXDOME

ARX Sentry recoge el inventario de software y procesos de ordenadores y servidores: te ayuda a saber dónde se ejecutan las herramientas de desarrollo y los runners que hay que revisar. Si una máquina ha instalado una versión sospechosa, ARX Shield te permite aislarla de la red mientras se hacen las comprobaciones y la rotación de secretos.

Última actualización: 13 de octubre de 2026