GitHub hace caducar en 48 horas configuraciones de npm sin validar tras una falla que expuso más de 1.500 paquetes

GitHub cerró una falla en npm, el registro de paquetes de JavaScript, que dejaba a más de 1.500 paquetes expuestos a un secuestro: un atacante podía publicar versiones nuevas de un paquete ajeno sin robar ninguna credencial. Le bastaba registrar el nombre de un repositorio de GitHub que el mantenedor había abandonado. La empresa anunció el 2 de octubre un cambio que reduce el riesgo, y el 13 de octubre la firma Bloom Security publicó los detalles de la falla, que bautizó SlugFest.

Cómo funcionaba

La publicación confiable de npm, disponible desde julio de 2025, evita los tokensUnidad mínima de texto que procesa un modelo de lenguaje, como una palabra, parte de una palabra o un signo. Se usa para medir cuánto lee y escribe un modelo y para cobrar su uso. de larga duración: el mantenedor le indica a npm qué repositorio de GitHub y qué flujo de trabajo pueden publicar su paquete, y npm entrega una credencial que vence en minutos.

El problema es que npm identificaba el repositorio por su nombre, en formato propietario/repositorio, y no por el número de identificación permanente que GitHub le asigna. Si el mantenedor renombraba, transfería o borraba el repositorio, o cambiaba o borraba su cuenta, el nombre quedaba libre. Cualquiera podía crear un repositorio con ese nombre y un flujo de trabajo con el archivo correcto, y recibía permiso para publicar. Bloom lo probó de punta a punta, pero solo con un paquete propio.

Un paquete secuestrado puede incluir un script de instalación, que corre automáticamente en cada máquina que lo instala. Bloom contó más de 1.500 paquetes expuestos, entre ellos escáneres de seguridad, herramientas de autenticación y de criptografía, con más de 10 millones de descargas en total. No observó explotación real, y no publicó la lista de nombres.

Qué cambió

Desde el 2 de octubre, según el aviso de GitHub, las configuraciones de publicación confiable que no fueron validadas caducan 48 horas después de crearse y dejan de poder autorizar publicaciones. Una configuración queda validada y sin vencimiento tras su primera publicación exitosa. Además, npm ahora rechaza los tokens de publicación confiable generados por eventos issue_comment de GitHub Actions, igual que ya hacía con pull_request_target.

Bloom informó el problema por el programa de recompensas el 6 de junio y GitHub lo validó el 9 de junio. Según Bloom, la última respuesta llegó el 8 de julio y sus seis recordatorios posteriores no tuvieron respuesta. GitHub dijo a Help Net Security que se enteró por ese programa y que validó el reporte y lanzó correcciones. La empresa no aclaró si las configuraciones anteriores al cambio quedaron vinculadas de forma retroactiva.

Qué tienen que hacer quienes publican paquetes

Quien mantiene un paquete con publicación confiable debería ejecutar npm trust list y confirmar que cada repositorio listado siga siendo uno que controla. Si un vínculo apunta a un repositorio renombrado o transferido, hay que borrarlo y crearlo de nuevo. Y antes de borrar un repositorio, hay que quitar su vínculo. Para quienes instalan paquetes, Bloom aconseja comprobar que la atestación de procedencia de un paquete nombre el repositorio de donde debe venir. Bloom afirma que la integración de npm con GitLab tiene la misma debilidad.

Detalle técnico

La falla consistía en validar el repositorio por su nombre y no por su identificador numérico inmutable, y no se informó un CVE. La corrección, de 48 horas de caducidad para configuraciones sin validar, rige desde el 2 de octubre de 2026 y está en el aviso de GitHub Changelog "Unvalidated npm trusted publishing configurations now expire".