CVE-2026-49757 — Toma de control de cuentas OAuth2/OIDC de AshAuthentication

Prueba de concepto para CVE-2026-49757 — una vulnerabilidad crítica en AshAuthentication donde los callbacks OAuth2/OIDC resolvían las cuentas de usuario locales por dirección de correo electrónico en lugar del par de identidad (strategy, sub), lo que permitía la toma de control de cuentas sin autenticación.

Campo	Valor
CVE	CVE-2026-49757
CVSS 4.0	9.2 (Crítica)
CWE	CWE-290 (Omisión de autenticación por suplantación)
GHSA	GHSA-777c-2fxx-qr28
Afectado	ash_authentication >= 0.1.0, < 4.14.0 y >= 5.0.0-rc.0, < 5.0.0-rc.10
Corregido	4.14.0, 5.0.0-rc.10

Resumen del ataque

1. La víctima se registra en una aplicación objetivo utilizando AshAuthentication
2. El atacante se registra en cualquier proveedor OAuth aceptado con el correo electrónico de la víctima
3. El atacante inicia sesión a través de OAuth — la aplicación busca coincidencia por correo electrónico y crea una sesión para la cuenta de la víctima

No se necesitan credenciales de la víctima. El atacante solo necesita la dirección de correo electrónico de la víctima y una cuenta en cualquier proveedor OAuth que acepte la aplicación objetivo.

Requisitos

• Python 3.8+
• Solo biblioteca estándar (no se necesita pip install)

Uso

# Interactive mode (recommended)
python3 exploit.py

# Non-interactive mode (piped input)
echo | python3 exploit.py

Qué demuestra el PoC

Fase 1: Manejador vulnerable (coincidencia por correo electrónico)

Simula el IdentityChange.change/3 de AshAuthentication con upsert_identity: :unique_email:

• La víctima se registra con [email protected] (rol: admin)
• La víctima vincula su cuenta de Google OAuth (sub: google-victim-real-12345)
• El atacante se registra en Keycloak con [email protected] (email_verified: false)
• El atacante inicia sesión OAuth → la aplicación busca coincidencia por correo electrónico → el atacante obtiene la sesión de la víctima

Fase 2: Manejador corregido — política :reject (predeterminada)

Simula el UserResolver corregido con la búsqueda por (strategy, sub):

• El sub del atacante (keycloak-attacker-fake-789) no se encuentra en user_identities
• on_untrusted_email_match: :reject bloquea el inicio de sesión
• Ataque evitado

Fase 3: Manejador corregido — política :confirm

• El atacante intenta iniciar sesión OAuth con el correo de la víctima
• El sistema envía un token de confirmación al correo de la víctima
• La identidad solo se vincula si la víctima confirma
• Ataque evitado (el atacante no controla la bandeja de entrada del correo)

Fase 4: Manejador corregido — trust_email_verified? = true

• El usuario legítimo inicia sesión a través de Google con email_verified: true → la vinculación automática se realiza correctamente
• El atacante inicia sesión a través de Keycloak con email_verified: false → bloqueado
• Se preserva la comodidad para los proveedores de confianza y la seguridad para los que no lo son

Archivos

Archivo	Descripción
exploit.py	Script principal del PoC — ejecuta las 4 fases
vulnerable_handler.py	Manejadores de callbacks OAuth simulados (vulnerable + corregido)

La corrección (ash_authentication >= 4.14.0)

1. Módulo UserResolver — resuelve los usuarios por la identidad (strategy, sub) en lugar del correo electrónico
2. Opción on_untrusted_email_match — :reject (predeterminada), :confirm o :warn para subs desconocidos
3. Opción trust_email_verified? — indicador por proveedor, predeterminado a true para GitHub/Google/Auth0/Slack/Apple
4. Clave única de identidad — cambiada de (strategy, uid, user_id) a (strategy, uid)
5. Restricciones de upsert — user_id nunca se actualiza en caso de conflicto
6. Advertencias en tiempo de compilación — para estrategias sin identity_resource

Referencias

• NVD — CVE-2026-49757
• GHSA-777c-2fxx-qr28
• OpenID Connect Core §5.7 — Estabilidad de claims
• AshAuthentication en Hex.pm

Descargo de responsabilidad

Este PoC es únicamente para fines educativos y de pruebas defensivas. Prueba solo contra sistemas que poseas o para los que tengas autorización explícita.