Blog Blog

Megalodon: más de 5.500 repos GitHub

Megalodon: más de 5.500 repos GitHub

Resumen ejecutivo

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.

Qué pasó

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.

Por qué importa

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.

Estado de atribución

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.

Línea de tiempo resumida

  • 2026-05-18: ventana reportada de actividad masiva, con más de 5.700 commits maliciosos contra más de 5.500 repositorios.
  • 2026-05-22: empiezan a circular análisis públicos de la campaña Megalodon y su foco en GitHub Actions / CI/CD.
  • 2026-05-25/26: medios cyber amplifican el caso y lo conectan con el riesgo más amplio de supply chain en ecosistemas GitHub/npm.

Qué deberían revisar los equipos técnicos

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.

Medidas defensivas

  • Rotar secretos potencialmente expuestos.
  • Revisar workflows nuevos o modificados.
  • Reducir permisos por defecto de GitHub Actions.
  • Usar permisos mínimos por workflow.
  • Restringir ejecución automática desde forks o PRs externos.
  • Separar secretos de build, test y deploy.
  • Validar uso de OIDC y audiencias cloud.
  • Revisar runners self-hosted.
  • Monitorear exfiltración desde jobs CI/CD.
  • Revisar paquetes npm, contenedores y releases publicados después del evento.

Conclusión

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.

Nestor Martin Guerra Garcia (Dr.Plaga)

Nestor Martin Guerra Garcia (Dr.Plaga)

Threat intelligence | Protección de Datos y Gestión de Riesgos | Old school