Acciones de GitHub Desactivadas de Nuevo: Impacto de la Campaña Mini Shai-Hulud

octubre 3, 2026 Alfonso Moreno | Sysadmin Senior 47 Visitas 8 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Por qué importa este segundo round de acciones-cool

El 16 de septiembre de 2026 GitHub re-habilitó dos repositorios que había desactivado en mayo por una brecha vinculada a la campaña Mini Shai-Hulud. El problema no fue el “despertar” en sí: los tags de versión nunca se limpiaron. Cualquier workflow que referencie actions-cool/[email protected] o actions-cool/maintain-one-comment por tag volvió a descargar el payload malicioso en su siguiente run, sin que el código del repositorio cambiara una sola línea.

El investigador de Socket Karlo Zanki documentó la ventana exacta: entre las 11:09 y las 18:16 GMT+2 del 16-sep-2026 ambos repos quedaron accesibles. Philipp Burckhardt, jefe de threat intelligence en Socket, ya había confirmado en mayo que el incidente de mayo compartía el dominio de exfiltración t.m-kosche[.]com con el ataque a paquetes @antv del ecosistema npm: “apunta al mismo clúster de actividad Mini Shai-Hulud, no es un incidente separado de npm”.

La cronología que tu repo no debería repetir

Tres olas en catorce meses muestran que el adversario está iterando sobre el mismo modelo de ataque — comprometer dependencias confiables y abusar del CI/CD para pivotar a secretos sensibles.

Fecha	Ola	Vector principal	Impacto documentado
Sep 2025	Shai-Hulud original	npm worm con auto-propagación via `postinstall`	500+ paquetes npm comprometidos (TrueSec, Datadog Security Labs)
Nov 2025	Shai-Hulud 2.0	Workflow `discussion.yaml` en GitHub Actions	Zapier, ENS Domains y otros (Aikido)
May 2026	Mini Shai-Hulud	GitHub Actions + npm + PyPI cross-ecosystem	TanStack (CVE-2026-45321, CVSS 9.6), Mistral AI, Guardrails AI, OpenSearch, @antv, Nx Console
16-sep-2026	Mini Shai-Hulud resurface	Tags sucios en repos re-habilitados	actions-cool/issues-helper + actions-cool/maintain-one-comment reactivan el payload de mayo

El patrón de noviembre (2.0) ya era el precedente: la primera ola de septiembre 2025 había enseñado que el worm podía propagarse vía postinstall; la segunda iteración movió el pivote a GitHub Actions workflows. El round de septiembre 2026 muestra algo más sutil — que la limpieza incompleta después de un takedown es, en sí misma, una superficie de ataque.

Qué hace exactamente el payload

Cuando un runner de GitHub Actions ejecuta la acción por tag, el código de mayo (que sigue en el árbol a pesar de la desactivación del repo) corre tres pasos en cadena.

# Paso 1 — Descargar Bun runtime al runner
curl -sL https://bun.sh/install | bash
# Paso 2 — Leer memoria del proceso Runner.Worker
# El payload usa /proc/<pid>/mem con ptrace para extraer
# el OIDC token del runner sin tocar el filesystem
# Paso 3 — Exfiltrar a t.m-kosche[.]com vía HTTPS POST
# El dominio fue vinculado por Socket al clúster @antv

Lo crítico para sysadmins Linux: el payload opera solo en memoria. No escribe el token a disco, no toca logs de auditoría estándar, no deja un binario que un escaneo post-mortem pueda encontrar. La única señal observable desde fuera es el tráfico HTTPS saliente hacia t.m-kosche[.]com desde un runner de GitHub Actions.

StepSecurity, que documentó el compromiso inicial en mayo, fue categórico: “because every tag now resolves to malicious commits, any workflow that references the action by version pulls the malicious code on its next run. Only workflows pinned to a known-good full commit SHA are unaffected”. El 16 de septiembre se confirmó que esa misma lógica aplicaba cuatro meses después.

Por qué falló el takedown de mayo

GitHub disableó el acceso a los repositorios de actions-cool el 18 de mayo con el mensaje estándar: “Access to this repository has been disabled by GitHub Staff due to a violation of GitHub’s terms of service”. El mensaje permite al dueño solicitar revisión, pero no borra tags ni purga caché de resolución. Cuando el repo volvió a estar accesible en septiembre, los tags v2.2.1 (issues-helper) y los 15 tags de maintain-one-comment siguieron apuntando al commit impostor introducido en mayo.

