La Tormenta Perfecta:

La semana del 18 de mayo de 2026 quedará grabada en los anales de la ciberseguridad como uno de los episodios más complejos y devastadores de ataques coordinados a la cadena de suministro de software. GitHub —la plataforma en la que millones de desarrolladores depositan su confianza diariamente— se convirtió en el campo de batalla de tres incidentes entrelazados que, vistos en conjunto, revelan un patrón inquietante: los atacantes ya no van a por los productos finales, van a por las herramientas que los construyen.

Incidente 1: La extensión envenenada que derribó los repositorios internos de GitHub

El 21 de mayo, GitHub confirmó oficialmente algo que muchos en la industria sospechaban: sus propios repositorios internos habían sido comprometidos. El vector de ataque no fue una vulnerabilidad en la plataforma, sino algo mucho más revelador de los tiempos que vivimos: una extensión de VS Code troyanizada.

La extensión en cuestión era nrwl.angular-console, conocida como Nx Console, ampliamente utilizada por desarrolladores de aplicaciones Angular y Node.js. Un actor de amenazas identificado como TeamPCP logró publicar una versión maliciosa en el Visual Studio Marketplace que estuvo activa apenas 18 minutos —entre las 12:30 y las 12:48 UTC del 18 de mayo— pero eso fue más que suficiente.

La extensión infectada parecía y se comportaba exactamente como la legítima, con una diferencia crítica: al arrancar, ejecutaba silenciosamente un comando de shell que descargaba y ejecutaba un paquete oculto desde un commit plantado en el repositorio oficial de nrwl/nx en GitHub. El comando estaba disfrazado como una tarea rutinaria de configuración de MCP para no levantar sospechas.

El resultado fue devastador. TeamPCP consiguió exfiltrar cerca de 3.800 repositorios internos de GitHub. El stealer de credenciales era capaz de robar datos de bóvedas de 1Password, configuraciones de Anthropic Claude Code, credenciales de npm, GitHub y Amazon Web Services.

Alexis Wales, CISO de GitHub, declaró que no había evidencia de impacto sobre la información de clientes almacenada fuera de los repositorios internos, aunque reconoció que algunos de esos repositorios contienen extractos de interacciones de soporte con clientes.

El co-fundador de Narwhal Technologies, Jeff Cross, capturó perfectamente la dimensión del problema: este incidente demuestra que hacen falta cambios más profundos y fundamentales en cómo los mantenedores piensan sobre la seguridad de las herramientas de desarrollo y la distribución de software de código abierto.

Lo que hace especialmente preocupante este vector es el mecanismo de distribución automática. Como señaló el investigador de Aikido Security Raphael Silva, VS Code y sus derivados —Cursor, Windsurf y otros— tienen las actualizaciones automáticas habilitadas por defecto. Esto significa que cualquier atacante que comprometa a un publicador de extensiones tiene un canal de distribución directa a millones de máquinas de desarrolladores sin ninguna revisión intermedia.

Incidente 2: La operación Megalodon — 5.561 repositorios backdooreados en seis horas

Mientras el incidente de Nx Console acaparaba titulares, los investigadores de SafeDep descubrían algo aún más alarmante en términos de escala: una campaña automatizada bautizada como "megalodon" que, en una ventana de apenas seis horas el mismo 18 de mayo, introdujo 5.718 commits maliciosos en 5.561 repositorios de GitHub.

El método era técnicamente elegante y operativamente brutal. Los atacantes usaron cuentas desechables con nombres de usuario aleatorios de ocho caracteres y forjaron identidades de autor como build-bot, auto-ci, ci-bot y pipeline-bot para que los commits parecieran mantenimiento rutinario de CI/CD. Los mensajes de commit eran indistinguibles de los legítimos: "ci: add build optimization step", "build: improve ci performance", "chore: sync ci configuration".

Detrás de esa fachada innocua se ocultaban workflows de GitHub Actions con payloads bash codificados en base64 cuyo objetivo era la exfiltración masiva de secretos:

• Variables de entorno de CI completas

• Credenciales de AWS (claves de acceso, claves secretas, tokens de sesión)

• Tokens de acceso de GCP via gcloud

• Credenciales de instancias de Azure vía IMDS

• Claves SSH privadas, configuraciones de Docker, archivos .npmrc, .netrc, configuraciones de Kubernetes y tokens de Vault

• Tokens OIDC de GitHub Actions para impersonar identidades cloud

• Escaneo de código fuente en busca de más de 30 patrones de secretos (API keys, cadenas de conexión a bases de datos, JWTs, claves PEM privadas)

Todo exfiltrado hacia un servidor de comando y control en 216.126.225.129:8443.

La campaña empleó dos variantes. La variante masiva (SysDiag) añadía un nuevo workflow disparado en cada push y pull request, maximizando la ejecución automática. La variante dirigida (Optimize-Build) reemplazaba workflows existentes con triggers de workflow_dispatch, creando backdoors durmientes que el atacante podría activar a demanda vía la API de GitHub.

Un caso especialmente instructivo fue el de Tiledesk. El atacante comprometió nueve repositorios de esta plataforma de chat de código abierto, incluyendo el código fuente del servidor. El mantenedor legítimo, sin saber nada del compromiso, continuó publicando versiones en npm desde el repositorio envenenado. Así, las versiones 2.18.6 a 2.18.12 de @tiledesk/tiledesk-server llegaron al registro público de npm con el backdoor incluido, sin que el atacante jamás hubiera tocado la cuenta de npm.

