James Harton

**Nome do Software Vulnerável e Versões Afetadas** ash authentication versões 3.10.5 até 4.14.1 ash authentication versões 5.0.0-rc.0 até 5.0.0-rc.12 **Description** Uma autenticação inadequada permite que JSON Web Tokens (JWTs) com finalidade limitada sejam reutilizados como credenciais completas de API bearer quando um recurso utiliza verificação de token bearer sem estado. A função auxiliar `retrieve from bearer/3` verifica a assinatura de um JWT Authorization: Bearer e rejeita tokens que contenham uma reivindicação `act`, mas não verifica se a reivindicação `purpose` do token é igual a `user`. Quando o recurso é configurado com `require token presence for authentication?` definido como `false`, a função `validate token/3` retorna `{:ok, nil}` sem consultar o recurso de token, ignorando as verificações de finalidade subsequentes. Como resultado, JWTs válidos e não expirados emitidos para finalidades restritas — como o token `sign in` emitido pelo WebAuthn ou pela estratégia de Password — são aceitos como credenciais bearer de propósito geral, resultando em uma atribuição completa de `current user`. Um invasor que obtenha um token `sign in` válido pode se autenticar como o sujeito alvo, ignorando a semântica de uso único e revogação. Isso requer que a aplicação utilize `retrieve from bearer/3` em uma rota acessível e empregue WebAuthn ou a estratégia de Password com `sign in tokens enabled?` definido como `true`. **Recommendations** Atualize o ash authentication para a versão 4.14.2 ou posterior. Atualize o ash authentication para a versão 5.0.0-rc.13 ou posterior. Defina `require token presence for authentication?` como `true` para impor a verificação de finalidade em relação ao registro de token armazenado. Restrinja o acesso a rotas que utilizam a função auxiliar `retrieve from bearer/3`.

**Nome do Software Vulnerável e Versões Afetadas** ash authentication versões 4.8.0 até 4.14.1 ash authentication versões 5.0.0-rc.0 até 5.0.0-rc.12 **Description** Ocorre cross-site scripting (XSS) refletido quando uma estratégia é configurada com `require interaction?` definido como true. O software exibe páginas HTML intermediárias que incorporam parâmetros de requisição diretamente em atributos de valor de entrada oculta sem a devida codificação HTML. Especificamente, o parâmetro `confirm` é interpolado em `lib/ash authentication/add ons/confirmation/confirmation form.html.eex` e o parâmetro de token de link mágico é interpolado em `lib/ash authentication/strategies/magic link/sign in form.html.eex`. Como esses templates utilizam expressões simples que não realizam a codificação e as funções `accept/2` em `AshAuthentication.AddOn.Confirmation.Plug` e `AshAuthentication.Strategy.MagicLink.Plug` não validam os valores, um invasor não autenticado pode criar uma URL para injetar marcações maliciosas. O script injetado é executado na origem da aplicação, permitindo o acesso a cookies, sessões e respostas de mesma origem. **Recommendations** Atualize o ash authentication para a versão 4.14.2 ou posterior. Atualize o ash authentication para a versão 5.0.0-rc.13 ou posterior.

**Nome do Software Vulnerável e Versões Afetadas** ash authentication versões 0.1.0 até 4.13.x ash authentication versões 5.0.0-rc.0 até 5.0.0-rc.9 **Description** Uma falha de bypass de autenticação por spoofing permite a invasão de contas de usuários locais durante o login via OAuth2 ou OIDC. O problema ocorre porque o software associa usuários locais pelo endereço de e-mail em vez de utilizar a combinação de claims `iss` (issuer) e `sub` (subject) do OpenID Connect, que são os únicos identificadores estáveis e únicos para um usuário final. Um invasor não autenticado pode registrar uma conta em um provedor OAuth aceito usando o e-mail de uma vítima — incluindo e-mails não verificados ou reutilizados — para obter privilégios locais totais da conta da vítima. **Recommendations** Atualizar as versões 0.1.0 até 4.13.x para a versão 4.14.0. Atualizar as versões 5.0.0-rc.0 até 5.0.0-rc.9 para a versão 5.0.0-rc.10.

**Name of the Vulnerable Software and Affected Versions** ash-project ash authentication phoenix versions prior to 2.10.0 **Description** The issue affects the ash authentication phoenix library, where session tokens remain valid on the server after a user logs out. This creates a security gap where compromised tokens can continue to work, even after the user logs out. The sessions stored in the database still expire, limiting the duration during which this could be exploited. Users cannot fully invalidate their sessions when logging out from shared or potentially compromised devices. However, changing one's password does invalidate all other sessions. This may cause compliance issues with security frameworks requiring complete session invalidation. **Recommendations** Upgrade to version 2.10.0. After upgrading, update the AuthController implementation to use the new `clear session/2` function with the OTP app name. If the setting `require token presence for authentication?` is not set to `true` in the `tokens` section, enable it if possible, or set `authentication.session identifier` to `:jti`. Note that setting `require token presence for authentication?` to `true` or setting `authentication.session identifier` to `:jti` will log out all currently authenticated users if this was not previously configured. As a temporary workaround, manually revoke tokens in the `logout/2` handler in the auth controller.