Megalodon usó GitHub Actions para infectar 5.561 repos en seis horas

Una campaña automatizada publicó 5.718 commits en 5.561 repositorios de GitHub en seis horas un lunes de mayo. Los commits parecían tareas rutinarias de CI (“ci: add build optimization step”, “build: improve ci performance”, “chore: optimize pipeline runtime”) y venían firmados por autores con nombres comunes: build-bot, auto-ci, pipeline-bot. Cuando terminó la mañana del 18 de mayo, cada uno de esos repositorios tenía un archivo de workflow con un payload bash codificado en base64 adentro.

La campaña se llama Megalodon. El equipo de investigación de SafeDep la dio a conocer el 21 de mayo, después de desarmar los commits y seguir el rastro hasta un único servidor de mando y control en 216.126.225.129:8443. Lo interesante no es que GitHub recibiera un ataque. Lo interesante es que el atacante no necesitó comprometer GitHub. Usaron GitHub Actions, el sistema de CI/CD diseñado para garantizar la integridad del código, como vehículo de entrega de la puerta trasera.

Dos workflows, uno masivo y otro dormido

Megalodon operó en dos modos. La variante masiva agregaba un workflow nuevo llamado SysDiag que se disparaba con cada push y cada pull request, capturando todo lo que pasara por delante. La variante dirigida, Optimize-Build, hizo algo más paciente: sustituyó un workflow existente por un disparador workflow_dispatch que se queda dormido hasta que alguien lo invoca a mano. Una puerta trasera durmiendo en el directorio CI de un proyecto cuesta mucho más detectar que un workflow nuevo llamado SysDiag, porque casi nadie audita un archivo que él mismo escribió.

Cuando el workflow se ejecuta, el payload lee todo lo que tiene a mano dentro del entorno CI. Variables de entorno. Claves de acceso, claves secretas y tokens de sesión de AWS. Tokens de acceso de GCP. Claves SSH privadas. Credenciales .npmrc. Configuraciones de Docker. Configuraciones de Kubernetes. Tokens OIDC de GitHub Actions, que dejan al atacante suplantar al propio workflow ante cualquier cuenta en la nube a la que estuviera autorizado. Antes de salir, el payload busca en el código del repositorio más de treinta patrones de secretos (claves de API, contraseñas, fragmentos de certificados) por si algún humano pegó uno. Los endpoints de metadatos de AWS IMDSv2, GCP y Azure también se consultan para obtener identidad de la máquina en la nube.

Un pipeline que envía su propia puerta trasera

La víctima más grave hasta ahora es Tiledesk, una plataforma de atención al cliente de código abierto cuyos nueve repositorios de GitHub fueron afectados. Entre el 19 y el 21 de mayo, Tiledesk subió su paquete tiledesk-server a npm con la puerta trasera compilada adentro. Las versiones 2.18.6 a 2.18.12 de @tiledesk/tiledesk-server cargan ahora el código del payload, instalado por cada desarrollador que ejecutó npm install durante esa ventana. Esa es la palanca para la que Megalodon fue diseñado: meter una puerta trasera en un proyecto de código abierto para que su pipeline de release meta puertas traseras en cientos de proyectos dependientes.

Black-Iron-Project tuvo ocho repositorios afectados. Cientos de proyectos más pequeños (cuentas de desarrolladores individuales, clústeres universitarios, sandboxes abandonados) recibieron uno o dos cada uno. El atacante no parecía escoger. El patrón fue cobertura amplia, cuentas desechables con nombres aleatorios de ocho caracteres empujando mensajes de commit idénticos minuto a minuto. El servidor C2 registró en silencio lo que volvía.

Por qué los archivos de CI sobrevivieron a la auditoría

Esto funcionó por la misma razón por la que va a repetirse durante el resto de 2026. Los pipelines CI/CD están construidos sobre confianza. Un desarrollador que desconfía de un binario raro en una descarga ejecuta sin pensar un archivo de workflow que llegó a su repositorio la semana pasada, porque los archivos de workflow son justamente eso: código que la plataforma debe correr. Los logs de auditoría existen, pero casi nadie los lee. Los commits nuevos vienen firmados por nombres como build-bot y ci-bot. Los diffs son pequeños. La cadena base64 al final del workflow es opaca a propósito.

El manual defensivo es simple y poco satisfactorio. Rotar cada secreto que tocó un repositorio entre el 18 de mayo y hoy. Auditar el directorio .github/workflows de cada proyecto bajo gestión. Revisar los commits cuyo correo de autor no coincida con un miembro conocido del equipo. Tratar cualquier cadena base64 dentro de un archivo de Actions como culpable hasta que se decodifique. Las organizaciones que usan Tiledesk deberían bajar a 2.18.5 o esperar una versión limpia. Cualquiera con confianza OIDC entre Actions y un proveedor de nube debería revocar y emitir de nuevo esa relación de confianza.

Megalodon es la primera campaña a esta escala que trata el workflow CI como el blanco blando. No será la última. La lección que deja el ataque es una que los desarrolladores ya escucharon antes en voz más baja: la parte del pipeline que no lees es la parte que el atacante escribe por ti.