GitHub Tightens npm Publishing After Flaw Left 1,500+ Packages Vulnerable to Hijacking
The Hacker News · 13 oct, 18:18
GitHub ha ajustado sus configuraciones de publicación de confianza en npm tras descubrir que atacantes podían tomar el control de miles de paquetes sin robar credenciales. La vulnerabilidad, llamada SlugFest, explotaba un fallo en cómo npm identificaba repositorios: usaba el nombre del repositorio en lugar de su identificador inmutable, permitiendo que alguien reclame un slug abandonado e herede la confianza del paquete original. El fallo afectaba más de 1.500 paquetes descargados más de 10 millones de veces en total.
El ataque funcionaba porque npm almacenaba la dirección del repositorio (owner/repository) en lugar del identificador numérico permanente que GitHub asigna. Cuando un mantenedor renombraba, transfería o eliminaba su repositorio, alguien podía crear uno nuevo con el mismo slug y heredar automáticamente la confianza para publicar versiones del paquete legítimo. El ataque se ejecutaba en cuatro pasos: reclamar el slug liberado, crear un flujo de publicación que generara un token OIDC, intercambiar ese token por credenciales de publicación en npm, y subir código malicioso con el nombre original del paquete.
La investigación de Bloom Security destacó que los agentes de IA en máquinas de desarrolladores complicaban el problema: estos resuelven dependencias automáticamente, tienden a elegir la versión más reciente sin verificar la procedencia, y raramente interviene un humano. Un paquete malicioso publicado mediante un slug reclamado hereda el historial de descargas, reputación y relaciones de dependencia, amplificando el impacto de la cadena de suministro. La solución de GitHub obliga a validar las configuraciones de publicación confiable en el primer intento; también rechaza tokens de eventos issue_comment y pull_request_target en GitHub Actions.
Puntos clave
- Más de 1.500 paquetes npm vulnerables a hijacking sin robo de credenciales
- El fallo usaba el slug del repositorio en lugar del identificador numérico inmutable
- Configuraciones de publicación confiable deben validarse en las primeras 48 horas
- Agentes de IA automáticos aumentan el riesgo al tirar dependencias sin verificación de origen