JWT Java a rischio: la falla in pac4j-jwt permette di diventare admin con un solo token

Una vulnerabilità critica individuata nella libreria Java pac4j-jwt ha riportato l’attenzione su un problema ricorrente nella sicurezza delle implementazioni di autenticazione basate su token.  La falla in questione, classificata con l’identificativo CVE-2026-29000 e un punteggio CVSS pari a 10,0 (valore massimo previsto dal Common Vulnerability Scoring System, il sistema standard utilizzato per valutare la gravità delle vulnerabilità di sicurezza informatica), consente a un attaccante di aggirare completamente i controlli di autenticazione e impersonare qualsiasi utente dell’applicazione, inclusi gli account amministrativi.

Il difetto interessa una delle librerie più diffuse nel mondo Java per la gestione dell’autenticazione federata e dei JSON Web Token (JWT), utilizzata in numerosi framework e applicazioni enterprise.

Cos’è e a che cosa serve pac4j

La famiglia di librerie pac4j nasce come un toolkit modulare per gestire autenticazione e autorizzazione nelle applicazioni Java: la prima riguarda la verifica dell’identità di un utente, mentre la seconda stabilisce a quali risorse o funzionalità quell’utente può accedere. Il framework include integrazioni pronte all’uso con diversi protocolli standard di identità e federazione, tra cui OAuth (utilizzato per delegare l’accesso a servizi esterni), SAML (impiegato soprattutto nei sistemi di autenticazione aziendali) e OpenID Connect, un livello di identità costruito sopra OAuth che consente di autenticare gli utenti tramite provider esterni.

Il modulo dedicato ai token, basato sulla libreria Nimbus JOSE JWT, gestisce la validazione di token firmati e cifrati utilizzando le specifiche standard definite dalla IETF. L’adozione dei JSON Web Token è cresciuta rapidamente negli ultimi dieci anni grazie alla loro capacità di trasportare informazioni di autenticazione in forma compatta e verificabile, spesso utilizzate per API REST, microservizi e piattaforme cloud.

Secondo varie analisi del settore, l’autenticazione tramite JWT è ormai presente in una larga quota delle applicazioni Web moderne, rendendo vulnerabilità di questo tipo particolarmente critiche.

Il problema emerso in pac4j (e confermato nel bollettino ufficiale) riguarda una combinazione specifica di funzionalità: l’uso simultaneo di token cifrati e di meccanismi di verifica della firma. In determinate configurazioni, il flusso di autenticazione permette di creare una sessione valida anche quando il token non è firmato, aprendo la strada a un bypass completo dell’identità digitale dichiarata nel token.

Come funziona l’attacco di bypass dell’autenticazione

Lo scenario di attacco sfrutta la combinazione tra token cifrati e chiavi pubbliche. In molti sistemi basati su JWT, la chiave pubblica RSA utilizzata per verificare la firma è facilmente reperibile.

Un attaccante può quindi costruire un token non firmato contenente claims arbitrari, ad esempio un identificativo utente privilegiato o ruoli amministrativi. Il token è poi inserito all’interno di un contenitore cifrato JWE utilizzando la chiave pubblica del server.

Quando il server riceve il token, lo decifra correttamente grazie alla propria chiave privata. Dopo la decifratura, il payload supera a piè pari la verifica della firma e il sistema crea direttamente un profilo autenticato utilizzando le informazioni presenti nel token.

Il risultato è un bypass completo dell’autenticazione: l’attaccante può impersonare qualsiasi identità definita nel token, inclusi account amministrativi o utenti con privilegi elevati.

Versioni vulnerabili e aggiornamenti di sicurezza

Le analisi di sicurezza indicano che il problema è rimasto nel codice per diversi anni prima di essere individuato. Le versioni vulnerabili includono tutte le release precedenti alle patch rilasciate nei principali rami di sviluppo della libreria.

Le correzioni sono state introdotte nelle versioni 4.5.9, 5.7.9 e 6.3.3 del modulo pac4j-jwt. Gli aggiornamenti introducono controlli aggiuntivi che impediscono l’accettazione di token non firmati quando la configurazione prevede la verifica della firma, eliminando così la possibilità di bypass.

La rapidità con cui i maintainer del progetto hanno distribuito le patch è stata evidenziata dalla comunità di sicurezza: gli aggiornamenti risultano pubblicati pochi giorni dopo la segnalazione privata del problema, insieme a un advisory ufficiale e al coordinamento per l’assegnazione del CVE.

Mitigazioni e verifiche per ambienti di produzione

Le applicazioni che utilizzano pac4j per l’autenticazione JWT dovrebbero verificare immediatamente la versione del modulo pac4j-jwt presente nelle dipendenze. L’aggiornamento alla versione corretta rappresenta la soluzione numero uno.

Nei sistemi che non potessero essere subito aggiornati, è possibile ridurre temporaneamente il rischio disabilitando l’accettazione di token cifrati oppure applicando controlli espliciti che rifiutino token privi di firma. Una revisione delle configurazioni di autenticazione è particolarmente importante quando l’applicazione accetta token provenienti da fonti esterne o federate.

La vulnerabilità evidenzia inoltre un punto critico nella progettazione dei sistemi di autenticazione: il rispetto formale delle specifiche non garantisce automaticamente la sicurezza dell’implementazione. Token validi secondo lo standard possono infatti introdurre comportamenti inattesi se le verifiche logiche non sono progettate con attenzione.

Il ruolo dell’intelligenza artificiale nella scoperta della vulnerabilità

Un elemento particolarmente interessante della falla CVE-2026-29000 riguarda il modo in cui la vulnerabilità è venuta a galla. La scoperta è infatti legata a un progetto di ricerca interno di CodeAnt AI, che utilizza sistemi di revisione automatizzata del codice per analizzare librerie open source e verificare se le patch di sicurezza eliminino davvero le vulnerabilità presenti.

Durante questa attività, il sistema di AI code review ha i percorsi di esecuzione del codice della libreria pac4j-jwt, individuando un’anomalia logica nel flusso di validazione dei token. Tale condizione, apparentemente innocua, creava invece uno scenario in cui la verifica della firma poteva essere completamente saltata.

Un ricercatore umano del team di sicurezza ha quindi analizzato l’avviso generato dal sistema automatizzato, confermando che si trattava di un bypass completo del meccanismo di autenticazione.

Se da un lato strumenti basati su AI stanno dimostrando di poter individuare bug complessi in grandi codebase, dall’altro stanno emergendo anche effetti collaterali inattesi. Un caso emblematico è quello del progetto curl, uno degli strumenti di rete più diffusi al mondo, i cui maintainer hanno deciso di interrompere il programma di bug bounty dopo la valanga di segnalazioni generate con modelli AI, prive di reale fondamento tecnico. Il responsabile Daniel Stenberg ha descritto il fenomeno come una sorta di “death by a thousand slops”, ovvero un sovraccarico di report plausibili ma spesso errati o imprecisi che richiedono comunque tempo per essere analizzati e scartati.

Il fatto è che quando l’analisi dell’AI è coadiuvata dal supporto umano, che analizza le segnalazioni in maniera approfondita, è possibile davvero individuare pattern sospetti che meritano ulteriori controlli. In contesti caratterizzati da codebase estese e librerie utilizzate su larga scala, questa combinazione tra automazione e revisione umana può accelerare significativamente l’identificazione di vulnerabilità critiche rimaste invisibili per anni. Come dimostra chiaramente il caso pac4j-jwt.