kyos-public/keycloak-cve-2026-18963-huntCaccia alle tracce di sfruttamento di CVE-2026-18963 (acquisizione non autenticata di account Keycloak) nel database di Keycloak.
Uno script psql che cerca in un database PostgreSQL di Keycloak le tracce
dello sfruttamento di CVE-2026-18963 (account takeover non autenticato tramite
il flusso reset-credentials).
Pubblicato da KYOS. Lo abbiamo scritto mentre applicavamo le correzioni alle distribuzioni Keycloak che gestiamo, per verificare che nessuno fosse stato compromesso durante la finestra di esposizione.
CVE-2026-18963 è una falla nel flusso reset-credentials di keycloak-services
(keycloak#51833). Un
attaccante non autenticato può completare il processo di reset della password
per qualsiasi utente senza cliccare il link di verifica via mail, e poi
impostare una nuova password sull'account. Non è richiesta alcuna interazione
con l'utente.
Severità: Critical, CVSS v3.1 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N),
secondo Red Hat e
NVD. La causa principale è
una validazione impropria dello stato nel flusso di autenticazione, corretta in
.
| Stream | Corretto in |
|---|---|
| 26.7.x | 26.7.2 (note di rilascio) |
| 26.6.x | 26.6.6 |
| 26.4.x (LTS) | 26.4.15 |
| 26.8 | 26.8.0 |
Tutto ciò che è al di sotto di queste versioni negli stream supportati è vulnerabile. Le release fuori supporto (26.5.x, 26.3 e precedenti) non ricevono correzioni: consideratevi esposti e aggiornate a uno stream corretto. Red Hat elenca il legacy RH-SSO 7 come non interessato; la Red Hat Build of Keycloak 26.4/26.6 è corretta in 26.4.15-1 / 26.6.6-1.
Disabilitare il reset password self-service rimuove il punto di ingresso
vulnerabile: Admin console > Realm settings > Login > "Forgot password" off,
per ogni realm. Tramite la admin API: PUT /admin/realms/{realm} con
{"resetPasswordAllowed": false}.
Questo blocca l'endpoint login-actions/reset-credentials ma impedisce anche
agli utenti legittimi di resettare la propria password, quindi trattatelo come
una misura temporanea finché non aggiornate. Nota: Red Hat non elenca una
mitigazione ufficiale per questa CVE; la patch è l'unica vera soluzione.
cve-2026-18963-keycloak-hunt.sql esegue quattro query di sola lettura:
| Query | Cosa trova |
|---|---|
| Q0 | Se il realm memorizza eventi di login/admin e la loro TTL. Se gli eventi sono disattivati o scaduti, i risultati vuoti in Q2/Q3 non provano nulla. |
| Q1 | Ogni credenziale password impostata all'interno della finestra di esposizione (credential.created_date). Questo è il takeover stesso e funziona anche se la registrazione degli eventi era disattivata. |
| Q2 | Eventi di login reset/credential, evidenziando qualsiasi reset completato senza SEND_RESET_PASSWORD nelle 24 ore precedenti (no_email_before = t). Quel flag è la firma della CVE: l'attaccante non ha mai attivato la mail. |
| Q3 | Reset di credenziali tramite admin API e operazioni execute-actions, per escludere la via amministrativa. |
# default: realm 'master', finestra dal 2026-06-01
psql -U keycloak -d keycloak -f cve-2026-18963-keycloak-hunt.sql
# realm e finestra espliciti (eseguire una volta per realm, citare i valori esattamente così)
psql -U keycloak -d keycloak \
-v realm="'myrealm'" -v since="'2026-05-01'" \
-f cve-2026-18963-keycloak-hunt.sql
Impostate since a poco prima che la vostra versione vulnerabile andasse in
produzione. Su Kubernetes:
kubectl exec -it my-postgres-pod -- \
psql -U keycloak -d keycloak -v realm="'myrealm'" -v since="'2026-05-01'" \
-f - < cve-2026-18963-keycloak-hunt.sql
Le righe in Q1 non sono automaticamente compromissioni. Confrontate ciascuna con una causa legittima nota (reset self-service, azione dell'helpdesk, nuova registrazione) e trattate qualsiasi cosa non spiegata come candidata al takeover.
Le righe di Q2 con no_email_before = t su RESET_PASSWORD, UPDATE_CREDENTIAL
o UPDATE_PASSWORD sono l'indicatore più forte dello sfruttamento di questa
CVE. Correlate la colonna ip_address con i vostri log di accesso.
Controllate prima Q0: gli eventi di login scadono (events_expiration) e
possono essere disattivati del tutto. Q1 non scade, quindi è il controllo più
affidabile.
MIT, vedi LICENSE. Fornito così com'è, senza garanzie.