RespuestasPublicado25 fuentes
wfx-loot: cómo cuentas robadas de GitHub expusieron secretos en miles de repositorios
wfx loot usó credenciales robadas de GitHub —no una vulnerabilidad de GitHub Actions— para probar el acceso a 61.764 repositorios. Aikido cifra en al menos 1.835 los repositorios donde se ejecutó el código y se exfiltraron credenciales; otros informes citaron 1.806.
Publicado porEditado con GPT-6 LunaImágenes generadas con GPT Image 2
Respuesta de investigación
Conclusiones clave
- wfx loot usó credenciales robadas de GitHub —no una vulnerabilidad de GitHub Actions— para probar el acceso a 61.764 repositorios.
- Aikido cifra en al menos 1.835 los repositorios donde se ejecutó el código y se exfiltraron credenciales; otros informes citaron 1.806.
Prompt de IA
openai.comCreate a landscape editorial hero image for this Studio Global article: What was the wfx-loot GitHub credential-theft campaign reported by Aikido Security, when did it begin and how long was it active, how did at. Article summary: wfx-loot was a mass CI credential-theft campaign that used valid stolen GitHub credentials—not a GitHub Actions vulnerability—to place secret-stealing code in repositories the compromised accounts could write to. Aikido . Topic tags: general, general web. Style: premium digital editorial illustration, source-backed research mood, clean composition, high detail, modern web publication hero. Use reference image context only for broad subject, composition, and topical grounding; do not copy the exact image. Avoid: logos, brand marks, copyrighted characters, real person likenesses, fake screenshots, UI text, readable text, watermarks, charts with fake numbers, clic
wfx-loot fue una campaña de robo de credenciales que empleó cuentas de GitHub comprometidas para sondear repositorios y, cuando esas cuentas tenían permisos de escritura, introducir código diseñado para sustraer secretos de entornos de integración continua (CI). Aikido informó de 4.837 cuentas comprometidas y solicitudes de cambios en 61.764 repositorios; su recuento publicado indica que la carga maliciosa se ejecutó y exfiltró credenciales de al menos 1.835 repositorios.4
9
¿Cuándo ocurrió wfx-loot y cuánto duró?
La actividad comenzó alrededor de las 12:45 UTC del 10 de noviembre de 2026. Un informe sitúa el periodo de solicitudes de prueba hasta las 15:00 UTC del 11 de noviembre: unas 26 horas y 15 minutos.6
7 Esa es la ventana observada para los sondeos; no confirma que toda la actividad de la carga maliciosa o el uso posterior de las credenciales robadas terminara entonces.
Las cifras de la campaña corresponden a distintas etapas:
- 4.837 cuentas fueron reportadas como comprometidas.
- 61.764 repositorios recibieron solicitudes de cambios de prueba. Es el número de repositorios sondeados, no de aquellos donde se sabe que se ejecutó el código malicioso.
- Al menos 1.835 repositorios aparecen en el recuento publicado por Aikido de ejecución de la carga y exfiltración de credenciales.
9
Algunos informes publicados en esas mismas fechas citaron una cifra menor: 1.806.6
10 Las fuentes disponibles no explican la diferencia, por lo que conviene tratarlas como recuentos distintos y no sumarlas. La información aportada tampoco respalda la afirmación posterior de unos 1.970 casos públicos confirmados entre más de 66.000 objetivos.
Cómo comprobaron los atacantes el acceso
Los atacantes abrieron solicitudes de cambios —pull requests— con el título docs: dependency audit notes desde ramas llamadas wfx-docs. Esas solicitudes servían como pruebas para averiguar si una cuenta comprometida podía modificar el repositorio.3
4
9
Cuando los permisos lo permitían, introducían en el entorno de CI una carga diseñada para robar secretos. La campaña se apoyó en credenciales válidas robadas, no en una vulnerabilidad de GitHub Actions.4
9 OX Security describió el malware como un único script de shell de unas 1.500 líneas.
31
Algunos informes señalan que, en ciertos casos, se eliminaron los cambios maliciosos y los registros de ejecución, lo que dificultaba investigar el incidente.1
6 La evidencia disponible respalda el patrón general de sondeo, ejecución y limpieza, pero no demuestra que todos los métodos de despliegue o mensajes de commit reportados aparecieran en cada infección.
Qué buscaba la carga maliciosa
El objetivo documentado era recopilar credenciales disponibles para los trabajos de CI, incluidos secretos de GitHub Actions y credenciales de servicios en la nube. Los informes también describen intentos de obtener tokens de servicios de inteligencia artificial.3
9 El análisis de OX Security incluye credenciales de AWS, Azure y Google Cloud entre los objetivos.
31 Otros informes indican que el malware podía buscar secretos en la memoria de procesos del runner, aunque los extractos disponibles no permiten determinar con qué frecuencia tuvo éxito ese método.
17
29
Un resumen consultado describe intentos de ampliar el acceso mediante cambios en políticas de confianza de AWS y credenciales federadas de Azure.5 Se trata de comportamientos reportados, no de pruebas de que se modificaran todos los repositorios afectados o todas las cuentas en la nube. La evidencia se centra en el robo de credenciales; no demuestra el robo de código fuente ni de bases de datos de clientes.
9
15
Qué indican —y qué no— las señales reportadas
Un informe señaló que el 92 % de las 10.431 solicitudes de prueba enviadas mediante acceso de colaboradores u organizaciones seguía abierto al momento de la revisión.10
19 Esto sugiere que muchas solicitudes aún no se habían atendido, pero no demuestra que ningún propietario de repositorio o equipo de seguridad las hubiera detectado. El porcentaje no se refiere necesariamente a todas las solicitudes de cambios.
Una guía de investigación también informó de 173 solicitudes de prueba de 19 cuentas que usaron tokens a través de la aplicación de GitHub de Fly.io. Ese dato, por sí solo, no demuestra que la infraestructura de Fly.io fuera vulnerada ni que la carga maliciosa se ejecutara en todos los repositorios alcanzados mediante esos tokens.37
Qué deberían revisar los equipos de seguridad
Si tu organización pudo verse afectada, distingue entre repositorio sondeado, carga insertada, carga ejecutada y credenciales exfiltradas. No son hallazgos equivalentes.
- Busca señales de sondeo. Revisa las solicitudes tituladas
docs: dependency audit notesy las ramas llamadaswfx-docsen los repositorios donde tus cuentas podían escribir. - Comprueba los registros de CI y auditoría. Examina ejecuciones de workflows, commits, actividad de ramas y registros disponibles de servicios en la nube. Los números de ejecución ausentes pueden ser una pista, ya que se informó de ejecuciones y registros eliminados; por sí solos, no prueban una intrusión.
1
24
- Revoca los accesos posiblemente afectados. Revoca los tokens de GitHub que se sospeche que fueron comprometidos y revisa los accesos de cuentas, colaboradores y aplicaciones de GitHub.
- Rota los secretos expuestos de forma amplia. Si la carga se ejecutó, considera potencialmente comprometidos los secretos y roles de nube disponibles para ese workflow, no solo las credenciales visibles en los registros que se conservaron.
3
- Busca mecanismos de persistencia en la nube. Investiga cambios inesperados en políticas de confianza de AWS y en aplicaciones o credenciales federadas de Azure, además de claves no autorizadas u otros cambios de acceso.
5
- Preserva la evidencia. Guarda los registros de auditoría y logs que aún existan antes de realizar tareas de limpieza y documenta qué etapas del ataque están respaldadas por pruebas.
Studio Global AI
Continúe su investigación
Esta página incluye una respuesta respaldada por fuentes que puede continuar dentro de Studio Global.
La gente también pregunta
¿Cuál es la respuesta corta a "wfx-loot: cómo cuentas robadas de GitHub expusieron secretos en miles de repositorios"?
wfx loot usó credenciales robadas de GitHub —no una vulnerabilidad de GitHub Actions— para probar el acceso a 61.764 repositorios.
¿Cuáles son los puntos clave a validar primero?
wfx loot usó credenciales robadas de GitHub —no una vulnerabilidad de GitHub Actions— para probar el acceso a 61.764 repositorios. Aikido cifra en al menos 1.835 los repositorios donde se ejecutó el código y se exfiltraron credenciales; otros informes citaron 1.806.
Fuentes
bleepingcomputer.comHackers compromise 4,800 GitHub accounts to steal cloud credentials
al-ice.aiProbe, Payload, Vanish: 4,837 Hijacked GitHub Accounts Fed a CI Secret Stealer Across 61,764 Repositories
unbiasedheadlines.comStolen Logins for 4,837 GitHub Accounts Used to Run Secret Stealer in at Least 1,806 Repositories, Researchers Say