Atacantes explotan notificaciones de GitHub para robar acceso OAuth a 12,000 repositorios

Investigadores de seguridad han documentado una sofisticada campaña de phishing que abusa del sistema de notificaciones de GitHub para engañar a desarrolladores y robarles tokens de acceso OAuth. El ataque, identificado por analistas de Atsika, ha impactado aproximadamente 12.000 repositorios y aprovecha la infraestructura de confianza de la propia plataforma para evadir filtros de correo y conciencias técnicas. Los correos electrónicos maliciosos se originan desde direcciones oficiales de GitHub, pasando validaciones SPF y DKIM sin problemas, lo que los hace indistinguibles de notificaciones legítimas a simple vista.

La técnica combina dos vectores: el sistema de menciones en GitHub Issues y aplicaciones OAuth maliciosas. Los atacantes crean una cuenta falsa que simula ser un servicio de seguridad oficial, con nombres como "GH-Security/alert" y publican issues públicos mencionando a usuarios específicos con @usuario. GitHub envía automáticamente un correo al usuario mencionado desde su propio dominio noreply@github.com. Dentro del mensaje, los atacantes insertan enlaces acortados que dirigen a una página de autorización OAuth real de GitHub, donde la víctima voluntariamente concede permisos que cree necesarios para "solucionar" un problema de seguridad inexistente.

El análisis técnico completo publicado por Atsika detalla que las aplicaciones OAuth maliciosas solicitan permisos extremadamente sensibles: acceso completo de lectura y escritura a repositorios públicos y privados, control sobre GitHub Actions workflows, y acceso al correo electrónico y perfil del usuario.

Un aspecto particularmente insidioso del ataque es la explotación de una condición de carrera tipo TOCTOU (Time-of-Check Time-of-Use) en el sistema de notificaciones de GitHub. Los atacantes publican el issue con el contenido malicioso, esperan dos o tres segundos a que se dispare el correo, y luego editan o eliminan el contenido completamente. El email que recibe la víctima contiene el mensaje de phishing pulido, pero cualquier persona que revise el repositorio directamente encontrará un issue vacío o con un título inofensivo como "Loading error". Esta técnica dificulta enormemente la investigación posterior y la atribución, ya que los atacantes también pueden borrar el historial de revisiones.

El coste de montar esta infraestructura de ataque es cero. Según la documentación técnica, un atacante necesita únicamente una cuenta de GitHub gratuita, una aplicación OAuth simple, el proof-of-concept "MalGitApp" ocupa aproximadamente 200 líneas de código y un servidor de hosting gratuito para recibir los tokens. Los enlaces a la página de autorización se camuflan mediante servicios de acortamiento de URLs, ya que GitHub detecta y marca como sospechosos los enlaces directos a flujos OAuth.

Una vez que el desarrollador autoriza la aplicación, el atacante recibe un token de acceso válido que le permite clonar repositorios privados, inyectar código malicioso en codebases existentes, manipular pipelines de CI/CD, y mantener persistencia sin necesidad de robar contraseñas ni eludir autenticación multifactor.

El vector representa una amenaza seria para la cadena de suministro de software. Comprometer la cuenta de GitHub de un solo desarrollador puede permitir la inyección de backdoors en proyectos con millones de descargas semanales, como ilustran casos recientes en proyectos como Axios y LiteLLM. Las organizaciones deben auditar regularmente las aplicaciones OAuth autorizadas en los ajustes de cuenta de GitHub, revocando cualquier app desconocida o con permisos excesivos.

Los equipos de seguridad deben implementar controles que restrinjan qué aplicaciones pueden solicitar scopes de repositorio y workflow, y monitorear la actividad de tokens OAuth en lugar de depender exclusivamente de alertas de login. Ninguna herramienta de seguridad legítima solicitará acceso completo a repositorios privados a través de un correo no solicitado.