CVE-2026-18963: takeover account Keycloak in 5 secondi bypassando la MFA

Il 18 agosto 2026 Red Hat ha pubblicato l'advisory CVE-2026-18963, una vulnerabilità critica nel motore di identità Keycloak che consente a un attaccante remoto e non autenticato di impossessarsi di qualsiasi account — amministrativi inclusi — bypassando completamente la verifica email e rendendo inutile l'autenticazione a due fattori. Il punteggio CVSS è 9.1: rete, bassa complessità, nessun privilegio richiesto, nessuna interazione utente.

Come funziona il flaw: una transizione di stato non autorizzata

La vulnerabilità risiede nel componente keycloak-services, cuore del flusso reset-credentials di Keycloak. Secondo l'analisi tecnica pubblicata nell'issue #51833 del repository ufficiale, il bug è stato introdotto nella versione 26.0.0 dal commit 6a9e60b: la variabile di stato AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED, implementata come booleano, permette una transizione non autorizzata verso la fase UPDATE_PASSWORD senza validazione del token email.

Il meccanismo si combina con ResetCredentialEmail.action(), che restituisce successo anche in assenza di un action token valido. Il risultato: un caller non autenticato salta il gate del reset-email, il controllo di sicurezza che dovrebbe garantire che solo il proprietario dell'indirizzo email possa completare la procedura.

"A flaw was found in the reset-credentials flow of the keycloak-services component... The issue allows an unauthenticated attacker to force the password reset process for any user without needing to click the required email verification link" — Red Hat Security Advisory

Perché la MFA diventa carta straccia

L'angolo più insidioso di CVE-2026-18963 non è tecnicamente il bypass del reset, ma la sua interazione con l'architettura di autenticazione di Keycloak. Il flusso reset password è progettato per saltare il passaggio 2FA: una volta ottenuto l'accesso tramite nuove credenziali impostate dall'attaccante, l'account è compromesso e l'autenticazione a due fattori può essere rimossa.

Come ha documentato il ricercatore SamTV12345 nell'issue GitHub: "the MFA is not of interest. Because the reset password flow by design skips the 2fa step. I can break into an account with MFA and e.g. remove the 2FA". La conferma è arrivata dai maintainer del progetto. Per organizzazioni che avevano investito su MFA come contro-misura privilegiata, la vulnerabilità rappresenta un ricalcolo completo del rischio: il perimetro più forte diventa irrilevante di fronte a un flusso di recovery progettato senza sufficiente isolamento.

Versioni colpite e patch disponibili

Il codice vulnerabile è presente sia nella community Keycloak che nella distribuzione commerciale Red Hat Build of Keycloak (RHBK), come confermato esplicitamente dai maintainer: "Same upstream code as the Red Hat build". Non si tratta quindi di un problema limitato agli utenti enterprise con contratto di supporto.

Le patch sono disponibili nelle versioni 26.7.2, 26.4.15 e 26.6.6. L'advisory Red Hat elenca quattro RHSA distinte (RHSA-2026:56519, 56520, 56523, 56524) per coprire le diverse linee di release. Per le organizzazioni che non possono aggiornare immediatamente, l'unica mitigazione documentata è la disabilitazione della funzionalità Forgot password in tutti i realm.

Cosa fare adesso

• Verificare la versione in produzione: identificare istanze Keycloak nelle versioni 26.0.0 o successive, inclusi ambienti self-managed e deployment containerizzati.
• Pianificare l'upgrade alle versioni patchate 26.7.2, 26.4.15 o 26.6.6 in base alla linea di release adottata, con priorità per i realm con account amministrativi esposti su internet.
• Disabilitare "Forgot password" come mitigazione temporanea sui sistemi che non possono essere aggiornati nel breve termine, valutando l'impatto operativo su utenti e procedure di recovery.
• Controllare i log di autenticazione per anomalie nel flusso reset-credentials, in particolare transizioni verso UPDATE_PASSWORD senza precedente validazione token email.

Il problema del design, non solo del codice

CVE-2026-18963 apre una riflessione più ampia su come i flussi di recovery vengono threat-modeled nei sistemi di identità moderni. Il commit 6a9e60b che ha introdotto il booleano vulnerabile faceva parte di una funzionalità legittima — la selezione del metodo di autenticazione — ma la sua interazione con ResetCredentialEmail.action() non è stata valutata nel contesto del flusso password reset. Il risultato è un classic state machine flaw: uno stato intermedio diventa trampoline per uno stato terminale senza le guardie di sicurezza previste.

La presenza di un PoC pubblico con takeover in ~5 secondi, combinata con la mancanza di exploitabilità in-the-wild confermata, crea una finestra di rischio particolarmente stretta. Le organizzazioni che gestiscono identità federate per terzi — provider di identità, SaaS multi-tenant, piattaforme pubbliche — hanno interesse a trattare questa patch come security-critical, non solo come aggiornamento di manutenzione.

Il ricercatore SamTV12345 ha reso il rischio tangibile con il suo PoC: "I was able to create a script. If I know the username/email of that user that account is taken over in 5 seconds or so". La velocità di esecuzione, unita alla semplicità dei prerequisiti (username o email noti), posiziona questa vulnerabilità nella categoria delle minacce che richiedono risposta immediata.

Per i security team, la lezione operativa è chiara: i flussi di recovery non possono essere trattati come percorso secondario. Quando un flusso di reset password bypassa l'intero stack di autenticazione forte, il confine tra recovery e compromissione si dissolve. La patch esiste, è disponibile, e ogni giorno di attesa espone account che gli utenti — ragionevolmente — credono protetti.

Fonti

• https://github.com/keycloak/keycloak/issues/51833
• https://access.redhat.com/security/cve/cve-2026-18963
• https://cve.imfht.com/detail/CVE-2026-18963?lang=en
• https://www.webpronews.com/critical-keycloak-vulnerability-cve-2026-18963-enables-account-takeover-via-password-reset-bypass
• https://www.cve.org/CVERecord?id=CVE-2026-18963