1.500 paquetes npm podían ser secuestrados simplemente al ocupar nombres antiguos en GitHub

El mecanismo de protección de npm resultó capaz de transferir el derecho a publicar el paquete de otra persona a quien simplemente ocupara el nombre de repositorio liberado. Bloom Security descubrió el problema SlugFest y contó más de 1500 paquetes potencialmente vulnerables con un total de más de 10 millones de descargas y más de 1 millón de descargas al mes. Para el ataque no fue necesario robar credenciales.

La función Trusted Publishing permite publicar versiones desde GitHub Actions sin un token permanente de npm. CI/CD recibe un token OIDC de corta duración que npm verifica antes de otorgar permisos temporales de publicación. El error estaba en la vinculación de confianza: hasta la primera publicación exitosa, npm guardaba la dirección textual owner/repository en lugar de los identificadores numéricos permanentes del repositorio y del propietario.

Si el desarrollador renombraba, trasladaba o eliminaba el repositorio asociado, la dirección antigua podía volver a estar disponible. Un atacante podía registrar un repositorio con el nombre anterior, crear un workflow con el nombre requerido y obtener un token OIDC válido. npm veía la dirección coincidente y emitía un token temporal de publicación, aunque el nuevo repositorio ya perteneciera a otro propietario.

Bloom comprobó el esquema en su propio paquete de npm y en repositorios bajo su control. Los investigadores pudieron publicar una nueva versión desde el repositorio de otra organización sin robar credenciales de npm o GitHub. Un lanzamiento malicioso podía conservar el nombre, la reputación y las dependencias del paquete legítimo, y el script postinstall ejecutaría código al instalarse. No se han confirmado ataques reales a través de SlugFest.

El riesgo aumenta con la automatización del desarrollo. Según las mediciones de Bloom, una estación de trabajo típica recibe alrededor de 70 paquetes al mes a través de agentes de IA, y el equipo del desarrollador unos 350. Un agente puede elegir una versión reciente de una dependencia sin verificar manualmente su procedencia. Un problema parecido ya se mostró en dependencias de IA, donde la selección automática de paquetes amplía la superficie de ataque.

GitHub recibió el informe el 6 de junio y confirmó el problema el 9 de junio, y la corrección apareció el 2 de octubre. La empresa modificó las reglas: la configuración no validada de Trusted Publishing ahora dura solo 48 horas, tras lo cual pierde el derecho a publicar. La primera publicación exitosa confirma la vinculación con la identidad inmutable del repositorio. npm también dejó de aceptar tokens de Trusted Publishing procedentes de eventos issue_comment.

A los mantenedores se les aconseja comprobar los enlaces mediante npm trust list, eliminar las configuraciones para repositorios renombrados, trasladados o eliminados y crear otras nuevas. Tras la nueva vinculación es mejor publicar inmediatamente una versión para que npm registre el identificador permanente. Un obstáculo adicional lo proporciona publicación por etapas, donde la publicación requiere la aprobación del mantenedor con autenticación de dos factores (2FA).