La vulnerabilidad SlugFest permitía heredar permisos de publicación reclamando nombres de repositorio abandonados en GitHub — npm parcheó el 2 de octubre con expiración de 48 horas para configuraciones no validadas
Investigadores de Boom Security identificaron una falla en el mecanismo de Trusted Publishing de npm que permitía a un atacante tomar control de paquetes legítimos sin comprometer credenciales ni cuentas de los mantenedores originales. La vulnerabilidad, denominada SlugFest, afectaba a más de 1.500 paquetes con más de 10 millones de descargas combinadas y más de un millón de descargas mensuales — entre ellos escáneres de seguridad, herramientas de autenticación y paquetes criptográficos. Boom Security confirmó que la falla fue explotada exitosamente en condiciones de prueba controladas para publicar una nueva versión de un paquete existente, aunque no se ha observado explotación activa en la naturaleza. npm lanzó un parche el 2 de octubre que introduce una expiración de 48 horas para configuraciones de Trusted Publishing no validadas.
Cómo un nombre de repositorio reciclado otorgaba permisos de publicación sin validar identidad permanente
El mecanismo de Trusted Publishing de npm permite a los mantenedores publicar versiones a través de flujos automatizados usando OpenID Connect (OIDC), evitando credenciales de larga duración. Sin embargo, Boom Security descubrió que la configuración de confianza de npm se basaba en el nombre legible del repositorio GitHub (formato owner/repository) en lugar del identificador numérico permanente del repositorio. Cuando un repositorio es renombrado, transferido o eliminado, su nombre anterior queda disponible para que otro usuario lo reclame.
Un atacante podía crear un repositorio en esa dirección y configurar un flujo de GitHub Actions con el nombre de archivo esperado. Como npm verificaba el nombre del repositorio y el nombre del archivo de flujo sin validar el identificador permanente del repositorio, el atacante podía obtener una credencial de publicación válida para un paquete que no poseía. Los investigadores demostraron el ataque contra un paquete controlado por ellos mismos, publicando una nueva versión desde un repositorio GitHub perteneciente a una organización diferente — sin comprometer la cuenta de GitHub o npm del mantenedor legítimo ni robar sus credenciales.
El escaneo completo del registro reveló exposición en paquetes con más de 200.000 descargas mensuales individuales
El escaneo de Boom Security a nivel de registro identificó más de 1.500 paquetes potencialmente vulnerables. Uno de los paquetes individuales registraba más de 200.000 descargas mensuales. La naturaleza de los paquetes afectados — escáneres de seguridad, herramientas de autenticación, paquetes criptográficos — amplificaba el riesgo: estos componentes suelen ejecutarse con privilegios elevados o manejar datos sensibles durante la instalación o el tiempo de ejecución.
Una versión maliciosa podía ejecutar código controlado por el atacante a través de un hook de instalación cuando desarrolladores o sistemas de integración continua instalaban el paquete comprometido. El investigador de Boom Security Golan Myers confirmó que el equipo de npm validó que el parche fue implementado el 2 de octubre. Además de la expiración de 48 horas para configuraciones no validadas, npm endureció sus salvaguardas rechazando tokens de trusted-publishing emitidos a través de eventos issue_comment de GitHub Actions, sumándose a la restricción ya existente sobre eventos pull_request_target.
Por qué los agentes de IA aceleran la distribución de dependencias maliciosas sin intervención humana explícita
Boom Security argumenta que los agentes de codificación basados en IA pueden acelerar la distribución de dependencias maliciosas porque seleccionan e instalan paquetes de software con intervención humana limitada. A través de mediciones en docenas de organizaciones, los investigadores registraron aproximadamente 70 paquetes instalados por agentes por endpoint cada mes, aumentando a alrededor de 350 en máquinas de desarrolladores — cifras que cubren instalaciones directas y excluyen dependencias transitivas.
Un paquete secuestrado podía introducirse en un proyecto sin que un desarrollador lo seleccionara explícitamente: el agente de IA lo elegiría como dependencia basándose en criterios automatizados. Golan Myers resumió la implicancia: un paquete secuestrado ya no necesita encontrar a un desarrollador — solo necesita ser el paquete que un agente elige. Esta dinámica transforma el modelo de ataque de cadena de suministro: la superficie de exposición ya no está limitada por decisiones humanas conscientes de instalación, sino por los criterios de selección automatizada de herramientas que operan a escala y velocidad superiores.
Exposición estructural en América Latina por dependencia de npm en pipelines de CI/CD sin auditoría de configuraciones de confianza
La adopción de npm como registro de paquetes estándar en equipos de desarrollo de Argentina, Brasil, México, Chile y Colombia — particularmente en startups fintech, plataformas de e-commerce y equipos de desarrollo de aplicaciones móviles — implica que la vulnerabilidad SlugFest afectaba a organizaciones de la región con la misma exposición que a nivel global. La falta de auditoría sistemática de configuraciones de Trusted Publishing en pipelines de integración continua — práctica común en equipos con recursos de seguridad limitados — dejaba a estas organizaciones expuestas a la herencia de permisos de publicación a través de nombres de repositorio reciclados.
La medición de Boom Security sobre instalación automatizada de paquetes por agentes de IA (70 por endpoint mensual, 350 en máquinas de desarrolladores) sugiere que equipos en la región que adoptaron herramientas de asistencia de código basadas en IA — como GitHub Copilot, Amazon CodeWhisperer o soluciones locales — enfrentaban un vector de distribución acelerada de dependencias comprometidas sin revisión humana explícita. Aunque no hay datos específicos de explotación en LATAM reportados por Boom Security, la exposición estructural era equivalente a la de cualquier organización que usara npm con Trusted Publishing configurado sobre nombres de repositorio en lugar de identificadores permanentes.
Nuestro análisis
SlugFest revela un patrón recurrente en sistemas de confianza basados en identificadores mutables: la validación de identidad sobre nombres legibles por humanos en lugar de identificadores permanentes introduce una ventana de ataque cuando esos nombres pueden ser reciclados. Este caso se suma a precedentes documentados en otros ecosistemas de paquetes donde la reutilización de nombres (typosquatting, namespace confusion, dependency confusion) ha sido explotada para inyectar código malicioso — pero SlugFest introduce una variante distinta: el atacante no necesita registrar un nombre similar ni confundir al desarrollador, simplemente hereda la confianza ya establecida por el mantenedor original al reclamar un nombre de repositorio abandonado. La corrección de npm (expiración de 48 horas para configuraciones no validadas, rechazo de tokens emitidos por eventos issue_comment) mitiga la ventana de exposición, pero no elimina el riesgo residual en configuraciones de confianza ya establecidas antes del parche — Boom Security recomienda que los mantenedores auditen sus configuraciones, verifiquen que cada nombre de repositorio de confianza todavía resuelve a un repositorio bajo su control, y eliminen y recreen vínculos donde sea necesario.
La medición de Boom sobre instalación automatizada de paquetes por agentes de IA (70-350 por endpoint mensual) introduce una variable nueva en el modelo de riesgo de cadena de suministro: la velocidad y escala de adopción de dependencias sin revisión humana explícita transforma el ataque de un problema de ingeniería social (convencer a un desarrollador de instalar un paquete) a un problema de selección automatizada (ser el paquete que un agente elige según criterios de popularidad, compatibilidad o documentación). Lo que todavía no se sabe es qué proporción de los más de 1.500 paquetes vulnerables identificados por Boom Security tenía configuraciones de Trusted Publishing activas antes del parche del 2 de octubre, cuántos de esos paquetes corresponden a repositorios cuyos nombres ya fueron abandonados y están disponibles para reclamo, y si algún atacante ya reclamó alguno de esos nombres entre la fecha de abandono y la fecha del parche — información que determinaría si la ventana de exposición fue puramente teórica o si hubo oportunidad real de explotación no detectada. ¿Qué pasaría si un atacante ya reclamó un nombre de repositorio abandonado antes del 2 de octubre y está esperando el momento óptimo para publicar una versión maliciosa que los agentes de IA distribuirían a escala sin intervención humana?