Megalodon es una campaña de supply chain orientada a repositorios GitHub y entornos CI/CD. Según reportes de investigación, la operación empujó 5.718 commits maliciosos contra 5.561 repositorios durante una ventana aproximada de seis horas. El objetivo era insertar workflows de GitHub Actions con payloads capaces de recolectar secretos, tokens, claves SSH, credenciales cloud y configuraciones sensibles.
El caso es relevante porque no se limita a “código malicioso en una aplicación”. El foco está en el pipeline: automatizaciones, runners, secretos, permisos, OIDC y publicación de artefactos. En otras palabras, el atacante no necesita entrar por la puerta principal si puede convencer al sistema de despliegue de abrirla desde adentro. Una genialidad miserable, como casi todo lo que funciona en seguridad.
La campaña habría usado cuentas o identidades automatizadas para enviar commits que aparentaban ser cambios rutinarios de CI/CD. Esos commits agregaban o modificaban workflows de GitHub Actions. Una vez ejecutados, los workflows podían recolectar secretos presentes en el entorno de integración continua y enviarlos hacia infraestructura controlada por el atacante.
Entre los elementos apuntados se mencionan variables de entorno, credenciales AWS, tokens de Google Cloud, credenciales Azure, claves SSH privadas, configuraciones de Docker y Kubernetes, tokens de Vault, credenciales Terraform, GitHub Actions tokens y otros secretos típicos de pipelines modernos.
El impacto potencial no está solo en los repositorios comprometidos. Si un pipeline tiene permisos para publicar paquetes, construir imágenes, firmar releases o desplegar en cloud, entonces un workflow malicioso puede convertirse en un punto de propagación hacia usuarios, clientes o infraestructura productiva.
TechRadar reportó además el caso de versiones comprometidas publicadas en npm a partir de un repositorio contaminado, donde el atacante no necesariamente necesitó comprometer directamente la cuenta npm: bastó con afectar la fuente desde donde se publicaba.
La atribución debe tratarse con cuidado. Algunos análisis vinculan el contexto con campañas recientes alrededor de TeamPCP/Shai-Hulud, pero otros reportes plantean que Megalodon podría ser una campaña separada o inspirada en ese movimiento. Para una pieza pública conviene marcarlo como atribución no cerrada o posible relación contextual, no como hecho definitivo.
Primero, commits recientes que agreguen o modifiquen .github/workflows/. Segundo, ejecución de workflows inusuales, especialmente si corrieron desde ramas, forks o PRs no confiables. Tercero, permisos de GitHub Actions, con atención a contents, packages, id-token, actions y acceso a secretos. Cuarto, secretos que hayan estado disponibles durante la ejecución del workflow. Quinto, publicación de paquetes, imágenes o artefactos generados después de los commits sospechosos.
Megalodon confirma una tendencia incómoda: el pipeline se convirtió en un objetivo de primer nivel. No alcanza con revisar dependencias o hacer SAST sobre el código. Hay que tratar CI/CD como infraestructura crítica.
El atacante moderno no siempre necesita vulnerar producción. A veces le alcanza con tocar el workflow correcto y dejar que la automatización haga el trabajo sucio.
Menos humo, más evidencia.