Reapertura de GitHub Actions comprometidas
Recientemente, dos repositorios de GitHub Actions, actions-cool/issues-helper y actions-cool/maintain-one-comment, han sido reactivados tras haber sido deshabilitados por un compromiso previo en mayo de 2026 durante la campaña de malware Mini Shai-Hulud. A pesar de haber sido inhabilitados, los repositorios volvieron a estar accesibles el 16 de septiembre de 2026, permitiendo así la reactivación del código malicioso que había sido introducido anteriormente.
Riesgos asociados a la reactivación
Según el investigador Karlo Zanki de Socket, la falta de limpieza en las etiquetas de lanzamiento de estos repositorios fue un factor crítico. Las etiquetas seguían apuntando al contenido malicioso, lo que significa que cualquier flujo de trabajo que hiciera referencia a estas acciones reanudaba la descarga y ejecución del payload en su siguiente ejecución. Este malware había sido diseñado para robar credenciales sensibles de los pipelines de CI/CD que los utilizaban e exfiltrar esta información a un servidor controlado por un atacante.
La actividad se ha vinculado con el grupo de amenazas Mini Shai-Hulud, dado que se observaron coincidencias en el dominio de exfiltración utilizado en los flujos de trabajo de GitHub Actions y en los paquetes de npm del ecosistema @antv. Esta conexión subraya la gravedad del incidente, que se considera un ataque a la cadena de suministro de software.
Detalles del incidente
La reactivación de los repositorios, que ocurrió entre las 11:09 y las 18:16 GMT+2, plantea interrogantes sobre por qué estos repositorios fueron habilitados nuevamente sin una limpieza previa. Lo alarmante es que el código malicioso permaneció en las bases de código afectadas, y cualquier acción para descargar los repositorios activó la amenaza sin requerir nuevas vulnerabilidades o infraestructura por parte de los atacantes.
Las dos acciones de GitHub en cuestión automatizan tareas de gestión de problemas y comentarios, como el cierre de incidencias inactivas o la actualización de comentarios de bots. Esto implica que muchos repositorios afectados probablemente ejecutaron el payload dentro de un día tras la reactivación, sin necesidad de que los atacantes intervinieran nuevamente.
Recomendaciones para desarrolladores
Para mitigar los riesgos asociados a este tipo de incidentes, se recomiendan las siguientes acciones: 1. Localizar todas las referencias a las acciones afectadas, considerando actions-cool/issues-helper@v2.2.1 como comprometida. 2. Eliminar estas acciones y fijarlas a un SHA limpio conocido que preceda al 18 de mayo de 2026. 3. Rotar todos los secretos expuestos. 4. Revisar el historial de ejecuciones de los flujos de trabajo y detectar nuevas ejecuciones exitosas tras un período prolongado de fallos en los trabajos. 5. Auditar el historial del repositorio en busca de commits inesperados después del 16 de septiembre de 2026.
Zanki enfatiza que la mayoría de los incidentes de cadena de suministro implican la publicación de nuevas versiones maliciosas o cambios en la configuración. Sin embargo, en este caso, no se publicó nuevo código ni se modificó la configuración, lo que resalta la importancia de la fijación de SHA para evitar dependencias del estado del repositorio original.
Conclusiones
Este incidente demuestra que un tag mutable puede ser comprometido, contenido y luego reactivado sin necesidad de modificaciones en los archivos de flujo de trabajo. La fijación de SHA proporciona una capa adicional de seguridad, asegurando que los desarrolladores no estén a merced de cambios en los repositorios upstream.