Es la misma clase de falla que vimos con el incidente de CrowdSec en julio (publicado en este sitio como post 3263): deshabilitar el acceso no es lo mismo que invalidar dependencias aguas abajo. En el modelo de GitHub Actions, un tag es una referencia mutable — no un inmutable.

Mitigación concreta para tu fleet

Socket publicó el 16-sep la lista de acciones para limitar el daño en runners propios.

# 1. Localizar referencias a las acciones afectadas
grep -rn "actions-cool/issues-helper" .github/workflows/
grep -rn "actions-cool/maintain-one-comment" .github/workflows/
# 2. Tratar v2.2.1 de issues-helper como comprometida
# Reemplazar por SHA de commit anterior al 18-may-2026
# Ejemplo: actions-cool/issues-helper@<40-char-sha-pre-2026-05-18>
# 3. Rotar todos los secretos que hayan podido correr
#    en runners que usaron la acción entre el 16 y 17-sep
gh secret list --repo <owner>/<repo>
gh secret delete NAME --repo <owner>/<repo>
# 4. Revisar runs sospechosos
gh run list --repo <owner>/<repo> --status success 
  --json databaseId,name,createdAt,event,headBranch 
  | jq '.[] | select(.createdAt > "2026-09-16")'
# 5. Auditar historial de commits posteriores al 16-sep
git log --since="2026-09-16" --all --pretty=format:"%H %an %ae %s"

El paso 1 es el único que escala. Si tu org tiene docenas de repos con workflows heredados, una búsqueda grep recursiva en .github/workflows/ te da el inventario completo antes de tocar nada. El paso 2 es el fix real: pin a SHA. Pinning a branch sigue siendo vulnerable porque la rama puede recibir un force-push; pinning a tag sigue siendo vulnerable porque, como acabamos de ver, los tags pueden seguir apuntando a commits maliciosos mucho después del takedown.

Lo que cambió en el modelo de amenaza

Antes de este incidente, la guía estándar era “usa actions oficiales, no uses third-party actions de autores desconocidos”. actions-cool era un autor conocido: llevaba años en el ecosistema, tenía stars y descargas, aparecía en recomendaciones de blog posts. La métrica de “confianza” no sirvió.

El nuevo piso de seguridad para GitHub Actions en 2026, según las recomendaciones de Socket + StepSecurity tras este incidente, es:

Pin obligatorio a SHA completo (40 hex chars), nunca a tag ni a branch. Auditable, inmutable, reproducible.
Limitar permissions a read-only por defecto y escalar a write solo en jobs que lo necesiten explícitamente.
Restringir pull_request_target: este trigger es el que la cadena TanStack usó en mayo para comprometer 42 paquetes y 84 versiones.
Monitorear tráfico HTTPS saliente desde runners hacia dominios no listados en un allowlist. Es la única señal del payload de actions-cool.
Rotar secretos en OIDC trust boundaries, no solo en PATs clásicas: el payload extrae el OIDC token del runner process, no un PAT del usuario.

Qué sigue sin resolverse

Socket no ha publicado por qué GitHub re-habilitó los repos el 16-sep. Las hipótesis abiertas son: (a) el dueño apeló el takedown y GitHub aprobó sin auditoría técnica, (b) un proceso automatizado de rehabilitación masiva corrió sin contexto del compromiso previo, (c) algún otro factor no público. Tampoco está claro cuántos workflows corporativos re-ejecutaron el payload en la ventana de 7 horas antes de que Socket publicara el hallazgo.

El 18-sep GitHub volvió a disablear ambos repos. Pero los tags siguen ahí, apuntando a código malicioso, esperando la próxima vez que el acceso se reabra.

Resumen para tu próximo review de seguridad

El incidente de actions-cool del 16-sep-2026 no es una nueva vulnerabilidad: es la confirmación de que el takedown de mayo fue cosmético. Para tu organización, las tres preguntas que debes poder responder antes del próximo comité de seguridad son:

¿Cuántos workflows en tus repos pinnean por SHA vs por tag vs por branch?
¿Cuántos usan actions-cool/* o cualquier otra acción de un autor que haya tenido un takedown, vigente o pasado?
¿tienes telemetría de egress HTTPS desde tus runners de GitHub Actions hacia dominios fuera de un allowlist?

Si la respuesta a cualquiera de las tres es “no sé”, este es el incidente que justifica el sprint.

Preguntas frecuentes

¿Por qué Acciones de GitHub Desactivadas de Nuevo: Impacto de la Campaña Mini Shai-Hulud es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Acciones de GitHub Desactivadas de?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Acciones de GitHub Desactivadas de?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Acciones de GitHub Desactivadas de y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Acciones de GitHub Desactivadas de?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.