GhostAction vuelve: workflows falsos roban claves en GitHub

Las empresas de seguridad StepSecurity y Socket publicaron el 9 de octubre de 2026 el análisis de una nueva oleada de GhostAction. El 8 de octubre, dos cuentas robadas de GitHub metieron un falso workflow «Security Audit» en unos 345 repositorios. Roba secretos y claves, también de IA. Afecta a quien guarda el código de su web en GitHub.

Lo que se sabe

  • Quién lo cuenta: StepSecurity y Socket, dos empresas que venden herramientas de seguridad para el desarrollo de software, en análisis del 9 de octubre de 2026. Son investigaciones de terceros. Ninguna recoge una respuesta de GitHub.
  • Qué pasó: el 8 de octubre, alguien usó las cuentas de dos mantenedores conocidos para añadir un archivo de GitHub Actions, `security-audit.yml`, directamente en la rama principal de sus repositorios. Fueron 27 repositorios desde una cuenta, a partir de las 13:20 UTC, y 318 desde la otra, entre las 21:10 y las 21:26 UTC, según StepSecurity. Entre ellos están el motor de juegos pyxel y un repositorio de Uber.
  • Cuántos: StepSecurity cuenta 345 repositorios; Socket, 346.
  • Qué hace el archivo: se presenta como una auditoría de seguridad y no audita nada. Envía a un servidor del atacante los secretos de GitHub Actions del repositorio y las credenciales que encuentra en el código y en todo el historial de git. Busca 13 patrones: claves de AWS, de Anthropic, OpenAI y OpenRouter, tokens de GitHub y GitLab, y claves de Google, Slack y SendGrid.
  • La novedad: el barrido del historial. Una clave que se subió una vez y se borró al día siguiente sigue ahí y sale igual, explica StepSecurity.
  • Cómo entran: con la credencial de un mantenedor. StepSecurity cree que lo más plausible es un token personal filtrado. Socket dice que no observó cómo.
  • Alcance: el 9 de octubre, una búsqueda de StepSecurity daba 378 repositorios con el archivo activo en su rama principal, sin contar los forks. Socket añadió después que ve más de 500 cuentas y decenas de miles de repositorios desde el 7 de octubre. Es su cifra y no da el desglose.
  • Lo que no ha pasado: ninguna de las dos vio versiones maliciosas de paquetes publicadas con las credenciales robadas. StepSecurity avisa de que eso no prueba que estén a salvo.
  • Antecedente: la campaña viene de septiembre de 2025, cuando robó más de 3.000 secretos de 817 repositorios, según StepSecurity.

Qué cambia y qué no

Cambia el remedio. Antes bastaba con cambiar los secretos configurados en GitHub Actions. Con el barrido del historial, StepSecurity da por comprometida cualquier credencial que alguna vez estuvo en un commit, aunque se borrara.

Cambia también el botín: las claves de IA pasan a ser objetivo de primera. Socket explica por qué: sirven para revender uso que se factura y dan acceso a los datos que pasan por esa clave.

La escala, por la cuenta de este artículo sobre las cifras de StepSecurity: de los 378 repositorios, 182 llevan el barrido de historial (el 48 %) y 88 envían secretos con nombre (el 23 %).

No cambia la vía de entrada. No es un fallo de GitHub: son cuentas robadas. Y la protección automática no basta. GitHub retiene desde el 28 de julio de 2026 las ejecuciones que identifica como sospechosas, pero solo en repositorios públicos, según su registro de cambios. En esta oleada el archivo se ejecutó con éxito en repositorios públicos como pyxel, según StepSecurity. El código de la web de un negocio suele estar en repositorios privados, que esa retención no cubre.

Cómo saber si te afecta

Te afecta si el código de tu web, tu tienda o tu aplicación está en GitHub, aunque el repositorio sea privado y aunque lo lleve un proveedor. Siete pasos:

  1. Pregunta a quien desarrolla tu web: «¿Nuestro código está en GitHub? ¿Quién tiene permiso de escritura?». Cada cuenta con ese permiso es una puerta.
  2. Abre la carpeta `.github/workflows/` de cada repositorio. StepSecurity cita tres nombres de archivo: `security-audit.yml`, `github_actions_security.yml` y `security-check.yml`. Uno que nadie del equipo añadió es la señal.
  3. Mira la pestaña «Actions». Una ejecución terminada de «Security Audit» o de «Github Actions Security» desde el 31 de agosto de 2026 se trata como robo confirmado, según StepSecurity.
  4. Si aparece, cambia todo: los secretos de Actions y cualquier credencial que alguna vez estuvo en el repositorio. Empieza por lo que cuesta dinero o publica en tu nombre: claves de IA, de la nube y de envío de correo. El orden es una recomendación de este artículo.
  5. Revoca el token o la sesión de la cuenta que hizo el commit y borra el archivo de todas las ramas, no solo de la principal. Cambiar secretos no basta si la entrada sigue abierta.
  6. Revisa el consumo de tus claves de IA en el panel del proveedor y ponles un límite de gasto si lo permite. Es una precaución de este artículo.
  7. Para prevenir, StepSecurity recomienda exigir aprobación para ejecutar workflows y que los cambios en `.github/workflows/` pasen por revisión. Vio que esa aprobación frenó el robo en un repositorio.

Las búsquedas exactas para revisar toda una organización están en el análisis de StepSecurity.

Relacionado: Anuncio de Google con dominio bing.com lleva a un Claude falso

Fuentes

Actualizaciones: aquí se añadirá si GitHub se pronuncia sobre esta oleada o si aparece una versión maliciosa de algún paquete afectado.