Dos herramientas de automatización comprometidas en mayo han reaparecido en septiembre sin haber eliminado las referencias al código malicioso. GitHub volvió a bloquearlas el día 25, pero los proyectos que las ejecutaron durante ese intervalo deben revisar su exposición.
Las GitHub Actions de terceros actions-cool/issues-helper y actions-cool/maintain-one-comment volvieron a estar accesibles el 16 de septiembre de 2026, conservando etiquetas de versión que apuntaban a código malicioso. Según la investigación de Socket, publicada el día 24, bastaba con que se ejecutara un flujo de trabajo que utilizase esas referencias para descargar y ejecutar nuevamente el payload de la campaña Mini Shai-Hulud.
El compromiso original se remontaba al 18 de mayo. StepSecurity documentó entonces cómo los atacantes habían redirigido las etiquetas de ambas herramientas hacia commits maliciosos ajenos al historial de su rama principal. El código estaba diseñado para robar credenciales de los entornos de integración y despliegue continuo, conocidos como CI/CD.
GitHub deshabilitó los repositorios al día siguiente. La medida impidió que los proyectos dependientes descargaran las Actions, pero no eliminó el código comprometido. Cuando volvieron a estar disponibles en septiembre, las referencias continuaban apuntando al mismo malware. Socket no ha podido determinar por qué se restableció el acceso sin corregir antes ese problema.
La etiqueta de versión no garantiza que el código sea el mismo
En GitHub Actions, los desarrolladores pueden incorporar herramientas externas indicando una etiqueta como @v3 o @v2.2.1. Aunque parezcan versiones fijas, las etiquetas de Git pueden modificarse para apuntar a otro commit. El archivo del proyecto consumidor puede permanecer intacto mientras cambia el código que termina ejecutando, un riesgo que GitHub recoge expresamente en su documentación de seguridad.
La alternativa recomendada es fijar la Action al SHA completo de un commit previamente revisado. Ese identificador permite seleccionar una revisión concreta, en lugar de depender de una etiqueta modificable. La diferencia es importante: fijar un SHA evita que la referencia cambie silenciosamente, pero no convierte en seguro un commit que ya contiene malware.
El objetivo eran las credenciales del entorno de ejecución
El análisis original de StepSecurity mostró que el código malicioso descargaba el entorno JavaScript Bun y leía la memoria del proceso Runner.Worker, donde podían encontrarse secretos descifrados del flujo de trabajo. Después enviaba las credenciales recopiladas a un servidor controlado por los atacantes. No se limitaba, por tanto, a alterar el funcionamiento de la automatización.
El impacto potencial depende de los permisos y secretos disponibles en cada ejecución. GitHub advierte de que una Action comprometida puede utilizar el GITHUB_TOKEN y, si dispone de permisos suficientes, escribir en el repositorio. Por eso recomienda aplicar privilegios mínimos y revisar qué información sensible reciben las herramientas externas, incluso cuando realizan tareas aparentemente secundarias.
15.000 dependencias ≠ 15.000 víctimas
Socket contabilizó aproximadamente 15.000 repositorios dependientes de issues-helper en el grafo de dependencias de GitHub. Sin embargo, no determinó cuántos utilizaban etiquetas modificables en lugar de un SHA fijo. Esa cifra describe el alcance potencial de la dependencia, no un recuento de repositorios comprometidos.
La distinción ya había resultado relevante durante el incidente original. En julio, un aviso de infraestructura publicado en Apache Linkis identificó el uso de la Action, pero señaló que el flujo revisado no se había ejecutado durante la ventana de exposición de mayo. Tener la dependencia configurada y haber ejecutado el código malicioso son situaciones diferentes, que deben comprobarse mediante el historial de ejecuciones.
Bloquear de nuevo no resuelve la exposición anterior
Tras el segundo bloqueo, la revisión debe centrarse en los proyectos que ejecutaron las referencias afectadas desde el 16 de septiembre. Las recomendaciones recogidas tras el incidente incluyen retirar las Actions o sustituirlas por revisiones verificadas, comprobar el historial de los flujos y rotar los secretos accesibles durante las ejecuciones afectadas.
Para reducir futuras exposiciones, GitHub permite restringir qué Actions pueden ejecutarse y exigir que estén fijadas a un SHA completo. Estas políticas complementan la revisión del código y los permisos mínimos: ninguna herramienta debería recibir más acceso del necesario por el simple hecho de llevar tiempo funcionando dentro de un proyecto.
El caso deja una diferencia fundamental entre contener un incidente y resolverlo. Retirar una dependencia de circulación puede detener nuevas ejecuciones, pero recuperar su disponibilidad no demuestra que haya recuperado su integridad. Antes de volver a confiar en ella, hay que comprobar qué código va a ejecutarse.
