Red Hat e il progetto Keycloak hanno corretto CVE-2026-18963, una falla critica nel flusso di recupero password che consente a un attaccante non autenticato di impossessarsi di qualunque account, inclusi quelli amministrativi. Red Hat, che agisce da CNA per questa vulnerabilità, le assegna un punteggio CVSS 9.1 e la classifica come CWE-640, "meccanismo debole di recupero della password dimenticata".

Per chi non lo usasse: Keycloak è il server open source di identity and access management sviluppato da Red Hat, ed è oggi il componente che, in moltissime architetture, decide chi entra e chi no. Una falla che ne permette il takeover non è una falla in un'applicazione: è una falla nella porta d'ingresso di tutte le applicazioni che stanno dietro.

Il difetto: il token via email semplicemente non serve

La causa è quella che Red Hat descrive come una validazione impropria dello stato all'interno del flusso di autenticazione reset-credentials, cioè la sequenza che Keycloak esegue quando un utente clicca su "password dimenticata".

Il funzionamento normale prevede che Keycloak invii per email un action token, e che solo chi possiede quel token possa impostare una nuova password. Nella versione vulnerabile, un attaccante invia una richiesta appositamente costruita all'endpoint reset-credentials: la sessione di autenticazione transita direttamente alla fase di aggiornamento della password, e il token inviato via email non viene mai richiesto.

Il prerequisito operativo è minimo: conoscere uno username o un indirizzo email. Nessuna interazione della vittima, nessuna credenziale preesistente. Il risultato è il takeover completo dell'account, "compresi gli account amministrativi" secondo l'advisory Red Hat.

La segnalazione, attribuita a James Paremain, è tracciata pubblicamente nell'issue #51833 del repository Keycloak, aperta il 19 agosto 2026, con etichetta severity/critical e chiusa dalla pull request #51844.

Versioni corrette

  • Keycloak upstream: 26.7.2, rilasciata il 19 agosto 2026.
  • Red Hat build of Keycloak (RHBK) 26.4: corretta dall'operator bundle 26.4.15-1 e dalle immagini rhbk/keycloak-rhel9 e rhbk/keycloak-rhel9-operator 26.4-23.
  • RHBK 26.6: corretta dall'operator bundle 26.6.6-1 e dai container 26.6-12.

Red Hat ha pubblicato quattro errata il 18 agosto 2026 (RHSA-2026:56519, 56520, 56523 e 56524). Al 24 agosto non risultava alcuna evidenza di sfruttamento né alcun exploit pubblico verificato.

Vale la pena notare che CVE-2026-18963 è solo una delle otto CVE corrette in 26.7.2. Nello stesso rilascio è stata sistemata anche CVE-2026-15571, un hash prevedibile nel meccanismo di account linking che consente il takeover attraverso un client OpenID Connect malevolo. E due settimane prima, il 5 agosto, la 26.7.1 ne aveva corrette dodici, fra cui un login SAML avviato dall'identity provider che aggirava una restrizione link-only. Il ritmo, da solo, dice qualcosa.

Cosa significa per le organizzazioni italiane

Keycloak in Italia è ovunque, e spesso in posti dove non ci si aspetterebbe di trovarlo.

Nella pubblica amministrazione è di fatto lo strumento standard per federare le identità: la community Developers Italia mantiene italia/spid-keycloak-provider, il provider di autenticazione SPID per Keycloak, e casi documentati come quello del CNR mostrano il pattern tipico — Keycloak in identity brokering davanti alle applicazioni interne, con SPID collegato dietro. È una scelta razionale, perché il software open source installabile on-premise risolve i requisiti di residenza del dato e di catena di responsabilità che una PA deve rispettare.

Nel privato lo si trova come IdP interno di software house e system integrator, come motore di SSO per portali B2B e come strato di autenticazione davanti alle API in architetture a microservizi.

Il ragionamento da fare è sul raggio d'azione. Un takeover su un'applicazione compromette quell'applicazione. Un takeover su un IdP compromette tutto ciò che si fida di quell'IdP — e "fidarsi" è letteralmente il suo mestiere. Se l'account colpito è un amministratore di realm, l'attaccante non si limita a entrare: può creare nuovi client, aggiungere protocol mapper che iniettano ruoli, configurare identity provider esterni, e da lì emettere token validi per qualunque utente. Sono operazioni che, nei log delle applicazioni a valle, appaiono come accessi perfettamente legittimi. È il tipo di compromissione che si scopre mesi dopo, oppure mai.

