Campaña GhostAction inyecta workflows maliciosos en miles de repositorios de GitHub para robar credenciales

El 8 y 9 de octubre de 2026 la campaña GhostAction comprometió cuentas de mantenedores de alto perfil y empujó un workflow disfrazado de auditoría de seguridad a cientos de repositorios, y posteriormente a miles, para exfiltrar secretos de GitHub Actions, claves de nube y credenciales de proveedores de IA presentes en el árbol de trabajo y en el historial completo de git.

StepSecurity y Socket documentaron una oleada concreta el 8 de octubre. La cuenta de Takashi Kitao, autor del motor de juegos pyxel con más de 18.000 estrellas, inyectó el fichero security-audit.yml en 27 repositorios a partir de las 13:20 UTC. Ocho horas después, la cuenta de Henry Wu (henrywoo), autor original de uber/athenadriver, hizo lo mismo en 318 repositorios en una ventana de 16 minutos. El commit llegó directamente a la rama por defecto bajo la identidad legítima del mantenedor, sin pull request ni revisión. A 9 de octubre Socket había identificado más de 500 cuentas que habían publicado el workflow en decenas de miles de repositorios desde el 7 de octubre.

El workflow se presenta como «Security Audit» o «Github Actions Security». Se dispara con workflow_dispatch o con cualquier push, hace un checkout con fetch-depth: 0 y ejecuta un único paso que realiza cuatro acciones: incluye los secretos nominados de GitHub Actions que el atacante había reconocido previamente, barre el árbol de trabajo con trece patrones de credenciales (claves AWS, tokens de Anthropic, OpenAI y OpenRouter, PATs de GitHub y GitLab, claves de Google/Firebase, Slack y SendGrid), recorre el historial completo de git con git log -p --all para recuperar secretos que se hubieran borrado, y empareja identificadores de claves AWS con su contexto circundante. Todo se envía en claro por HTTP a la IP 193.32.204.199. En uber/athenadriver el run log confirmó que la exfiltración se completó.

La campaña no es nueva. En septiembre de 2025 ya había afectado a 817 repositorios y exfiltrado más de 3.000 secretos. Lo que cambia en esta oleada es el alcance: ya no se limita a los secretos configurados en Actions; ahora recolecta cualquier credencial que alguna vez se hubiera commitado, aunque se hubiera eliminado después. Rotar únicamente los secretos actuales de Actions no cubre la exposición. Además, los objetivos incluyen de forma explícita claves de proveedores de modelos de IA.

Para un responsable TIC de un centro educativo, una red concertada o una organización de tamaño medio el riesgo es concreto. Muchos equipos mantienen repositorios propios o de forks en GitHub, usan GitHub Actions para desplegar plataformas educativas, sitios web o scripts de automatización, y almacenan tokens de servicios cloud o de APIs de IA. Un workflow inyectado bajo la identidad de un mantenedor pasa desapercibido en los logs de auditoría normales. Si el repositorio es privado o contiene historial con claves antiguas, el impacto es mayor. Las forks también heredan el fichero y pueden ejecutarlo.

Las acciones prácticas son inmediatas y medibles. Buscar en los repositorios propios y de la organización los ficheros .github/workflows/security-audit.yml y github_actions_security.yml, o las cadenas AKIA_CTX_START, c=monami y la IP 193.32.204.199. Si aparece alguno, asumir compromiso: revocar el token o la cuenta de GitHub utilizada, rotar todos los secretos de Actions y cualquier credencial que haya estado en el historial, eliminar el workflow de todas las ramas y revisar las forks. Conviene también exigir revisión de pull request para cambios en workflows, limitar los permisos de los tokens de acceso personal y activar la protección de ramas en los repositorios que contengan secretos o que se usen para publicar paquetes.

El caso ilustra un patrón que se repite: el atacante no necesita vulnerabilidades nuevas; aprovecha credenciales filtradas de mantenedores y la confianza que genera un commit que parece un intento de mejora de seguridad. Un equipo que solo revisa el código de aplicación y no los workflows, o que reutiliza tokens de larga duración, queda expuesto. La respuesta no es abandonar GitHub Actions, sino tratar los workflows como código sensible, inventariar dónde se guardan secretos y tener un procedimiento de rotación que cubra también el historial.

GhostAction demuestra que la cadena de suministro de software abierto y de CI/CD sigue siendo un vector de bajo coste y alto rendimiento. Para quien gestiona repositorios, el primer paso es la búsqueda concreta de los indicadores descritos y la rotación preventiva de cualquier secreto que haya pasado por esos repositorios en el último año.