Tres minutos en tu sistema y todas las claves de acceso acaban en un servidor externo: ciberdelincuentes hallan nuevo método de ataque vía GitHub Actions

Una modificación casi imperceptible en una etiqueta convirtió la popular herramienta de comprobación de seguridad en una puerta trasera. Un atacante comprometió la acción oficial de GitHub (GitHub Action) Xygeni e implantó una shell completa de control remoto que podía ejecutar cualquier comando en los servidores de compilación. Los especialistas de StepSecurity describieron detalladamente el incidente, que ocurrió el 3 de marzo de 2026.

Un desconocido obtuvo acceso a las credenciales de los mantenedores del proyecto Xygeni e inyectó código malicioso en el repositorio xygeni/xygeni-action – la acción oficial para GitHub que usan más de 137 repositorios. El problema principal era que el atacante no modificó los archivos de trabajo de los usuarios. En lugar de eso, redirigió silenciosamente la etiqueta de versión v5 a un commit malicioso. Cualquier proyecto cuyo flujo de trabajo indique xygeni/xygeni-action@v5 comenzó a ejecutar la puerta trasera inyectada.

El código malicioso se ocultó como un paso «recolectar la telemetría de la versión del escáner». El script se añadió al archivo action.yml entre la instalación del escáner y la comprobación principal. A primera vista el paso parecía inofensivo: mostraba información sobre la versión de la herramienta. En realidad el código iniciaba una shell oculta de control remoto.

Al ejecutarse, la acción se registraba en el servidor de comando en la dirección 91.214.78.178, enviaba el nombre del host, el nombre de usuario y la versión del sistema operativo, y luego comprobaba cada pocos segundos si había comandos. Los comandos recibidos se ejecutaban mediante eval, y el resultado se comprimía y se enviaba de vuelta al servidor. El script se ejecutaba en segundo plano, por lo que el proceso principal de comprobación de seguridad continuaba como de costumbre y no despertaba sospechas.

En tres minutos de ejecución, el atacante podía ejecutar cualquier comando en el servidor de compilación. Entre las acciones posibles estaba el robo de variables de entorno, incluidos tokens de GitHub y claves de acceso, la lectura del código fuente o la sustitución de artefactos de compilación.

El ataque fue más sofisticado que una inyección de código mediante una solicitud de extracción. En el repositorio sí aparecieron tres solicitudes de extracción con el mismo código malicioso, pero ninguna fue aceptada. En vez de eso, el atacante simplemente movió la etiqueta v5 al commit malicioso. Esa etiqueta se puede cambiar en cualquier momento, y la mayoría de usuarios especifica en la configuración únicamente el número de la versión mayor.

Por este esquema, miles de proyectos pudieron empezar a ejecutar código malicioso sin ningún cambio en sus archivos. En la configuración del flujo de trabajo seguía apareciendo la línea uses: xygeni/xygeni-action@v5, aunque el código real de la acción ya había cambiado.

Los registros del repositorio muestran que los cambios maliciosos provinieron desde dentro de la organización. Las solicitudes de extracción las crearon tres orígenes diferentes: la cuenta del mantenedor nico-car, la cuenta del empleado con la firma felix.carnicero@xygeni.io y la aplicación de servicio de GitHub xygeni-onboarding-app-dev[bot]. Todas las acciones ocurrieron aproximadamente en veinte minutos. Esta secuencia indica la compromisión de credenciales o claves de acceso, no acciones de un atacante interno.

Los mantenedores del proyecto pronto cerraron las solicitudes de extracción maliciosas y eliminaron los flujos de trabajo del repositorio. Sin embargo, la etiqueta v5 siguió apuntando al commit infectado. A fecha del 9 de marzo se aconseja a los usuarios actualizar urgentemente a la versión v6.4.0 o fijar un commit concreto en lugar de usar la etiqueta.

El ataque a Xygeni volvió a evidenciar la fragilidad de la cadena de suministro en GitHub Actions. Las etiquetas de versión se pueden modificar, por lo que mover una etiqueta puede sustituir el código para todos los usuarios de una acción. Un esquema similar ya se utilizó en 2025 en el ataque a la acción tj-actions/changed-files, cuando los atacantes obtuvieron acceso a los secretos de miles de repositorios. La principal protección en estos casos es vincular las acciones de GitHub no a etiquetas, sino a identificadores de commit concretos. Un commit no se puede cambiar retroactivamente, por lo que la sustitución de código mediante el movimiento de una etiqueta se vuelve imposible.