Si un día aparece en tu repositorio una automatización llamada «Security Audit» que tú no creaste, no es un regalo: es un ladrón. Una campaña conocida como GhostAction está metiendo archivos así en proyectos de GitHub para llevarse contraseñas y llaves de acceso.
El ataque abusa de GitHub Actions, el servicio de GitHub que ejecuta tareas automáticas como pruebas y despliegues cada vez que subes código.
¿Qué pasó?
La empresa de seguridad StepSecurity reportó el 9 de octubre de 2026 una nueva oleada. El 8 de octubre los atacantes usaron las cuentas comprometidas de dos mantenedores conocidos de código abierto y, en dos tandas automáticas de pocos minutos, subieron el archivo malicioso a 345 repositorios: 27 desde una cuenta y 318 desde la otra.
Los archivos se hacen pasar por revisiones de seguridad. Se llaman security-audit.yml, github_actions_security.yml o security-check.yml y viven en la carpeta de automatizaciones del repositorio. Como se suben directo a la rama principal con la identidad de la víctima, parecen cambios legítimos.
No es un caso aislado. Investigadores de GitGuardian, citados por GBHackers, documentaron la misma campaña entre el 31 de agosto y el 30 de septiembre de 2026: 772 repositorios públicos de 373 usuarios y organizaciones, con 26 secretos robados de forma confirmada en 13 repositorios. Para el 5 de octubre solo el 16% de los repositorios afectados mostraba una limpieza efectiva.
¿Qué se roban?
Primero, los secretos configurados en GitHub Actions, que son las contraseñas y llaves que tu proyecto usa para publicar o desplegar. Entre lo que buscan hay llaves de AWS, tokens de GitHub y GitLab y llaves de servicios de IA como Anthropic, OpenAI y OpenRouter.
La novedad de esta oleada, según StepSecurity, es que el archivo también revisa todo el historial del repositorio. Eso significa que una llave que subiste por error hace años y luego borraste sigue estando al alcance del atacante.
StepSecurity cree que las cuentas se comprometieron con tokens personales filtrados, aunque no está confirmado. En uno de los proyectos quedaron expuestas las llaves para publicar paquetes, pero hasta el reporte no se había publicado ninguna versión maliciosa.
¿Por qué te importa?
Porque casi cualquier proyecto moderno, desde un sitio en Next.js hasta una API, guarda en GitHub las llaves de su hospedaje, su base de datos o su cuenta en la nube. Con ellas alguien puede entrar a tus servidores o generar cobros a tu nombre.
Además, los forks, que son las copias de un repositorio, heredan el archivo malicioso. Si copiaste un proyecto afectado, el archivo puede ejecutarse con tus propias credenciales.
¿Qué puedes hacer?
- Busca en tus repositorios, en todas las ramas, archivos de automatización con esos nombres que tú no hayas creado, sobre todo si aparecieron desde el 31 de agosto de 2026.
- Si encuentras uno, bórralo de todas las ramas y cambia todas las llaves: los secretos de Actions y cualquier credencial que alguna vez haya estado en el historial.
- Revoca tus tokens personales de GitHub y crea nuevos con los permisos mínimos y con fecha de vencimiento. Activa la verificación en dos pasos.
- Activa en la configuración del repositorio la aprobación manual antes de ejecutar automatizaciones. StepSecurity vio que ese control detuvo el robo en un repositorio.
- Protege la rama principal para que nadie pueda subir cambios directos sin revisión.