Atacantes que tomaron el control de unas 1.900 cuentas de GitHub colaron flujos de trabajo que roban credenciales en más de 30.000 repositorios, según GitGuardian. La campaña, bautizada GhostAction, buscaba llaves de servicios en la nube, accesos de despliegue y claves de proveedores de IA como Anthropic, OpenAI y OpenRouter, de acuerdo con The New Stack.
La ola más fuerte llegó el 8 y el 9 de octubre. Los atacantes alcanzaron repositorios de unos 3.000 usuarios y organizaciones e intentaron extraer 3.174 secretos. GitGuardian aclara que esa es la cifra de secretos buscados, no de los que llegaron a manos de los atacantes: el total robado sigue sin conocerse.
No hubo una falla en GitHub. Los atacantes usaron credenciales robadas de desarrolladores para editar los flujos de GitHub Actions, el sistema que automatiza pruebas y despliegues. Cómo las consiguieron no está claro. StepSecurity apunta a tokens de acceso personal salidos de filtraciones anteriores, aunque no está confirmado.
GhostAction escondió el robo en una falsa auditoría de seguridad
El truco fue esconder el código malicioso en archivos con nombres como security-audit.yml. Como citaban secretos que las compilaciones legítimas ya usaban, el trabajo podía recogerlos y enviarlos por HTTP a un servidor de los atacantes.
La variante de octubre de GhostAction fue más lejos. Además de los secretos que citaba cada flujo, revisaba todo el historial de Git en busca de llaves de AWS, tokens de GitHub y GitLab, credenciales de Google y Firebase, y claves de Anthropic, OpenAI y OpenRouter. Eso incluye llaves borradas del código hace meses pero que seguían activas.
Para quien trabaja con IA, el riesgo es concreto: una clave de API permite usar el servicio a nombre de su dueño, y la factura le llega a él. En la ola de agosto y septiembre, GitGuardian contó 446 llaves SSH y 218 credenciales de Azure entre lo más buscado; las de proveedores de IA aparecían al final de la lista, sin cifra propia. Meta reconoció esta semana que una credencial robada le dio acceso a alguien a sus repositorios, y Vercel ya había sido hackeada a través de una app de IA en abril.
Por qué bloquear los flujos no alcanza
GitHub empezó a impedir que el flujo malicioso se ejecutara el 9 de octubre. Las oleadas del 10 y el 12 no lograron extraer secretos, según GitGuardian. Pero en agosto y septiembre los controles de aprobación de GitHub frenaron a la mayoría y aun así 26 secretos salieron de 13 repositorios. Los atacantes además reciclaron 92 flujos viejos que nadie había borrado, y al 5 de octubre solo 124 de 772 repositorios afectados, un 16 %, se habían limpiado.
GitGuardian advierte que las credenciales de GitHub robadas circulan entre varios grupos. Por eso no basta con rotar los secretos que salieron: hay que encontrar y revocar la credencial que permitió la intrusión, o alguien más la usará. Los equipos que usan GitHub deberían revisar qué cuentas modificaron la carpeta .github/workflows, revocar sus tokens y cambiar las llaves de nube y de IA, incluidas las que alguna vez estuvieron en el historial del repositorio.
GhostAction no es nueva. GitGuardian la documentó por primera vez en septiembre de 2025, cuando comprometió 817 repositorios y 3.325 secretos, y en 92 casos de esta ola los atacantes solo apuntaron flujos instalados entonces hacia un servidor nuevo.
Fuentes: The New Stack y GitGuardian.
