Keycloak, CVE-2026-18963 permette il takeover degli account senza autenticazione

🛡️ Executive Summary

• CVE-2026-18963 bypassa la verifica email nel flusso reset-credentials e permette a un attaccante remoto non autenticato di impostare nuove credenziali.
• Red Hat valuta la falla Critical con CVSS 9.1: l’impatto può includere anche account amministrativi e accesso ai servizi federati dietro Keycloak.
• Keycloak 26.7.2 e Red Hat build 26.4.15/26.6.6 correggono il problema; in assenza di patch va disabilitata temporaneamente la funzione Forgot password.

Keycloak corregge una vulnerabilità critica nel processo di recupero delle password che può consentire a un attaccante remoto e non autenticato di assumere il controllo di qualsiasi account interessato, compresi quelli amministrativi. La falla, identificata come CVE-2026-18963 e valutata CVSS 9.1 da Red Hat, deriva da una validazione impropria dello stato nel flusso reset-credentials: attraverso una richiesta appositamente costruita, il server può arrivare direttamente alla fase di impostazione della nuova password senza verificare il token normalmente inviato via email. Il rischio è particolarmente elevato perché Keycloak opera spesso come punto centrale di autenticazione per applicazioni, API e servizi aziendali.

CVE-2026-18963 salta il token inviato via email

Secondo l’advisory ufficiale di Red Hat per CVE-2026-18963, il problema si trova nel componente keycloak-services, motore centrale utilizzato per i flussi di identity and access management della Red Hat build di Keycloak. Un normale recupero password dovrebbe iniziare con l’identificazione dell’account, proseguire con l’invio di un collegamento contenente un action token verso l’indirizzo email registrato e permettere la modifica delle credenziali soltanto dopo che quel token è stato verificato. CVE-2026-18963 interrompe questa catena di fiducia. La gestione dello stato della sessione di autenticazione permette a una richiesta costruita dall’attaccante di far avanzare direttamente il flusso verso la fase di Update Password, saltando la conferma del possesso dell’email. La descrizione tecnica pubblicata nel bug report di Red Hat conferma che l’attaccante non deve possedere il token ricevuto via posta elettronica e può quindi impostare direttamente nuove credenziali per la vittima. Si tratta di una debolezza CWE-640, Weak Password Recovery Mechanism for Forgotten Password, ma le conseguenze sono molto più gravi di un semplice errore nella procedura di recupero.

Nessuna autenticazione e nessuna interazione della vittima

La gravità deriva soprattutto dai prerequisiti estremamente bassi. Il vettore CVSS indicato da Red Hat è AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N: la vulnerabilità è raggiungibile attraverso la rete, richiede bassa complessità, non necessita privilegi preliminari e non richiede alcuna interazione da parte della vittima. Non serve quindi convincere l’utente a cliccare un link di phishing, intercettare l’email di reset o compromettere preventivamente un account con pochi privilegi. È sufficiente poter raggiungere il flusso vulnerabile. Questo distingue CVE-2026-18963 da molte vulnerabilità IAM nelle quali l’attaccante deve prima possedere un token, un client OAuth valido o autorizzazioni limitate. La centralità dell’identità rende inoltre il possibile impatto superiore alla compromissione della singola applicazione: un account Keycloak può rappresentare la chiave d’accesso a più servizi federati. È lo stesso motivo per cui vulnerabilità su piattaforme centrali di autenticazione e gestione, come la recente RCE critica in Microsoft Entra ID, assumono priorità immediata nel vulnerability management aziendale.

Anche gli amministratori possono essere presi di mira

La documentazione Red Hat indica esplicitamente che uno sfruttamento riuscito può produrre il complete account takeover di qualsiasi utente, inclusi gli account amministrativi. Se l’obiettivo possiede privilegi di amministrazione sul realm, l’effetto può quindi propagarsi molto oltre l’account iniziale. Un amministratore Keycloak può gestire utenti, client, ruoli, provider di identità, redirect URI e configurazioni di autenticazione, permettendo a un aggressore di trasformare una compromissione dell’identità in accesso persistente all’intera infrastruttura federata. In ambienti enterprise Keycloak viene frequentemente usato davanti ad applicazioni interne, cluster Kubernetes, servizi cloud, portali Web e API. Per questo un reset non autorizzato di un account privilegiato non equivale semplicemente alla perdita di una password: può diventare il punto iniziale per privilege escalation, furto di token, modifica dei client OIDC e accesso a sistemi sottostanti. La criticità ricorda quella delle vulnerabilità di bypass dell’autenticazione osservate su N-able N-central, dove l’accesso amministrativo remoto permetteva di raggiungere anche gli endpoint gestiti.

