Un fallo de seguridad en la función de Publicación Confiable de npm expuso más de 1,500 paquetes a una posible toma de control mediante la recuperación de nombres de repositorios de GitHub. Estos paquetes afectados acumulan más de 10 millones de descargas totales y superan el millón de descargas mensuales, lo que representa un grave riesgo para la cadena de suministro de software de desarrolladores y organizaciones que dependen de npm.

Un fallo de seguridad en la función de Publicación Confiable (Trusted Publishing) de npm expuso más de 1.500 paquetes a una posible toma de control mediante la recuperación de nombres de repositorios de GitHub.

Los paquetes afectados sumaron más de 10 millones de descargas totales y más de un millón de descargas al mes, creando un riesgo grave en la cadena de suministro de software para desarrolladores, sistemas CI/CD y organizaciones que dependen de las dependencias de npm.

El problema, denominado SlugFest, no requería que un atacante robara un token de npm, irrumpiera en la cuenta de npm de un mantenedor o accediera al repositorio original de GitHub.

En su lugar, un actor de amenazas podía reclamar un nombre de propietario/repositorio de GitHub abandonado y usarlo para recibir una credencial de publicación de npm válida y de corta duración para un paquete que todavía confiaba en esa ubicación antigua.

Analistas de Bloom Security identificaron el fallo y señalaron que se trataba de una ruta de toma de control de paquetes, no de una campaña de malware activa.

Sin embargo, una toma de control exitosa podría permitir que se publique código malicioso, incluido un script postinstall dañino, bajo el nombre de un paquete legítimo y se entregue a los usuarios durante la instalación normal de dependencias.

Este riesgo es especialmente importante después de que el reciente gusano npm ChainDrop demostrara cómo las versiones comprometidas pueden propagarse a través de herramientas de desarrollo, repositorios y entornos de construcción automatizados.

Fallo de Publicación Confiable de npm con 10 millones de descargas

La Publicación Confiable tiene como objetivo hacer que los lanzamientos de npm sean más seguros. En lugar de almacenar un token de npm de larga duración en GitHub Actions u otro servicio de CI/CD, un mantenedor puede conectar un paquete a un repositorio y a un flujo de trabajo a través de OpenID Connect, o OIDC.

Durante un lanzamiento, el flujo de trabajo obtiene un token de identidad de corta duración y lo intercambia por una credencial de publicación de npm. Esto elimina la necesidad de colocar secretos de publicación reutilizables en las tuberías de construcción. El problema estaba en la forma en que npm vinculaba inicialmente un paquete a su repositorio de publicación.

Para una configuración no validada, npm almacenaba la ruta del repositorio de GitHub legible para humanos, conocida como slug (como organización/proyecto), en lugar de almacenar inmediatamente el ID numérico permanente del repositorio y el ID del propietario de GitHub.

Los nombres de los repositorios pueden cambiar de propietario después de que un proyecto sea renombrado, transferido, eliminado o cuando la cuenta del propietario cambie de nombre.

Eso significa que un atacante podría crear un nuevo repositorio de GitHub usando el slug recién disponible, añadir un flujo de trabajo con el nombre de archivo esperado, solicitar un token OIDC y presentar ese token a npm.

Si el paquete configurado nunca había completado su primera publicación confiable, npm podía aceptar el nombre del repositorio como una coincidencia y emitir una credencial de publicación válida. El atacante podría entonces lanzar una nueva versión bajo el nombre del paquete legítimo de npm.

Esto difiere del robo de tokens utilizado en muchos compromisos anteriores de npm. Tal como se explicó en la cobertura sobre las mejoras de seguridad de npm de GitHub, la Publicación Confiable fue diseñada para reducir la exposición de los tokens de automatización de larga duración.

SlugFest demostró que una credencial segura de corta duración aún puede ser abusada cuando la vinculación de identidad detrás de ella depende de un nombre reutilizable en lugar de un identificador inmutable.

Por qué los agentes de codificación de IA aumentan la exposición

La investigación de Bloom también se centró en el creciente papel de los agentes de codificación de IA en la instalación de paquetes. La empresa descubrió que un endpoint típico instala alrededor de 70 paquetes al mes a través de agentes de IA, mientras que los sistemas de desarrolladores pueden instalar cerca de 350 paquetes por mes.

Estas cifras cubren las instalaciones directas y no incluyen las dependencias adicionales que arrastra cada paquete. Herramientas como los asistentes de codificación y los agentes integrados en IDE pueden elegir, instalar y ejecutar paquetes con muy poca revisión humana.

Si una dependencia legítima es reemplazada silenciosamente por una versión maliciosa, el agente puede seleccionar la versión más reciente y ejecutar sus scripts de ciclo de vida como parte de una tarea de configuración normal. Esto hace que la procedencia del paquete, el anclaje de versiones (version pinning) y la revisión de los scripts de instalación sean más importantes que nunca.

La preocupación también se conecta con los riesgos de seguridad de los agentes de codificación de IA reportados a principios de este año, donde el contenido manipulado podría influir en un agente para ejecutar comandos controlados por un atacante.

En el caso de SlugFest, el paso peligroso no es solo un prompt: es la posibilidad de que un agente instale un paquete que ha sido publicado a través de una ruta de lanzamiento aparentemente confiable.

Bloom reportó el problema a través del programa HackerOne de GitHub el 6 de junio de 2026. El problema fue validado el 9 de junio, y los investigadores dijeron que se implementó una solución el 2 de octubre, después de más de 120 días.

Ahora, GitHub hace que las configuraciones de Publicación Confiable recién creadas pero no validadas expiren después de 48 horas. Una configuración se valida solo después de su primera publicación exitosa, lo que luego la vincula a la identidad inmutable del repositorio.

GitHub también bloquea los tokens de Publicación Confiable activados por eventos issue_comment, además de su restricción existente sobre los eventos pull_request_target.

Los mantenedores que utilicen flujos de trabajo afectados deben trasladar la publicación a eventos más seguros, como push, release o workflow_dispatch. La documentación actual de Publicación Confiable de npm confirma que una nueva configuración debe completar su primera publicación exitosa en dos días o expirará.

Tú, como mantenedor de paquetes, deberías revisar cada configuración de Publicador Confiable, verificar que cada repositorio de GitHub vinculado esté todavía bajo tu control, y eliminar y recrear las vinculaciones después de renombrar, eliminar o transferir un repositorio.

Los equipos también deben monitorear la actividad de lanzamiento inesperada, anclar las versiones de las dependencias donde sea práctico y revisar cuidadosamente las atestaciones de procedencia.

Como demostró el incidente de publicación confiable de ChainDrop, una procedencia válida puede mostrar dónde se construyó un paquete, pero no prueba que el repositorio fuente, la cuenta o el entorno de construcción fueran seguros.