CVE-2026-65633 in ash_authentication
Sumário
de VulDB • 25/08/2026
Vulnerabilidade de autenticação inadequada no AshAuthentication do team-alembic permite que JWTs com propósito limitado sejam reutilizados como credenciais API bearer completas quando um recurso utiliza verificação de token bearer sem estado (stateless).
O auxiliar de autenticação por token bearer `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifica a assinatura do JWT no cabeçalho `Authorization: Bearer` e rejeita tokens que contêm uma declaração `act`, mas não realiza nenhuma verificação para garantir que a declaração de propósito (purpose claim) do token seja igual a "user" na fronteira bearer. Quando o recurso está configurado com `require_token_presence_for_authentication?: false` (o padrão da DSL), o auxiliar subsequente `validate_token/3` retorna `{ok, nil}` sem consultar o recurso do token; portanto, nenhuma verificação posterior sobre o propósito é realizada. Como resultado, qualquer JWT válido e não expirado emitido pela própria biblioteca para um fluxo de propósito único e restrito (notavelmente o token com `purpose: sign_in`, que o WebAuthn emite sempre durante o login, e que a estratégia Password emite quando os tokens de login estão habilitados) é aceito diretamente como uma credencial bearer de uso geral, resultando na atribuição completa do usuário atual (`current_user`).
Isso contorna o contrato de troca de tokens pretendido pela biblioteca, no qual o token `sign_in` deve ser apresentado exatamente uma vez a um processo que valida a declaração de propósito e revoga imediatamente o token. O primeiro uso de um token de login ainda válido, apresentado diretamente no cabeçalho Authorization, tem sucesso porque o caminho bearer sem estado nunca o limita ao escopo `purpose == "user"`.
Um atacante que obtenha um token de login não trocado para um sujeito alvo (por exemplo, através de vazamento em logs ou referrer, interceptação do canal de entrega de link mágico, ou intermediário parcialmente comprometido) pode apresentá-lo como um token bearer e ser autenticado como esse sujeito, contornando completamente as semânticas de uso único e revogação pretendidas. A exploração também requer que o aplicativo host configure `retrieve_from_bearer/3` em uma rota acessível e utilize ou WebAuthn (os tokens de login são sempre emitidos) ou a estratégia Password com `sign_in_tokens_enabled?: true`. Recursos configurados com `require_token_presence_for_authentication?: true` (incluindo aplicativos gerados pelo instalador Igniter desde a v4.5.0) e o caminho baseado em sessão (`authenticate_resource_from_session/4`) aplicam a verificação de `purpose == "user"` contra o registro do token armazenado e não são afetados.
Este problema afeta ash_authentication: das versões 3.10.5 anteriores à 4.14.2 e das versões 5.0.0-rc.0 anteriores à 5.0.0-rc.13.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.