Keycloak 26.7.2 chiude la falla insieme ad altre sette CVE

Per il ramo upstream, la correzione è disponibile in Keycloak 26.7.2, pubblicato il 19 agosto 2026. La versione include CVE-2026-18963 tra otto vulnerabilità corrette e arriva soltanto due settimane dopo Keycloak 26.7.1, che aveva già risolto dodici CVE. Per i clienti Red Hat build of Keycloak, le release da considerare corrette sono 26.4.15 e 26.6.6, con versioni specifiche dei container e degli operator bundle rilasciate attraverso gli errata RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 e RHSA-2026:56524. La frequenza degli aggiornamenti mostra una superficie d’attacco particolarmente sensibile, perché Keycloak concentra numerosi protocolli e flussi complessi: OIDC, OAuth, SAML, account linking, federazione LDAP, Dynamic Client Registration e password recovery. Nelle settimane precedenti erano già emerse vulnerabilità come CVE-2026-16102, attraverso cui la Dynamic Client Registration poteva consentire la falsificazione di ruoli amministrativi, e CVE-2026-11800, un bypass della verifica JWT. La situazione è paragonabile ai cicli di patch accelerati osservati su altri componenti enterprise critici, dove CISA sta progressivamente aumentando la priorità per authentication bypass e RCE su sistemi centrali.

Disabilitare Forgot password è la mitigazione temporanea

Per gli ambienti che non possono installare immediatamente le versioni corrette, Red Hat indica una mitigazione molto netta: disabilitare la funzione “Forgot password” in tutti i realm. Nella console di amministrazione della Red Hat build di Keycloak l’opzione si trova sotto Realm settings → Login → Forgot password. La configurazione deve essere applicata a ogni realm nel quale la funzione sia attiva. Si tratta di una misura temporanea e operativamente scomoda, perché impedisce agli utenti di recuperare autonomamente l’accesso, ma elimina il flusso vulnerabile in attesa dell’upgrade. Gli amministratori dovrebbero inoltre verificare i log delle richieste recenti al percorso reset-credentials, cercando anomalie come reset password non preceduti da una normale validazione tramite email, cambiamenti inattesi sugli account privilegiati e login immediatamente successivi alla modifica delle credenziali. Red Hat non segnala al momento exploit attivi e, al 24 agosto 2026, non risultano PoC pubblici verificati, quindi non esistono elementi per affermare che CVE-2026-18963 sia già sfruttata in natura.

Il problema mette in discussione il confine di fiducia nel password recovery

Il punto tecnicamente più interessante è che CVE-2026-18963 non rompe una primitiva crittografica e non compromette direttamente password o token. Sfrutta invece un errore nella state machine del processo di autenticazione. Il server possiede tutte le primitive corrette per verificare il link inviato via email, ma permette al flusso di arrivare allo stato successivo senza provare che quello stato precedente sia stato completato correttamente. È una categoria di difetti particolarmente pericolosa nei sistemi IAM, perché la sicurezza dipende da sequenze di passaggi concatenati: autenticazione primaria, MFA, password reset, account linking, consent e token exchange. Saltare uno solo di questi passaggi può produrre lo stesso effetto di una password rubata. È un principio già visibile nelle vulnerabilità di Cisco FMC legate alle credenziali statiche e ai controlli centrali di accesso, dove la compromissione del livello di gestione modifica immediatamente il rischio dell’intera infrastruttura.

Gli amministratori Keycloak devono trattare la patch come prioritaria

La combinazione tra assenza di autenticazione, nessuna interazione della vittima, bassa complessità e possibilità di takeover amministrativo rende CVE-2026-18963 una vulnerabilità da correggere rapidamente anche in assenza di evidenze di sfruttamento attivo. La priorità aumenta ulteriormente per istanze esposte direttamente a Internet o utilizzate come Identity Provider centrale per molte applicazioni.

La prima azione deve essere verificare la versione realmente in esecuzione, comprendendo container e operatori Kubernetes, perché l’aggiornamento dell’applicazione senza quello dell’immagine o dell’operator può lasciare componenti vulnerabili. La seconda è aggiornare a Keycloak 26.7.2, oppure alle build Red Hat corrette 26.4.15 e 26.6.6. Dove questo non sia immediatamente possibile, la funzione di recupero password deve essere disabilitata temporaneamente. Un sistema IAM deve rappresentare il punto nel quale l’identità viene verificata, non il punto attraverso cui un attaccante può riscriverla senza credenziali: CVE-2026-18963 colpisce esattamente questa garanzia fondamentale.