Una falla en npm Trusted Publishing expuso más de 1.500 paquetes

Una investigación divulgada el 13 de octubre identificó una debilidad en Trusted Publishing, el mecanismo que permite publicar paquetes npm desde flujos automatizados sin guardar credenciales permanentes. Bloom Security la denominó SlugFest y detectó más de 1.500 paquetes potencialmente expuestos, con más de diez millones de descargas acumuladas. La cifra describe paquetes que podían cumplir las condiciones del ataque; no significa que todos hayan sido comprometidos. (bloom.security)

El problema aparecía antes de la primera publicación realizada mediante una configuración de confianza. En esa etapa, npm se basaba en el nombre legible del repositorio y del flujo de trabajo. Si el repositorio original cambiaba de nombre, se transfería o desaparecía, un atacante podía reclamar la dirección anterior y, bajo las condiciones descritas por los investigadores, publicar una versión del paquete sin robar la cuenta de su responsable. Bloom demostró el mecanismo con paquetes bajo su control; no informó haber observado explotación activa contra terceros. (csoonline.com)

GitHub había anunciado el 2 de octubre una mitigación: las configuraciones de Trusted Publishing que no se validan mediante una primera publicación expiran después de 48 horas. La divulgación pública de la investigación llegó el 13 de octubre. Es una distinción importante: se trata de una noticia reciente sobre una exposición investigada, no de un parche lanzado hoy. (github.blog)

Si mantienes paquetes npm, revisa las configuraciones de publicación confiable, los repositorios y flujos asociados, y el historial de versiones publicadas. Si consumes dependencias, conserva las revisiones de cambios y los controles sobre scripts de instalación. Sustituir secretos permanentes por credenciales temporales reduce un riesgo, pero no elimina la necesidad de verificar a qué repositorio se le está concediendo la confianza. (csoonline.com)