Una campaña coordinada de ataque a la cadena de suministro de software apuntó a 61 repositorios públicos de GitHub el 1 de septiembre de 2026. Según una investigación de la empresa de seguridad Radware, divulgada el 29 de octubre, los atacantes publicaron 83 elementos maliciosos —issues, pull requests y comentarios— con el objetivo de ejecutar comandos dentro de entornos de integración y entrega continuas (CI/CD) e intentar robar secretos de desarrollo.
Qué ocurrió
La actividad estuvo concentrada en el tiempo: 77 de los 83 elementos maliciosos se publicaron en unos 43 minutos, entre las 11:26 y las 12:10 UTC del 1 de septiembre. Una segunda oleada, con seis elementos, llegó más tarde ese mismo día. Entre los objetivos había proyectos conocidos como Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet y PX4-Autopilot, lo que no significa que todos esos proyectos fueran vulnerados: el impacto dependía de los permisos y la configuración de cada workflow.
Cómo funcionaba el ataque
El mecanismo era la inyección de comandos shell a través de contenido no confiable procesado por GitHub Actions. Los atacantes incrustaban expresiones de sustitución de comandos de Bash, escritas como $(), en títulos de issues y pull requests. Cuando un workflow insertaba ese contenido directamente en el código shell, Bash interpretaba la expresión como un comando a ejecutar.
El payload recopilaba las variables de entorno del proceso con el comando env, codificaba el resultado en Base64 e intentaba enviarlo por HTTP a un servidor controlado por los atacantes, en la dirección 54.205.16.142, puerto 8443. El ataque podía tener éxito aunque la issue o el pull request nunca se aprobara, nunca se fusionara o se cerrara minutos después de enviarse.
Lo confirmado — y lo que no se confirmó
Radware analizó registros de ejecuciones reales y encontró evidencia directa de que el comando malicioso se ejecutó dentro del entorno de automatización en dos casos: el pull request n.º 28488 de PX4-Autopilot y una issue del proyecto workout-cool. Por otro lado, la investigación no confirmó el robo de secretos, la obtención de permisos de escritura en los repositorios, la modificación de código fuente ni el compromiso de versiones distribuidas. Los secretos de GitHub Actions no están disponibles automáticamente para todos los workflows, y la ejecución del comando por sí sola no prueba que se exfiltraran credenciales.
Radware también identificó cuentas de GitHub con actividad legítima previa de desarrollo que se usaron para distribuir el ataque, además de un usuario que declaró públicamente no haber creado la actividad maliciosa que se le atribuía.
Qué deben hacer los mantenedores
Para los proyectos que usan GitHub Actions, la recomendación de los investigadores es no interpolar nunca contenido aportado por usuarios directamente en scripts shell: los valores deben pasarse mediante variables de entorno. Los mantenedores de repositorios públicos deben revisar las issues y los pull requests publicados el 1 de septiembre de 2026 y, por precaución, rotar las credenciales que pudieran haber quedado expuestas en entornos de CI/CD.
Lee también en Geekiki: Fallo de WordPress explotado durante las actualizaciones; CISA fija el 6 de noviembre como plazo.
Crédito de la imagen: ilustración de Radware, publicada en el blog oficial de la empresa sobre la investigación.
Fuentes
- Radware — Inside a GitHub Supply Chain Attack Campaign
- Cyber Security News — Hackers Target 61 GitHub Repositories With Command Injection Attacks to Steal CI/CD Secrets
- GitHub — PX4/PX4-Autopilot, Pull Request #28488
Transparencia: este artículo fue producido con ayuda de inteligencia artificial, a partir de fuentes públicas de internet, y revisado con base en las fuentes originales citadas abajo. Consulta siempre las fuentes originales para confirmar los detalles.
Muse
