CVE-2026-17059: falla BOLA su Keycloak

Una nuova vulnerabilità di controllo accessi mette in allerta chi gestisce infrastrutture Keycloak in ambienti multi-team. Si chiama CVE-2026-17059 ed è una falla di tipo Broken Object-Level Authorization (BOLA) che, per mesi, ha permesso ad account amministrativi con permessi limitati di accedere a dati personali di altri utenti. In questo articolo vediamo come funziona la vulnerabilità, perché rappresenta un rischio concreto per le organizzazioni con deleghe amministrative complesse e quali azioni intraprendere subito per proteggere i propri sistemi.

Cos’è CVE-2026-17059 e come funziona

CVE-2026-17059 è una vulnerabilità classificata come CWE-639 (Broken Object-Level Authorization, BOLA) che colpisce Keycloak, la piattaforma open source per la gestione dell’identità e degli accessi ampiamente usata in ambito enterprise.

Il problema riguarda un endpoint specifico dell’API amministrativa:

• GET /admin/realms/{realm}/roles/{role-name}/users

Questo endpoint, pensato per elencare gli utenti associati a un determinato ruolo, restituiva informazioni personali complete come username, email, nome e cognome, senza applicare gli stessi controlli di autorizzazione previsti dall’endpoint principale /admin/realms/{realm}/users.

La root cause tecnica

Il codice che gestiva questa richiesta convertiva gli ID dei membri del ruolo in rappresentazioni utente complete (UserRepresentation) senza verificare, caso per caso, se il chiamante avesse effettivamente il diritto di visualizzare quel singolo utente. In pratica, venivano controllati solo permessi generici come query-users e view-realm, ma non il filtro granulare “per singolo utente” che invece protegge l’endpoint principale.

Perché è un rischio reale negli ambienti multi-team

Molte aziende strutturano l’accesso amministrativo a Keycloak su base delegata: team di supporto, helpdesk o servizi esterni ricevono ruoli con permessi limitati per svolgere operazioni specifiche, senza però ottenere la visibilità completa sugli utenti del realm.

Questo modello di delega, teoricamente sicuro, veniva aggirato proprio grazie alla vulnerabilità. Un operatore con permessi ridotti poteva:

• Interrogare l’endpoint alternativo dei ruoli invece di quello principale degli utenti
• Ottenere elenchi completi di utenti con relativi dati personali (PII)
• Ricostruire di fatto una directory aziendale non autorizzata
• Effettuare profiling su dipendenti o clienti senza lasciare tracce evidenti

L’impatto pratico è significativo: si tratta di esposizione di dati personali a personale che, per policy interna, non avrebbe dovuto averne accesso. Un problema non solo di sicurezza tecnica, ma anche di conformità normativa, pensando ad esempio agli obblighi previsti dal GDPR.

Il ruolo del modello di permessi v2 (adminPermissionsEnabled)

Un dettaglio interessante riguarda il modello di permessi amministrativi più recente di Keycloak, noto come permissions v2 o adminPermissionsEnabled. Questo modello, più granulare rispetto a quello legacy, applica controlli di autorizzazione coerenti su ogni singola risorsa, riducendo drasticamente la probabilità che un endpoint “alternativo” possa aggirare le protezioni previste.

Detto questo, è importante essere chiari su un punto: non si tratta di una garanzia assoluta. Anche con il modello v2 attivo, è indispensabile:

• Verificare la configurazione realm per realm
• Testare la coerenza dei controlli su tutti gli endpoint che espongono gli stessi dati
• Non dare per scontato che l’attivazione di una funzionalità risolva automaticamente ogni lacuna

La lezione di sicurezza da portare a casa

Questo caso offre uno spunto di riflessione che va oltre Keycloak: proteggere solo l’endpoint “principale” non basta. Ogni sistema complesso, soprattutto le API REST amministrative, tende ad avere percorsi alternativi che restituiscono dati simili o identici, magari pensati per casi d’uso diversi.

