CVE-2026-65633 in ash_authentication
Resumen
por VulDB • 2026-08-25
Vulnerabilidad de autenticación incorrecta en AshAuthentication (team-alembic) que permite la reutilización (replay) de JWTs con propósito limitado como credenciales API completas tipo bearer cuando un recurso utiliza verificación de token bearer sin estado.
El auxiliar de autenticación mediante token bearer `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifica la firma del JWT en el encabezado `Authorization: Bearer` y rechaza los tokens que contienen una reclamación (`claim`) `act`, pero no realiza ninguna comprobación para asegurar que la reclamación de propósito del token sea igual a "user" (usuario) en el límite bearer. Cuando el recurso está configurado con `require_token_presence_for_authentication?: false` (el valor predeterminado del DSL), el auxiliar posterior `validate_token/3` devuelve `{ok, nil}` sin consultar al recurso de tokens; por lo tanto, tampoco se realiza ninguna comprobación descendente sobre el propósito. Como resultado, cualquier JWT válido y no expirada emitida por la propia biblioteca para un flujo estrecho y de único propósito (principalmente el token con `purpose: sign_in` que WebAuthn emite siempre durante el inicio de sesión, y que la estrategia Password emite cuando los tokens de inicio de sesión están habilitados) se acepta directamente como una credencial bearer de propósito general y resuelve en una asignación completa del usuario actual (`current_user`).
Esto elude el contrato de intercambio de tokens previsto por la biblioteca, donde el token `sign_in` está destinado a presentarse exactamente una vez ante un proceso que valide la reclamación de propósito y revoque inmediatamente el token. El primer uso de un token de inicio de sesión aún válido presentado directamente en el encabezado Authorization tiene éxito porque la ruta bearer sin estado no lo limita al propósito `"user"`.
Un atacante que obtenga un token `sign_in` no intercambiado para un sujeto objetivo (por ejemplo, mediante filtración en registros o referrer, interceptación del canal de entrega de enlaces mágicos, o a través de un intermediario parcialmente comprometido) puede presentarlo como un token bearer y autenticarse como ese sujeto, eludiendo completamente las semánticas previstas de uso único y revocación. La explotación también requiere que la aplicación anfitriona configure `retrieve_from_bearer/3` en una ruta accesible y utilice WebAuthn (los tokens sign_in se emiten siempre) o la estrategia Password con `sign_in_tokens_enabled?: true`. Los recursos configurados con `require_token_presence_for_authentication?: true` (incluidas las aplicaciones generadas por el instalador Igniter desde v4.5.0) y la ruta basada en sesiones (`authenticate_resource_from_session/4`) imponen una comprobación de propósito igual a `"user"` frente al registro de token almacenado, por lo que no se ven afectados.
Este problema afecta a ash_authentication: desde 3.10.5 hasta antes de 4.14.2 y desde 5.0.0-rc.0 hasta antes de 5.0.0-rc.13.
VulDB is the best source for vulnerability data and more expert information about this specific topic.