Una acción de GitHub muy utilizada, denominada actions-cool/issues-helper, ha sido comprometida. El ataque consistió en redirigir silenciosamente todas las etiquetas de versión del repositorio hacia un commit malicioso. Como resultado, las credenciales de los flujos de CI/CD son robadas y enviadas directamente al atacante, lo que representa un riesgo grave para los equipos de desarrollo que utilizan esta herramienta en sus flujos de trabajo automatizados.

Una GitHub Action muy utilizada llamada actions-cool/issues-helper ha sido comprometida, y cada etiqueta de versión en el repositorio ha sido redirigida silenciosamente a un commit malicioso.

El ataque coloca credenciales robadas de pipelines de CI/CD directamente en manos de un atacante, lo que genera serias preocupaciones para los equipos de desarrollo de todo el mundo que confían en esta acción en sus flujos de trabajo automatizados.

El compromiso funciona de una manera engañosamente simple. Un atacante obtuvo la capacidad de mover etiquetas dentro del repositorio y re-apuntó las 53 etiquetas de versión existentes a un único commit impostor que no aparece en ninguna parte del historial de código normal del repositorio.

Cualquier equipo cuyo flujo de trabajo haga referencia a esta acción mediante una etiqueta de versión descargará y ejecutará sin saberlo el código malicioso la próxima vez que se ejecute su pipeline. Solo los flujos de trabajo anclados a un hash de commit específico y conocido como seguro permanecen totalmente inafectados.

Investigadores de StepSecurity identificaron el ataque y publicaron un informe detallado el 18 de mayo de 2026.

StepSecurity afirmó en un informe compartido con Cyber Security News (CSN) que el commit malicioso utiliza el entorno de ejecución JavaScript de código abierto Bun para ejecutar una carga útil que lee directamente de la memoria del proceso Runner.Worker, que es el componente dentro de la infraestructura de pipelines de GitHub que contiene los secretos de flujo de trabajo descifrados durante la ejecución de un trabajo.

Una segunda acción de la misma organización, actions-cool/maintain-one-comment, también fue afectada utilizando exactamente la misma técnica.

Las 15 etiquetas de versión fueron movidas a commits impostores, y los datos robados fueron enviados al mismo dominio controlado por el atacante.

La velocidad de la operación fue sorprendente: los 53 commits impostores para issues-helper se crearon en un intervalo de solo tres minutos y dieciséis segundos, y los 15 para maintain-one-comment se crearon en menos de cuarenta segundos.

El incidente sigue un patrón creciente de ataques a la cadena de suministro dirigidos a herramientas de desarrollo, donde los adversarios buscan puntos de entrada de alto impacto que puedan comprometer a muchas organizaciones a la vez a través de una sola dependencia envenenada.

Los pipelines de CI/CD se han convertido en un objetivo preferido porque a menudo contienen credenciales poderosas para servicios en la nube, repositorios de código y sistemas de despliegue.

Cómo el ataque recolecta secretos

Una vez que el commit malicioso se ejecuta dentro de un pipeline de GitHub Actions, inicia una secuencia de pasos cuidadosamente planeada.

La carga útil primero descarga el entorno de ejecución JavaScript Bun en el entorno del runner, luego inicia un proceso de Python que lee el espacio de direcciones de memoria del proceso Runner.Worker, específicamente a través de la ruta /proc/<PID>/mem.

Esta es la ubicación donde GitHub Actions almacena los secretos de flujo de trabajo descifrados mientras un trabajo se está ejecutando activamente.

La carga útil luego filtra ese volcado de memoria utilizando herramientas estándar de Unix, extrayendo cualquier valor etiquetado con la bandera interna “isSecret”:true.

Desde ahí, extrae el token de autenticación de GitHub y escala privilegios mediante sudo python3 antes de enviar las credenciales recolectadas a través de una conexión HTTPS saliente en el puerto 443 al dominio del atacante, t.m-kosche.com.

La propia interfaz de repositorio de GitHub marcó el commit impostor 1c9e803 con una advertencia de que no pertenece a ninguna rama, pero aun así permaneció accesible a través de las etiquetas movidas.

Detección y pasos recomendados

La herramienta Harden-Runner de StepSecurity detectó el ataque en tiempo real al señalar la descarga de Bun, el proceso sospechoso de lectura de memoria y la llamada de red saliente inesperada a t.m-kosche.com.

Los flujos de trabajo que se ejecutan bajo Harden-Runner tuvieron el dominio del atacante bloqueado automáticamente a nivel de red, lo que significa que las credenciales no pudieron salir del runner incluso si el código malicioso se ejecutó completamente.

El atacante intentó pasar desapercibido asignando a cada commit impostor un mensaje falso estilizado según las notas de lanzamiento del mantenedor legítimo, pero las marcas de tiempo de creación tan cercanas expusieron el fraude inmediatamente.

Se recomienda encarecidamente a los equipos que utilicen cualquiera de las acciones afectadas que anclen sus flujos de trabajo a un SHA de commit completo y verificado en lugar de una etiqueta de versión flotante, ya que las etiquetas pueden moverse silenciosamente sin ninguna notificación a los usuarios.

Los equipos de seguridad deben auditar las ejecuciones recientes de flujos de trabajo que hicieron referencia a actions-cool/issues-helper o actions-cool/maintain-one-comment, y tratar cualquier token o secreto expuesto como completamente comprometido.

Rotar todos los secretos del pipeline es la medida más segura y urgente a tomar. Cualquier tráfico saliente hacia t.m-kosche.com observado en los registros de CI/CD debe considerarse como un signo confirmado de robo de credenciales.

Indicadores de Compromiso (IoCs):-

Nota: Las direcciones IP y los dominios han sido desactivos intencionalmente (por ejemplo, [.]) para evitar la resolución accidental o el enlace. Reactívalos solo dentro de plataformas de inteligencia de amenazas controladas como MISP, VirusTotal o tu SIEM.