GitHub reactiva Actions comprometidas y el malware Mini Shai-Hulud vuelve a ejecutarse
Dos repositorios deshabilitados en mayo se volvieron accesibles sin limpiar los tags maliciosos, reactivando el exfiltrado de credenciales CI/CD.
GitHub ha deshabilitado por segunda vez los repositorios de las GitHub Actions actions-cool/issues-helper y actions-cool/maintain-one-comment después de que sus repositorios volvieran a ser accesibles la semana pasada. La consecuencia operativa es inmediata: cualquier workflow que referencie estas acciones mediante una etiqueta de versión (tag) ha reanudado la descarga y ejecución del código malicioso asociado a la campaña Mini Shai-Hulud en su próximo ciclo de ejecución.
El incidente original se registró el 18 de mayo de 2026, cuando inyectaron código diseñado para recolectar credenciales sensibles de pipelines CI/CD y exfiltrarlas a un servidor controlado por el atacante. Socket, que ha seguido el caso, vincula esta actividad a la misma infraestructura de amenazas que afectó a paquetes de npm del ecosistema @antv, citando solapamientos en el dominio de exfiltración t.m-kosche[.]com. Philipp Burckhardt, responsable de inteligencia de amenazas en Socket, confirmó entonces que se trataba de un mismo clúster de actividad, no de un incidente aislado de npm.
El fallo no fue el código, fue la limpieza
Los repositorios se reactivaron el 16 de septiembre de 2026. Según Karlo Zanki, investigador de Socket, el problema no fue una nueva inyección de código ni un cambio de configuración en los workflows afectados. Lo que ocurrió es que, al reactivar los repositorios, los tags de versión que apuntaban al código malicioso introducido en mayo nunca fueron limpiados. Como la mayoría de los workflows que utilizan estas acciones para tareas de mantenimiento (cerrar issues inactivos, borrar comentarios) se ejecutan a diario o al abrir un issue, la carga maliciosa se activó de nuevo sin que el atacante tuviera que hacer nada nuevo. Básicamente, la amenaza se reactivó sola por un error de gestión en la reactivación de la infraestructura upstream.
Para los administradores de sistemas y DevOps, la lección técnica es clara: las etiquetas mutables son un vector de riesgo supply chain si el upstream puede ser comprometido y restaurado. Zanki señala que este incidente demuestra que un tag comprometedor puede ser contenido y luego reactivado sin alterar el archivo de workflow del consumidor. La única defensa real es fijar las dependencias a un SHA completo de commit conocido como limpio (anterior al 18 de mayo de 2026).
Si utilizas estas actions, debes localizar todas las referencias a actions-cool/issues-helper@v2.2.1 y tratarlas como comprometidas. La recomendación de seguridad es eliminar las acciones o fijarlas a un SHA limpio, rotar todos los secretos expuestos y auditar el historial de ejecución de workflows buscando ejecuciones exitosas inusuales tras periodos de fallo. También conviene revisar el historial del repositorio en busca de commits inesperados posteriores al 16 de septiembre.
