Hackers llevaron a cabo una campaña coordinada de inyección de comandos contra 61 repositorios públicos de GitHub con el objetivo de robar datos de sistemas de desarrollo automatizados. Investigadores de Radware detectaron 83 elementos maliciosos (problemas, solicitudes de extracción y comentarios) el 1 de septiembre de 2026, confirmando que se ejecutaron comandos dentro de dos flujos de trabajo de GitHub Actions.

Unos hackers atacaron 61 repositorios públicos de GitHub en una campaña coordinada de inyección de comandos diseñada para robar datos de sistemas de desarrollo automatizados.

Investigadores de Radware identificaron 83 problemas, solicitudes de extracción (pull requests) y comentarios maliciosos publicados el 1 de septiembre de 2026, con evidencias de que los comandos inyectados se ejecutaron dentro de dos flujos de trabajo de GitHub Actions. Los hallazgos muestran cómo las discusiones rutinarias de un proyecto pueden convertirse en puntos de entrada a los sistemas de construcción de software.

Según la investigación de Radware, 77 elementos maliciosos aparecieron en unos 43 minutos. Seis más siguieron en una segunda ola que duró aproximadamente dos minutos.

Los objetivos incluyeron Google LangExtract, Trivy, Brave Browser, MLflow, ToolJet y PX4-Autopilot. Su inclusión no significa que todos los proyectos hayan sido vulnerados.

La campaña explotó flujos de trabajo que colocaban texto controlado por el usuario directamente en scripts de shell. GitHub Actions puede responder automáticamente cuando alguien abre un problema, envía una solicitud de extracción o publica un comentario. Estas tareas pueden verificar títulos, asignar etiquetas o enviar notificaciones.

Atacan 61 repositorios de GitHub

Los atacantes colocaron expresiones de sustitución de comandos de Bash, escritas como $(), dentro de ese contenido. Cuando un flujo de trabajo vulnerable insertaba el texto en el código de shell ejecutable, Bash trataba la expresión incrustada como un comando en lugar de texto ordinario. Envolver el título insertado en comillas dobles no evitó la ejecución.

La carga útil ejecutó env para recopilar variables de entorno, codificó la salida con Base64, eliminó los caracteres de nueva línea y utilizó curl para intentar una solicitud HTTP POST.

Cada carga útil verificada apuntaba a 54.205.16[.]142 en el puerto 8443, con un identificador de recolección separado para cada intento. A pesar del número de puerto, la conexión utilizaba HTTP en lugar de HTTPS.

El riesgo dependía de a qué pudiera acceder cada trabajo. Las variables de entorno podrían contener tokens de servicio, credenciales de despliegue o configuraciones internas.

Los secretos de GitHub Actions no están disponibles automáticamente para cada flujo de trabajo, por lo que la ejecución por sí sola no establece que se hayan robado credenciales sensibles.

En PX4-Autopilot, una solicitud de extracción que se hacía pasar por una corrección de documentación llevaba la carga útil en su título. Un flujo de trabajo de verificación de títulos insertó dicho título en un comando de Bash que invocaba Python. Los registros mostraron una advertencia de sustitución de comandos y devolvieron contenido que comenzaba con GIF89a, reemplazando la expresión maliciosa.

En Snouzy/workout-cool, un flujo de trabajo de notificación de problemas insertó el título del atacante directamente en una asignación de variable de Bash. Una advertencia vinculada a esa línea confirmó la sustitución de comandos. Una solicitud posterior a Discord falló porque su cuerpo contenía un JSON inválido, aunque ese fallo no probó que el robo de datos hubiera sido exitoso.

Radware no confirmó el robo de secretos, el acceso de escritura al repositorio, cambios en el código fuente o versiones comprometidas. Los investigadores también encontraron indicios de que algunas cuentas participantes podrían haber sido secuestradas, incluyendo a un propietario que negó públicamente haber abierto un problema malicioso.

Los hallazgos complementan informes anteriores sobre el robo de credenciales de GhostAction y el ataque a la cadena de suministro de tj-actions. Aquellos incidentes utilizaron rutas diferentes pero también pusieron en riesgo los secretos de CI/CD.

Si eres mantenedor, deberías pasar los títulos no confiables a través de variables de entorno en lugar de insertarlos en el código fuente de shell, evitar el uso de eval y limitar los permisos del flujo de trabajo.

Si tú y tu equipo encuentran evidencia de ejecución, deberían revisar los secretos disponibles, rotar las credenciales potencialmente expuestas, inspeccionar los registros de auditoría e investigar el tráfico saliente inesperado. Mantén los trabajos de notificación separados de los flujos de trabajo de lanzamiento privilegiados para reducir el daño que podría causar un comando inyectado.