Un ataque masivo contra GitHub pone en alerta a la comunidad de desarrolladores

La seguridad de miles de proyectos de software está bajo la lupa tras el descubrimiento de una nueva campaña de ciberataques que utiliza cuentas comprometidas de GitHub para robar credenciales, claves de acceso y otros datos confidenciales.

La operación, identificada como wfx-loot, comenzó el 10 de noviembre de 2026 y ha conseguido alcanzar una escala preocupante en apenas unos días.

Según una investigación de Aikido Security, los atacantes utilizaron miles de cuentas comprometidas para identificar repositorios vulnerables a modificaciones maliciosas y aprovechar los procesos automatizados de desarrollo de software.

¿Qué tan grande es el ataque?

Las cifras reveladas por los investigadores muestran la magnitud del incidente:

• 4.837 cuentas de GitHub comprometidas.

• 61.764 repositorios examinados por los atacantes.

• Más de 1.800 repositorios en los que se ejecutó el código malicioso.

• Miles de proyectos expuestos a posibles modificaciones no autorizadas.

Sin embargo, existe una diferencia importante: los más de 61.000 repositorios fueron objetivos de la campaña, lo que no significa que todos hayan sufrido un robo de información.

¿Cómo consiguieron infiltrarse en los proyectos?

Los ciberdelincuentes utilizaron credenciales previamente robadas para acceder a cuentas legítimas de desarrolladores.

Desde estas cuentas, comenzaron a enviar solicitudes de cambios aparentemente inofensivas, conocidas como pull requests, con el objetivo de comprobar los permisos disponibles en cada repositorio.

Una vez identificado un proyecto en el que podían realizar modificaciones, introducían código malicioso en los procesos automatizados de GitHub Actions o en scripts vinculados a la instalación de dependencias.

De esta manera, el malware podía ejecutarse durante tareas habituales como la compilación, las pruebas o el despliegue de una aplicación.

Lo más preocupante es que, después de ejecutarse, los atacantes revertían las modificaciones y eliminaban registros de ejecución para dificultar la detección del incidente.

El verdadero objetivo: robar las claves de tus aplicaciones

El malware no estaba diseñado únicamente para acceder al código fuente. Su principal objetivo era obtener información confidencial que pudiera utilizarse para acceder a otros servicios.

Entre los datos que buscaba se encuentran:

• Credenciales de Amazon Web Services (AWS).

• Claves de Microsoft Azure y Google Cloud.

• API Keys de OpenAI y Anthropic.

• Tokens de autenticación de GitHub.

• Archivos de configuración y variables de entorno.

• Credenciales de Docker, Kubernetes y gestores de paquetes.

• Claves SSH y otros mecanismos de acceso a servidores.

Estas credenciales pueden permitir que un atacante acceda a infraestructura en la nube, utilice servicios de inteligencia artificial sin autorización o incluso comprometa otras aplicaciones.

En determinados casos, los investigadores identificaron mecanismos destinados a mantener el acceso a servicios en la nube incluso después de que las víctimas cambiaran sus credenciales.

¿GitHub fue realmente hackeado?

Aunque el incidente afecta a miles de usuarios de la plataforma, las investigaciones disponibles no indican que los atacantes hayan vulnerado directamente la infraestructura de GitHub.

En realidad, aprovecharon cuentas y tokens de acceso previamente comprometidos, utilizando permisos legítimos para introducir código malicioso.

Este tipo de incidente demuestra que la seguridad de una plataforma también depende de cómo sus usuarios protegen sus credenciales y administran los permisos de sus proyectos.

Además, tener un repositorio privado no sustituye las medidas de seguridad necesarias para proteger una cuenta y sus integraciones.

¿Cómo saber si tu repositorio está afectado?

Los investigadores recomiendan revisar la actividad reciente de tus proyectos, especialmente a partir del 10 de noviembre de 2026.

Algunas señales relacionadas con esta campaña incluyen:

• Pull requests titulados docs: dependency audit notes.

• Ramas desconocidas con el nombre wfx-docs.

• Commits inesperados titulados ci: refresh build cache.

• Modificaciones sospechosas en los archivos de GitHub Actions.

• Ejecuciones desaparecidas del historial de automatizaciones.

La presencia de estos indicadores merece una investigación inmediata, aunque no todos implican necesariamente que el malware haya conseguido robar información.

¿Qué puedes hacer para proteger tus proyectos?

Si utilizas GitHub para desarrollar aplicaciones, almacenar código o automatizar despliegues, estas recomendaciones pueden ayudarte a reducir los riesgos:

1. Activa la autenticación de dos factores en tu cuenta.

2. Revisa periódicamente tus tokens de acceso y elimina aquellos que ya no necesitas.

3. Evita almacenar contraseñas y claves de API directamente en el código fuente.

4. Supervisa los cambios realizados en tus repositorios y workflows.

5. Configura permisos mínimos para colaboradores, aplicaciones y cuentas automatizadas.

6. Protege las ramas principales de tus proyectos.

7. Si detectas una intrusión, revoca las credenciales comprometidas, genera nuevas claves y revisa los accesos a tus servicios en la nube.

Recuerda que cambiar una contraseña no siempre es suficiente. Si un atacante ha conseguido crear nuevas credenciales o modificar los permisos de tu infraestructura, también será necesario eliminar esos accesos.

Una advertencia para todos los programadores

Este ataque demuestra que los ciberdelincuentes no necesitan encontrar necesariamente una vulnerabilidad en una gran plataforma tecnológica para comprometer miles de proyectos.

En ocasiones, una cuenta robada, un token con demasiados permisos o una automatización mal supervisada pueden convertirse en la puerta de entrada a toda una infraestructura.

En una época en la que los desarrolladores utilizamos cada vez más servicios en la nube, herramientas de inteligencia artificial y procesos automatizados, proteger nuestras credenciales debe ser tan importante como escribir buen código.

Y tú, ¿cuándo fue la última vez que revisaste las claves y permisos de tus repositorios de GitHub?