Dos acciones de GitHub Actions de actions-cool comprometidas en mayo y reactivadas en septiembre

Dos acciones públicas de GitHub Actions mantenidas por el proyecto actions-cool —actions-cool/issues-helper y actions-cool/maintain-one-comment— fueron reactivadas el 16 de septiembre de 2026 y, tras ello, GitHub las ha vuelto a deshabilitar. Está confirmado que esas acciones habían sido comprometidas el 18 de mayo de 2026 para ejecutar código malicioso destinado a extraer credenciales desde las canalizaciones de CI/CD que las invocaran y enviar esos datos a un servidor controlado por los atacantes; la actividad fue asociada públicamente al clúster de amenazas conocido como Mini Shai-Hulud. Según la investigación publicada por la firma Socket y declaraciones de su equipo, las etiquetas de versión (tags) que apuntaban al código malicioso nunca fueron eliminadas, por lo que la única condición necesaria para reactivar la amenaza fue que los repositorios volvieran a ser accesibles públicamente.

Técnicamente, el vector explotado aquí no exige publicar un nuevo release ni comprometer otra cuenta: muchos workflows de GitHub Actions referencian esas acciones mediante referencias mutables (por ejemplo, tags como @v2.2.1). Cuando un tag mutable fue apuntado en mayo hacia un commit que inyectaba un payload —capaz de leer secretos de entorno o del contexto del runner y de exfiltrarlos—, cualquier workflow que use ese tag descarga y ejecuta ese contenido en tiempo de ejecución. Socket ha indicado además que la exfiltración reutilizaba un dominio observado con anterioridad en el incidente del ecosistema @antv (t.m-kosche[.]com), lo que permitió correlacionar ambas campañas con Mini Shai-Hulud. Esa reutilización de infraestructura es un indicador técnico útil para atribución y fue un factor clave para identificar la conexión entre compromisos de paquetes npm y el abuso de acciones en GitHub.

Quienes resultan afectados son, en primer lugar, los mantenedores y usuarios de repositorios que incorporan esas acciones sin fijarlas a un commit SHA específico anterior al 18 de mayo. En la práctica esto incluye proyectos que automatizan cierre de issues, mantenimiento de comentarios de bot o chequeos periódicos, porque dichos workflows suelen ejecutarse con frecuencia (por ejemplo, on: schedule o on: issues/pull_request). Socket estima que la mayoría de los repositorios que dependían de esas acciones pudieron ejecutar el payload dentro de un día desde la reactivación, dado el patrón de ejecución habitual, aunque ese punto es una proyección basada en cómo se configuran típicamente esos workflows y no la verificación de cada repositorio individual.

Las consecuencias técnicas importantes son varias y concretas: la exposición de tokens y secretos almacenados como variables de entorno en las ejecuciones de Actions puede permitir a un atacante escalar privilegios, acceder a otros repositorios, publicar paquetes maliciosos en registros con credenciales robadas o manipular pipelines de entrega. Además, al tratarse de una dependencia en la cadena de suministro de desarrollo, la ejecución silenciosa del payload en múltiples proyectos multiplica el riesgo sin requerir nuevas vulnerabilidades ni infraestructura adicional por parte del atacante —basta con que el código malicioso permanezca disponible bajo la referencia que los workflows consumen.

Hechos confirmados: los compromisos iniciales de 18 de mayo de 2026, la reactivación de acceso entre las 11:09 y las 18:16 (GMT+2) del 16 de septiembre de 2026, la observación de etiquetas que seguían apuntando al contenido malicioso, la identificación del dominio de exfiltración y la intervención posterior de GitHub para deshabilitar las repos. Estimaciones razonables: la rapidez con la que la mayoría de repositorios afectados podrían haber ejecutado el payload tras la reactivación, basada en patrones de ejecución típicos. Información aún incierta: la causa raíz de por qué GitHub permitió de nuevo el acceso a esos repositorios en septiembre y si hubo una intervención humana, un error automatizado o un procedimiento administrativo que revirtió la suspensión previa.

Qué debe hacer un equipo de desarrollo o un administrador de repositorio ahora mismo: localizar todas las referencias a las dos acciones afectadas y tratar la referencia actions-cool/[email protected] como comprometida; eliminar esa dependencia o reemplazarla por un commit SHA conocido y limpio que sea anterior al 18 de mayo de 2026; rotar inmediatamente todos los secretos y tokens que pudieron haber estado disponibles en ejecuciones que utilizaron esas acciones; revisar el historial de ejecuciones de workflows para detectar ejecuciones exitosas tras la reactivación o por períodos inusualmente breves en que antes fallaban las jobs; y auditar el historial del repositorio buscando commits inesperados con fecha posterior al 16 de septiembre de 2026. Estas recomendaciones están en línea con las prácticas de mitigación frente a supply chain risks y con los avisos públicos de investigadores; GitHub mantiene una guía sobre endurecimiento de seguridad para Actions que incluye la recomendación de usar referencias inmutables (SHA) para evitar exactamente este tipo de reactivaciones: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions.

Medidas técnicas concretas y prioritarias: pinnear todas las dependencias de acciones a su commit SHA completo (no a tags mutables), invalidar y rotar cualquier secreto expuesto (tokens personales, secretos de repositorio o de organización) y revisar los permisos asignados a los tokens para aplicar el principio de menor privilegio. Además, conviene habilitar controles organizacionales como la revisión manual de acciones externas, permitir solo acciones auditadas desde el Marketplace o restringir la ejecución de acciones a runners auto-hospedados con políticas de seguridad más estrictas. Para comprobar la reputación y la historia de una acción, los equipos pueden apoyarse en análisis externos y en herramientas de detección de dependencias —Socket es una de las firmas que ha publicado detalles sobre esta campaña y mantiene información técnica sobre la investigación en su web: https://socket.dev/.

Interpretación: este incidente subraya que la seguridad de la cadena de suministro no depende únicamente de prevenir nuevas publicaciones maliciosas; también requiere controlar cómo se referencian e invocan dependencias. Una etiqueta mutable comprometida puede ser contenida y luego inadvertidamente reactivada sin que el consumidor modifique su propio workflow, lo que hace que la práctica de pinning a SHA deje de ser una recomendación teórica para ser una necesidad operativa.

Por último, lo que aún hace falta aclarar: GitHub no ha hecho público por qué se restauró el acceso a esos repositorios y si adoptará medidas para notificar de forma proactiva a los repositorios que dependían de ellos. Las organizaciones deberían asumir que la incertidumbre persiste y actuar como si cualquier acción referenciada por tag mutable y potencialmente afectada fuera insegura hasta que se pruebe lo contrario mediante una auditoría interna. El error en esta materia no es esperar a que GitHub emita un comunicado, sino no verificar por cuenta propia la integridad de las dependencias y no tener un proceso de respuesta rápida para la rotación de credenciales y la remediación de pipelines.