GitHub ha tomado la medida de hacer expirar las configuraciones de publicación confiable en npm que no hayan sido validadas dentro de las 48 horas posteriores a su creación, después de que investigadores descubrieran que era posible que un atacante publicara nuevas versiones del paquete de otro usuario sin necesidad de robar sus credenciales.
Su configuración se valida y queda exenta de expiración después de su primera publicación exitosa. Cambiar la identidad del repositorio o del proyecto requiere una nueva relación de confianza con una ventana de validación renovada de 48 horas; las ediciones ordinarias no reinician el plazo.
El cambio contiene el riesgo asociado con confiar en un nombre de repositorio o proyecto que cambia de propietario, según GitHub, y añade que npm también rechazará en adelante los tokens de publicación confiable procedentes de eventos issue_comment de GitHub Actions, junto con la restricción existente para pull_request_target.
En una actualización de su documentación, GitHub establece que una configuración de publicador de confianza recién creada debe completar su primera publicación exitosa en un plazo de dos días, lo que valida la configuración y la vincula a la 'identidad inmutable del repositorio'.
Este desarrollo responde a los hallazgos de Bloom Security, que descubrió una laguna en el sistema de publicación confiable de npm que permitía hacerse con el control de miles de paquetes y desencadenar un ataque en cascada de cadena de suministro al estilo Shai-Hulud. Los hallazgos se reportaron a GitHub el 6 de junio de 2026.
Imagínese esto: un atacante compromete un solo paquete. Un agente de IA en el dispositivo de un mantenedor de paquetes populares lo descarga de forma autónoma para un proyecto. Ese único endpoint se utiliza para enviar código malicioso al paquete popular. Todos los usuarios del paquete quedan expuestos. Todo porque una persona con el acceso correcto quedó expuesta.
La publicación confiable se introdujo en npm en julio de 2025 como un método de autenticación sin credenciales que permite a los desarrolladores publicar paquetes npm desde una plataforma de CI/CD, como GitHub Actions, utilizando tokens de OpenID Connect (OIDC).
Cuando se configura la publicación confiable, el proveedor de CI/CD del desarrollador genera un token criptográfico de corta duración para una ejecución de flujo de trabajo específica, que el registro npm verifica contra una configuración preautorizada. Esto elimina la necesidad de almacenar, rotar o gestionar manualmente secretos npm de larga duración, reduciendo el riesgo de filtraciones de credenciales. También genera automáticamente atestaciones de procedencia para los paquetes npm, lo que permite a los usuarios establecer dónde se construyó un paquete y quién lo publicó, fortaleciendo así la seguridad de la cadena de suministro de software.
Sin embargo, como descubrió Bloom Security, esta arquitectura de seguridad presentaba un problema en la forma de identificar el repositorio, también llamado slug (es decir, la combinación del propietario u organización y el nombre del repositorio con el formato 'propietario/repositorio').
Registra la dirección del repositorio, […] en lugar del ID permanente que GitHub le asigna, al menos hasta que se publica una versión desde ese repositorio por primera vez. Es como una cerradura que comprueba la dirección en la puerta en lugar de quién es el dueño de la casa: cuando el dueño se muda, quien se muda entra recibe la llave.
En otras palabras, los ID numéricos que sobreviven a los cambios de nombre y transferencias de repositorios son transportados por los tokens OIDC de GitHub, pero npm los ignora por completo hasta la primera publicación exitosa desde ese repositorio. Esto significa que la confianza se ancla a un nombre en lugar de a un ID de repositorio inmutable, una laguna que puede ser explotada reclamando slugs abandonados para heredar su confianza. Para que este ataque tenga éxito, el único requisito previo es que el publicador de confianza de la víctima apunte a un slug de GitHub que un atacante pueda reclamar, y que el repositorio nunca se haya utilizado para publicar una versión del paquete en npm.
Una vez que dicho slug queda disponible para su uso después de que un mantenedor renombra, transfiere o elimina un repositorio, un atacante puede seguir estos pasos:
- Crear un repositorio en el slug liberado en la ruta 'propietario/repositorio', lo que hace que GitHub emita un nuevo ID de repositorio.
- Crear y activar un flujo de trabajo de publicación en npm, que genera un token OIDC que lleva el slug reclamado y el nuevo ID numérico del repositorio.
- Enviar el token al endpoint de intercambio de npm. Npm comprueba que la reclamación del repositorio coincide con el slug almacenado y emite una credencial de publicación.
- El atacante recibe un token de publicación limitado en el tiempo para un paquete que no posee y envía cambios maliciosos al registro.
Un ataque de este tipo, con el nombre en clave SlugFest, puede utilizarse para publicar una nueva versión 'maliciosa' del paquete víctima bajo el nombre legítimo del paquete, mientras hereda la reputación existente, los recuentos de descargas y las relaciones de dependencia. Esto, a su vez, puede dar lugar a ataques de cadena de suministro a escala.
Los agentes de IA que se ejecutan en las máquinas de los desarrolladores pueden complicar aún más las cosas. 'Los agentes resuelven las dependencias por sí mismos, tienden a tomar la última versión y rara vez comprueban de dónde procede un paquete', dijo Bloom Security. 'Una versión maliciosa publicada a través de un slug reclamado se descarga y se ejecuta sin intervención humana'.
La empresa de ciberseguridad afirmó haber encontrado más de 1.500 paquetes vulnerables que en conjunto han sido descargados más de 10 millones de veces.
Se recomienda a los desarrolladores que mantienen paquetes npm que realicen las siguientes acciones:
- Auditar las vinculaciones de publicadores de confianza y verificar si el slug del repositorio listado sigue resolviendo al repositorio bajo su control.
- Si el repositorio ha sido renombrado o transferido, eliminar la vinculación de confianza existente y volver a crearla apuntando al slug actual.
- Monitorizar eventos de publicación inesperados en npm.
- Eliminar las vinculaciones de confianza cada vez que se elimine, transfiera o renombre un repositorio.
El ataque no requiere conocimiento interno, ni robo de credenciales, ni condición de carrera. La única precondición es la disponibilidad del slug (en una vinculación que aún no se ha utilizado para publicar), lo que depende enteramente de la higiene de repositorios de la propia víctima.
Lo que demuestra esta investigación es algo que la comunidad de seguridad ha visto repetidamente en los ataques a la cadena de suministro: la vinculación entre un identificador legible por humanos y la cosa que identifica es la invariante más importante en cualquier sistema de confianza. Cuando esa vinculación puede reemplazarse silenciosamente, por el acto ordinario de renombrar un repositorio, no por ninguna acción del atacante, la garantía de confianza se derrumba.
Esta no es la primera vez que se descubren vectores de ataque no convencionales en la cadena de suministro. A principios de este agosto, Bloom Security también descubrió que tanto Open VSX como el Marketplace de VS Code de Microsoft permitían que los paquetes de extensiones hicieran referencia a extensiones inexistentes en los mercados.
La técnica, denominada Extension Resurrection, puede ser utilizada para secuestrar extensiones ya referenciadas dentro de estos paquetes de confianza simplemente reclamando un espacio de nombres no reclamado. Hasta 87 paquetes en Open VSX y 677 paquetes en el Marketplace de VS Code fueron marcados como vulnerables.
Los atacantes podrían reclamar esos espacios vacíos, publicar código malicioso bajo ellos y hacer que se instale automáticamente junto con el paquete de confianza, enviando actualizaciones silenciosamente a cualquiera que haya instalado el paquete previamente. Dado que las extensiones se ejecutan con acceso completo al host, esto equivale efectivamente a [ejecución remota de código] entregada bajo la apariencia de legitimidad.
Deja una respuesta