El 8 de octubre, la campaña de malware GhostAction volvió a golpear GitHub Actions: en dos oleadas automatizadas de apenas minutos, los atacantes comprometieron las cuentas de dos mantenedores con buena reputación — henrywoo y kitao — y usaron su acceso para empujar un workflow malicioso a 345 repositorios, incluido kitao/pyxel (más de 18.000 estrellas, con publicaciones en PyPI y crates.io) y el repositorio corporativo uber/athenadriver.

El mecanismo es siempre el mismo: el atacante no explota ninguna vulnerabilidad de software, sino que roba o reutiliza el acceso de un mantenedor para añadir un fichero a .github/workflows/ — esta vez con nombres como security-audit.yml o github_actions_security.yml, disfrazados de auditoría de seguridad rutinaria — que se ejecuta con los permisos del repositorio y manda a un servidor de control (la IP 193.32.204.199 en esta oleada) cualquier credencial que encuentre: claves de AWS, tokens de GitHub y GitLab, claves de API de Anthropic, OpenAI y OpenRouter, credenciales de GCP/Firebase, tokens de Slack y de SendGrid, entre otras 13 categorías distintas. La variante más reciente del script, además, recorre todo el historial de commits del repositorio buscando secretos que alguien dejó olvidados en un commit antiguo, no solo en las variables de entorno actuales.

No es un incidente aislado: la misma campaña ya había golpeado 772 repositorios públicos entre el 31 de agosto y el 30 de septiembre, robando 2.577 secretos con el mismo patrón de workflow inyectado. Para quien mantiene un proyecto propio en GitHub — con Actions corriendo en runners alojados por GitHub o, cada vez más habitual en un homelab, en un runner self-hosted — la exposición es la misma: cualquier secreto guardado como "repository secret" o cualquier clave de API con el alcance demasiado amplio (un token de GitHub clásico sin caducidad, por ejemplo) es un objetivo directo si la cuenta que mantiene el repo cae.

La mitigación no depende de parchear nada, sino de revisar hábitos: rotar cualquier secreto que haya pasado por un repositorio con un workflow sospechoso, auditar .github/workflows/ buscando ficheros que nadie del equipo recuerde haber añadido, activar el escaneo de secretos con push protection de GitHub, exigir revisión obligatoria para cambios en workflows propuestos por colaboradores externos o de primera contribución, y — el cambio de fondo que de verdad corta el vector — sustituir los tokens de larga duración guardados como secretos por autenticación OIDC de corta duración siempre que el proveedor (AWS, GCP, npm…) lo soporte.

Fuentes: socket.dev · blog.gitguardian.com · stepsecurity.io