C'è poi un problema tipicamente italiano che va detto con franchezza. Molte installazioni Keycloak sono state messe in produzione da un integratore esterno anni fa, in un progetto chiuso e collaudato, e da allora non hanno un proprietario del patching. Nessuno le segue nel changelog, nessuno riceve le mailing list di sicurezza, nessuno sa in che versione sono. Considerando che il progetto ha rilasciato venti CVE corrette in due release nell'arco di due settimane, chi si trova su una minor version vecchia non ha davanti un aggiornamento di dieci minuti: ha davanti un progetto di migrazione, e nel frattempo resta esposto. La domanda da porsi oggi non è solo "quale versione di Keycloak abbiamo", è "chi, per contratto, è responsabile di aggiornarla, e con quali tempi di intervento".

Il contesto normativo

Un account takeover sull'identity provider è, sotto il profilo regolamentare, uno degli scenari peggiori possibili.

  • NIS2 (in Italia d.lgs. 138/2024) colloca il controllo degli accessi, la gestione dell'identità e l'autenticazione a più fattori fra le misure minime di gestione del rischio richieste ai soggetti essenziali e importanti. Un IdP non aggiornato per una falla critica nota è difficilmente difendibile in sede ispettiva. E se la compromissione si verifica, l'incidente è quasi certamente significativo: preallerta al CSIRT Italia entro 24 ore e notifica completa entro 72.
  • GDPR: se Keycloak media l'accesso a sistemi che trattano dati personali, il takeover di un account amministrativo è una violazione dei dati personali a tutti gli effetti, con obbligo di valutazione e — se sussiste rischio per i diritti degli interessati — notifica al Garante entro 72 ore ai sensi dell'art. 33. La correzione tempestiva di una falla con CVSS 9.1 rientra invece a pieno titolo fra le misure adeguate dell'art. 32.
  • Per le PA, l'esposizione è aggravata dal fatto che l'identità mediata è spesso un'identità digitale nazionale: la compromissione del broker ha implicazioni che vanno oltre la singola amministrazione.

Cosa fare subito

  • Fate l'inventario delle istanze Keycloak e delle loro versioni. Comprese quelle dimenticate: ambienti di collaudo esposti su internet, istanze di un progetto chiuso, container in cluster gestiti da terzi. È il passaggio che quasi sempre riserva sorprese.
  • Aggiornate a Keycloak 26.7.2 (upstream) oppure a RHBK 26.4.15 / 26.6.6 con le immagini e gli operator bundle indicati negli errata Red Hat.
  • Se non potete aggiornare subito, applicate la mitigazione ufficiale: disattivare la funzionalità "Forgot password" da Realm settings > Login > Forgot password. Attenzione al dettaglio che fa la differenza: va applicata su ogni singolo realm, non solo su quello principale. Elencate i realm da console o da API e spuntateli uno per uno — il realm dimenticato è esattamente quello che vi farà male.
  • Mettete in conto il costo operativo della mitigazione. Disattivare il recupero password sposta il carico sull'help desk e crea un incentivo perverso a "fare in fretta" sulle procedure di reset manuale. Se la adottate, definite prima come verificherete l'identità di chi chiama.
  • Fate caccia retroattiva nei log eventi di Keycloak. Cercate eventi UPDATE_PASSWORD privi di un corrispondente SEND_RESET_PASSWORD per lo stesso utente e nella stessa finestra temporale, e reset di password su account amministrativi. Se gli eventi non sono abilitati o non sono esportati verso un SIEM, questo è il momento di rimediare.
  • Dopo l'aggiornamento, revocate le sessioni e i refresh token e verificate che non siano comparsi client, mapper o identity provider che nessuno ricorda di aver configurato.
  • Riducete la superficie: la console di amministrazione di Keycloak non dovrebbe essere raggiungibile da internet. Imponete MFA su tutti gli account amministrativi di realm e separate le utenze amministrative da quelle applicative.

Un'ultima nota di onestà intellettuale: nessuna delle fonti pubblicate chiarisce se siano vulnerabili tutti i realm con il recupero password attivo o soltanto certe configurazioni del flusso reset-credentials. In assenza di quel dettaglio, l'unica ipotesi prudente è considerarsi esposti.