El ataque a la cadena de suministro GhostAction compromete más de 340 repositorios de GitHub mediante dos cuentas de mantenedores

Una nueva oleada del ataque a la cadena de suministro GhostAction comprometió dos conocidas cuentas de mantenedores de Open Source el 8 de octubre de 2026 y utilizó su acceso de escritura para plantar un workflow de GitHub Actions diseñado para robar credenciales en más de 340 repositorios en cuestión de minutos, según una investigación publicada por StepSecurity.

La primera cuenta pertenecía al desarrollador del motor de videojuegos pyxel, un proyecto con cerca de 18.400 estrellas en GitHub. Fue utilizada para enviar el workflow malicioso a 27 repositorios entre las 13:20 y las 13:44 UTC. Ocho horas después, una segunda cuenta comprometida —perteneciente al autor original de la biblioteca Open Source athenadriver de Uber— envió el mismo workflow a 318 repositorios, incluyendo 39 proyectos fuente y 279 forks, en una ventana de apenas 16 minutos. El acceso llegó hasta la propia organización de GitHub de Uber antes de que la empresa pudiera intervenir.

Los workflows de GitHub Actions se han convertido en un objetivo predilecto para los atacantes de cadenas de suministro, ya que una sola cuenta de mantenedor comprometida puede inyectar silenciosamente automatización maliciosa en todos los repositorios a los que esa cuenta tiene acceso de escritura, y dicha automatización se ejecuta con la confianza y las credenciales ya configuradas para el proyecto. La campaña GhostAction original, identificada en septiembre de 2025, robó más de 3.300 secretos de 817 repositorios vinculados a 327 desarrolladores. Esta segunda oleada reutilizó el mismo esquema a mayor escala y contra objetivos de mayor perfil.

Los archivos inyectados —denominados security-audit.yml y una variante anterior llamada github_actions_security.yml— estaban camuflados como trabajos rutinarios de escaneo de seguridad. Una vez activados, rastreaban tanto el árbol de trabajo como el historial completo de git, incluidos los archivos eliminados, en busca de 13 categorías de credenciales: claves de acceso y tokens de sesión de AWS, API keys de Anthropic, OpenAI y OpenRouter, tokens de GitHub y GitLab, claves de Google y Firebase, tokens de bots de Slack y credenciales de SendGrid. También recopilaban secretos con nombre ya configurados en los workflows de cada repositorio, como tokens de publicación de PyPI y Cargo. Todo lo encontrado era enviado en texto plano a un servidor de mando y control codificado de forma fija.

A 9 de octubre, StepSecurity encontró 378 repositorios que todavía albergaban el workflow malicioso activo en su rama principal, con evidencia confirmada de que secretos con nombre habían sido exfiltrados de al menos 88 de ellos. En el momento de publicarse la investigación no había aparecido ninguna versión maliciosa de paquetes vinculada a las credenciales de publicación robadas, pero la firma advirtió que cualquier repositorio que muestre una ejecución completada del workflow debe tratarse como una brecha confirmada.

El incidente es un recordatorio de que la confianza en el ecosistema Open Source recae en cuentas individuales de mantenedores y no en las organizaciones: el repositorio de Uber fue afectado no porque Uber fuera un objetivo directo, sino porque las credenciales comprometidas de un colaborador externo resultaron tener acceso a él. StepSecurity insta a cualquier persona que mantenga proyectos afectados a rotar todas las credenciales que hayan sido incluidas en alguna rama —ya que el paso de minería del historial del ataque lee secretos eliminados hace tiempo—, revocar las sesiones comprometidas, eliminar el workflow de todas las ramas y forks, y exigir Code Review mediante Pull Request antes de cualquier cambio en el directorio .github/workflows de un repositorio.