Alcune buone pratiche generali da adottare in qualsiasi progetto:

1. Mappare tutti gli endpoint che possono restituire lo stesso tipo di dato sensibile, non solo quello “ufficiale”
2. Applicare controlli di autorizzazione coerenti su ogni endpoint, incluse le operazioni di listing e le conversioni server-side
3. Testare sistematicamente confrontando le risposte di endpoint diversi che dovrebbero comportarsi allo stesso modo
4. Adottare una difesa in profondità, senza fare affidamento su un unico livello di controllo

Timeline della vulnerabilità

La scoperta della falla è attribuita al ricercatore Enzo Mongin, in collaborazione con Escape Research. Ecco i punti chiave della vicenda:

• La segnalazione al team Keycloak risale a metà luglio 2026
• L’assegnazione del CVE e la pubblicazione dei primi riferimenti sono avvenute nella seconda metà di luglio 2026
• La correzione definitiva è stata rilasciata con Keycloak 26.7.0, a fine luglio 2026
• Il coordinamento con Red Hat ha portato all’inserimento della vulnerabilità nei principali database CVE (NVD, Red Hat Access)

Il punteggio CVSS 3.1 assegnato è di circa 6.5, gravità Medium: non critico in senso assoluto, ma comunque rilevante considerando la natura dei dati esposti.

Cosa fare subito: raccomandazioni pratiche

Se gestisci un’infrastruttura Keycloak, ecco le azioni da mettere in pratica senza rimandare.

1. Aggiorna Keycloak

La prima e più importante azione è l’aggiornamento a Keycloak 26.7.0 o versione successiva, che include la patch ufficiale per questa vulnerabilità.

2. Effettua un audit dei ruoli e permessi

• Identifica tutti gli account con permessi query-users e view-realm
• Rivedi quali utenti o servizi hanno accesso agli endpoint /admin/*
• Separa, dove possibile, le funzioni di ricerca ruoli da quelle che comportano visibilità su dati personali

3. Limita gli accessi non necessari

Applica il principio del minimo privilegio: riduci il numero di account con permessi di query estesi, specialmente per ruoli helpdesk o di supporto esterno.

4. Testa dopo l’aggiornamento

Verifica che, dopo la patch, l’endpoint GET /admin/realms/{realm}/roles/{role-name}/users restituisca solo le informazioni che l’account chiamante è autorizzato a vedere. Controlla anche i log di accesso per individuare eventuali chiamate sospette effettuate prima dell’aggiornamento.

5. Valuta l’attivazione del modello permissions v2

Se compatibile con la tua infrastruttura, valuta l’attivazione di adminPermissionsEnabled per un controllo più granulare sulle risorse, sempre accompagnato da test specifici.

Checklist operativa rapida

• Pianifica l’upgrade a Keycloak >= 26.7.0, testandolo prima in staging
• Crea un inventario degli account con permessi query-users e view-realm
• Analizza i log per individuare accessi sospetti all’endpoint vulnerabile
• Esegui test di validazione post-patch con token rappresentativi di ruoli limitati
• Valuta l’attivazione delle permissions v2, se compatibile con il tuo ambiente
• Informa i team di sicurezza e compliance della possibile esposizione di dati personali

Conclusione

CVE-2026-17059 è un esempio emblematico di come le vulnerabilità di controllo accessi possano nascondersi in endpoint “secondari”, spesso trascurati durante i test di sicurezza. In un ambiente Keycloak multi-team, dove la delega dei permessi amministrativi è la norma, questo tipo di falla può tradursi in un’esposizione concreta di dati personali a chi non dovrebbe averne accesso.

La lezione principale è chiara: la sicurezza di un sistema si misura sulla coerenza dei controlli applicati a tutti gli endpoint, non solo a quelli più visibili. Aggiornare tempestivamente a Keycloak 26.7.0, effettuare un audit dei permessi e testare la coerenza delle autorizzazioni sono passaggi fondamentali per chiudere questa falla e prevenire situazioni simili in futuro.