Incidente 3: Los tags de GitHub Actions redirigidos — el ataque imposter commit

Apenas un día antes, el 19 de mayo, StepSecurity había alertado de un tercer vector de ataque: el compromiso de actions-cool/issues-helper, un GitHub Action popular para la gestión de issues en repositorios.

En este caso, el mecanismo era lo que la industria denomina un "imposter commit": todos los tags existentes del repositorio habían sido redirigidos para apuntar a un commit malicioso que no aparecía en el historial normal del proyecto. Ese commit contenía código que, al ejecutarse dentro de un runner de GitHub Actions, realizaba tres acciones:

1. Descargaba el runtime de JavaScript Bun al runner.
2. Leía memoria del proceso Runner.Worker para extraer credenciales.
3. Realizaba una llamada HTTPS saliente al dominio controlado por el atacante t.m-kosche[.]com para transmitir los datos robados.

Quince tags de una segunda acción, actions-cool/maintain-one-comment, también resultaron comprometidos con la misma funcionalidad. GitHub deshabilitó posteriormente el acceso a ese repositorio por violación de sus términos de servicio.

El detalle más significativo es la conexión: el dominio de exfiltración t.m-kosche[.]com había sido previamente observado en la campaña Mini Shai-Hulud, que también comprometió paquetes npm del ecosistema @antv, además de TanStack, Mistral AI y Grafana Labs. Todo apunta a que TeamPCP está orquestando múltiples oleadas de ataques interconectados.

El patrón que lo conecta todo: la cadena de compromisos en cascada

Visto en conjunto, lo que esta semana de incidentes ilustra no es una casualidad sino una estrategia deliberada. TeamPCP ha desarrollado un ciclo autosostenido de compromisos en cascada:

Comprometer una herramienta de confianza → Robar credenciales de los desarrolladores que la instalan → Usar esas credenciales para comprometer la siguiente herramienta legítima → Repetir.

El vector inicial fue el ataque a TanStack, que permitió comprometer el sistema del desarrollador que mantenía la extensión Nx Console. Con esas credenciales, se troyanizó la extensión. Con la extensión troyanizada, se robaron las credenciales de un empleado de GitHub. Con esas credenciales, se exfiltraron miles de repositorios internos.

Paralelamente, la operación Megalodon actuó de forma independiente pero complementaria, usando credenciales robadas para escalar el impacto a decenas de miles de repositorios de terceros.

Qué debería hacer tu organización ahora mismo

Las lecciones operativas de esta semana son claras y accionables:

Para equipos de desarrollo:

Ancla tus workflows de GitHub Actions a hashes de commit completos (SHA), no a tags. Los tags son mutables; los hashes, no. Un workflow que usa uses: actions/checkout@v4 es vulnerable; uno que usa uses: actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29 no lo es.

Audita todos los workflows existentes en busca de referencias a tags que puedan haber sido comprometidos.

Revisa los commits recientes en tus repositorios en busca de los indicadores de compromiso de la campaña Megalodon (autor build-bot, auto-ci, ci-bot, pipeline-bot; emails agent@build-pipeline.io o ci@auto-pipeline.io).

Para administradores de plataforma:

• Considera deshabilitar las actualizaciones automáticas de extensiones de VS Code en entornos corporativos y adoptar un proceso de revisión controlado.

• Implementa revisión de código obligatoria incluso para commits de automatización, especialmente en workflows de CI/CD.

• Monitoriza el tráfico saliente desde tus runners de CI/CD hacia IPs y dominios no autorizados.

Para mantenedores de proyectos open source:

• Configura alertas para commits no autorizados en ramas principales.

• Requiere que todas las publicaciones a registros de paquetes (npm, PyPI, etc.) pasen por pipelines verificados, no desde entornos de desarrollo locales que puedan estar comprometidos.

• Considera usar tokens de publicación de corta duración con alcance mínimo.

• Indicadores de compromiso (IoC) a monitorizar:

C2: 216.126.225.129:8443

Dominio de exfiltración: t.m-kosche[.]com

Paquetes npm comprometidos: @tiledesk/tiledesk-server versiones 2.18.6 a 2.18.12

Nombres de autor en commits: build-bot, auto-ci, ci-bot, pipeline-bot

Emails de autor: agent@build-pipeline.io, ci@auto-pipeline.io

Reflexión final: la confianza como superficie de ataque

Lo que estos tres incidentes tienen en común va más allá de los actores o las técnicas. Todos explotan el mismo recurso: la confianza implícita que los desarrolladores depositan en las herramientas que usan a diario.

Confiamos en que las extensiones de nuestro editor de código hacen lo que dicen hacer. Confiamos en que los workflows de CI que hemos copiado de proyectos populares son seguros. Confiamos en que los paquetes que publicamos llegan intactos al registro. TeamPCP ha demostrado esta semana que cada una de esas suposiciones puede ser y ha sido violada.

El co-fundador de Narwhal Technologies lo expresó con precisión: muchas de las suposiciones bajo las que el ecosistema ha operado durante años ya no son válidas. La cadena de suministro de software no es solo código; es confianza. Y proteger esa confianza requiere repensar no solo las herramientas sino los modelos mentales con los que los desarrolladores se relacionan con ellas.