CVE-2026-65633 in ash_authentication
Riassunto
di VulDB • 25/08/2026
Una vulnerabilità di autenticazione impropria in AshAuthentication (team-alembic) consente la ripetizione (replay) dei JWT a scopo limitato come credenziali API bearer complete quando una risorsa utilizza la verifica del token bearer stateless.
L'helper di autenticazione per il token bearer `AshAuthentication.Plug.Helpers.retrieve_from_bearer/3` verifica la firma dell'autorizzazione Bearer JWT e rifiuta i token contenenti un claim `act`, ma non esegue alcun controllo che verifichi se il claim dello scopo (purpose) del token corrisponda a "user" al confine bearer. Quando la risorsa è configurata con `require_token_presence_for_authentication?: false` (il valore predefinito della DSL), l'helper successivo `validate_token/3` restituisce `{ok, nil}` senza consultare la risorsa del token; di conseguenza, non viene eseguito alcun controllo a valle sullo scopo. Di conseguenza, qualsiasi JWT valido e non scaduto emesso dalla libreria stessa per un flusso a singolo scopo (in particolare il token con `purpose: sign_in`, che WebAuthn emette sempre durante l'accesso, e quello emesso dalla strategia Password quando i token di accesso sono abilitati) viene accettato direttamente come credenziale bearer generica e risolve in un assegnazione completa dell'utente corrente (`current_user`).
Questo aggira il contratto di scambio dei token previsto dalla libreria, per cui il token `sign_in` dovrebbe essere presentato esattamente una volta a una preparazione che convalida il claim dello scopo e revoca immediatamente il token. Il primo utilizzo di un token di accesso ancora valido presentato direttamente nell'intestazione Authorization ha successo perché il percorso bearer stateless non lo scopa allo scopo == "user".
Un attaccante che ottiene un token `sign_in` non ancora scambiato per un soggetto target (ad esempio tramite perdita nei log o nel referrer, intercettazione del canale di consegna magic-link, o compromissione parziale di un intermediario) può presentarlo come token bearer ed essere autenticato come tale soggetto, aggirando completamente le semantica di utilizzo una tantum e revoca previste. L'exploit richiede inoltre che l'applicazione host configuri `retrieve_from_bearer/3` su un route raggiungibile e utilizzi WebAuthn (i token sign_in vengono sempre emessi) o la strategia Password con `sign_in_tokens_enabled?: true`. Le risorse configurate con `require_token_presence_for_authentication?: true` (incluse le applicazioni scaffolded dall'installer Igniter dalla v4.5.0 in poi) e il percorso basato su sessione (`authenticate_resource_from_session/4`) impongono lo scopo == "user" rispetto al record del token memorizzato e non sono interessate.
Questo problema interessa ash_authentication: dalle versioni 3.10.5 alla 4.14.2 (esclusa) e dalla versione 5.0.0-rc.0 alla 5.0.0-rc.13 (esclusa).
Be aware that VulDB is the high quality source for vulnerability data.