Los repositorios restaurados de GitHub Actions reactivaron brevemente una carga maliciosa latente en la cadena de suministro
La restauración temporal de actions-cool reactivó etiquetas maliciosas de Mini Shai-Hulud y expuso secretos CI/CD el 16 de septiembre de 2026.
Imagen ilustrativa generada con IA
La restauración del acceso a los repositorios reactivó etiquetas maliciosas antiguas
Dos GitHub Actions mantenidas por actions-cool volvieron a estar accesibles brevemente el 16 de septiembre de 2026, lo que reactivó código malicioso que había quedado tras la campaña Mini Shai-Hulud.
Los repositorios afectados eran:
actions-cool/issues-helperactions-cool/maintain-one-comment
Ambos habían sido comprometidos inicialmente el 18 de mayo de 2026. Las etiquetas de sus versiones nunca se limpiaron por completo tras ese incidente y siguieron apuntando a contenido modificado por los atacantes.
Cuando se restableció el acceso a los repositorios, los flujos de trabajo que dependían de esas etiquetas de versión mutables pudieron volver a descargar y ejecutar la carga maliciosa. Los usuarios no tuvieron que modificar sus archivos de flujo de trabajo, y los atacantes no necesitaron publicar una nueva versión.
El investigador de Socket Karlo Zanki afirmó que los repositorios estuvieron disponibles desde las 11:09 hasta las 18:16 (GMT+2) del 16 de septiembre. Después, volvieron a deshabilitarse.
En el aviso de GitHub se indicaba que el personal había bloqueado el acceso por una infracción de las condiciones del servicio. Se desconoce por qué se volvieron a habilitar los repositorios o qué proceso permitió que las referencias maliciosas anteriores pudieran descargarse de nuevo.
Las etiquetas mutables convirtieron la restauración en ejecución de código
Los flujos de trabajo de GitHub Actions pueden cargar automatizaciones de terceros mediante referencias como esta:
uses: actions-cool/[email protected]
La referencia que aparece después de @ puede identificar una etiqueta de versión en lugar de un commit inmutable. Una etiqueta puede seguir apuntando a contenido comprometido —o redirigirse a otro contenido— sin que se modifique el flujo de trabajo que la utiliza.
Esta diferencia fue clave en el incidente. En cuanto GitHub restableció el acceso a los repositorios de actions-cool, los ejecutores pudieron resolver las etiquetas existentes y recuperar el código malicioso que ya estaba almacenado en los repositorios de origen.
La referencia actions-cool/[email protected] debe considerarse comprometida. No se ha revelado qué versión concreta de actions-cool/maintain-one-comment resultó afectada, por lo que las organizaciones deberían investigar todos los usos de esa Action en lugar de dar por segura una etiqueta determinada.
No hizo falta publicar código nuevo, cambiar la configuración del flujo de trabajo, explotar una vulnerabilidad ni usar infraestructura controlada por los atacantes. La mera disponibilidad de los repositorios bastó para reactivar la vía de distribución.
Los flujos de trabajo fijados al SHA completo de un commit de una versión de confianza anterior al 18 de mayo de 2026 no se vieron afectados. A diferencia de una etiqueta mutable, un hash de commit completo fija la dependencia a un estado concreto del repositorio.
La automatización rutinaria de incidencias generó oportunidades frecuentes de ejecución
Las Actions comprometidas realizan tareas habituales de mantenimiento de repositorios, como revisar las incidencias nuevas, cerrar las inactivas y mantener actualizado un único comentario automatizado.
Estos trabajos suelen configurarse para ejecutarse a diario o cuando se producen eventos, como la apertura de una incidencia o una solicitud de incorporación de cambios. Esa programación ofreció múltiples oportunidades para que los repositorios restaurados llegaran a los ejecutores de CI/CD durante las siete horas en que estuvieron disponibles.
Socket estimó que muchos repositorios dependientes podrían haber ejecutado la carga en el plazo de un día desde que las Actions volvieron a estar disponibles. No habría sido necesaria ninguna otra interacción por parte del actor de amenazas.
El código malicioso intentó recopilar credenciales disponibles en el entorno de CI/CD y transmitirlas a un servidor controlado por los atacantes. El indicador de exfiltración conocido es:
t.m-kosche[.]com
Por tanto, se debería investigar cualquier repositorio que ejecutara una de las dos Actions durante el periodo relevante para determinar si pudo haber una exposición de secretos. El impacto potencial va más allá del flujo de trabajo afectado, ya que las credenciales robadas podrían permitir el acceso a repositorios, sistemas de compilación o procesos de publicación de software.
Se desconoce qué credenciales concretas se recopilaron en cada entorno afectado. La exposición depende de los secretos y permisos a los que tuviera acceso el trabajo cuando se ejecutó la Action comprometida.
Las pruebas vinculan la actividad con Mini Shai-Hulud
El incidente está relacionado con el clúster de actividad Mini Shai-Hulud, que también afectó a paquetes npm del ecosistema @antv.
Philipp Burckhardt, responsable de inteligencia sobre amenazas de Socket, evaluó que el dominio de exfiltración compartido vinculaba el compromiso de GitHub Actions y la actividad en npm con el mismo clúster. Según esa evaluación, la coincidencia no justificaba tratar el componente de npm como un incidente separado.
En este caso, el mecanismo clave fue la persistencia en la cadena de suministro de software. El contenido de los atacantes permaneció tras referencias en las que los repositorios dependientes ya confiaban. Deshabilitar los repositorios de origen interrumpió la distribución, pero no eliminó los objetos comprometidos.
Por tanto, restaurar la disponibilidad también restableció la vía de ataque. Las configuraciones existentes de los flujos de trabajo volvieron a ser peligrosas aunque no hubieran cambiado.
Los responsables de los repositorios deben rotar los secretos y revisar el historial de ejecuciones
Lo primero que deberían hacer los equipos de defensa es buscar referencias a las dos Actions afectadas en todos los archivos de flujo de trabajo. Esto incluye los archivos actuales, los flujos de trabajo reutilizables y las ramas antiguas que aún puedan activar automatizaciones.
Como mínimo, los equipos de respuesta deberían:
- Considerar comprometida la referencia
actions-cool/[email protected]. - Eliminar las dependencias de actions-cool o sustituirlas por un SHA de commit completo y verificado, anterior al 18 de mayo de 2026.
- Rotar todos los secretos a los que podrían haber tenido acceso los trabajos afectados.
- Revisar el historial de ejecuciones de los flujos de trabajo para identificar ejecuciones correctas posteriores a una secuencia prolongada de errores de Set up job.
- Investigar las ejecuciones asociadas al periodo de disponibilidad del 16 de septiembre de 2026.
- Auditar el historial de los repositorios en busca de commits inesperados posteriores al 16 de septiembre de 2026.
- Buscar conexiones a
t.m-kosche[.]comen los registros de red, proxy y telemetría de CI/CD.
La rotación de secretos no debería limitarse a las credenciales cuyo robo ya se haya confirmado. Si un token, una clave o una contraseña estaban disponibles para un trabajo que cargó correctamente la Action maliciosa, los equipos de defensa deberían asumir que quedaron expuestos, salvo que las pruebas de ejecución demuestren lo contrario.
Los responsables de los repositorios también deberían revisar los permisos asignados a los tokens de los flujos de trabajo afectados. Las consecuencias del robo de credenciales dependen en gran medida de si esos tokens solo podían leer el código fuente o también modificar repositorios y procesos de publicación relacionados.
Fijar los commits reduce el riesgo de que se reactiven dependencias
Este incidente pone de manifiesto una debilidad concreta de las dependencias de GitHub Actions basadas en etiquetas: la confianza sigue ligada al estado cambiante de un repositorio externo.
Un flujo de trabajo que usa @v2.2.1 puede parecer inmutable, pero una etiqueta no equivale a un artefacto de software inmutable. Su seguridad puede cambiar si el repositorio de origen se modifica, se ve comprometido, se elimina o se restaura.
Fijar las Actions de terceros a SHA de commit completos reduce ese riesgo, ya que el flujo de trabajo solicita una revisión exacta. Las organizaciones siguen teniendo que verificar el commit elegido y vigilar los incidentes de seguridad relacionados con los repositorios de origen, pero la restauración de un repositorio no puede redirigir silenciosamente la referencia fijada a otro código.
Los controles de acceso y la retirada de repositorios siguen siendo medidas de contención útiles. Sin embargo, no corrigen el problema si el contenido malicioso sigue asociado a etiquetas de versión de confianza.
Fuentes
Este artículo es una reelaboración original basada en las siguientes fuentes.