WSO2 CVE-2026-5430: il bypass JWT CVSS 10 che forgia token admin in the wild

Il 24 settembre 2026 CISA ha inserito CVE-2026-5430 nel proprio catalogo Known Exploited Vulnerabilities, dando alle agenzie federali statunitensi tre giorni per correggerla. La vulnerabilità è un bypass di autenticazione JWT in WSO2 API Manager e nei gateway che ci girano sopra, con punteggio CVSS 10.0. La parte scomoda è il calendario: WSO2 ha rilasciato la correzione il 3 maggio 2026. Il record del catalogo e l'exploit funzionante sono arrivati quasi cinque mesi dopo, il che significa che la finestra tra "corretta" e "sfruttata" è stata di quasi mezzo anno — e la maggior parte di chi possedeva un gateway vulnerabile ha passato quella finestra senza fare nulla, perché nulla gli diceva di farlo.

In breve

CVE	CVE-2026-5430
Prodotto / versioni colpite	WSO2 API Manager 4.1.0–4.6.0; API Control Plane 4.5.0–4.6.0; Traffic Manager 4.5.0–4.6.0; Universal Gateway 4.5.0–4.6.0
Corretta in	API Manager 4.6.0 U21 · 4.5.0 U57 · 4.4.0 U72 · 4.3.0 U108 · 4.2.0 U197 · 4.1.0 U257; API Control Plane 4.6.0 U22 · 4.5.0 U58; Traffic Manager 4.6.0 U21 · 4.5.0 U56; Universal Gateway 4.6.0 U21 · 4.5.0 U57 (advisory WSO2-2026-5328, 03-05-2026)
CVSS	10.0 Critical (CVSS 3.1, WSO2/CNA; AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H); 9.8 per le installazioni single-tenant (S:U)
Sfruttata attivamente	Sì — gli honeypot di watchTowr hanno catturato JWT admin falsificati dal 13-09-2026 (riportato da The Hacker News)
CISA KEV	Inserita il 24-09-2026; scadenza federale 27-09-2026 (BOD 26-04, triage forense richiesto)
PoC pubblico	Nessuno pubblico al 25-09-2026; i ricercatori l'hanno riprodotta senza dettagli tecnici pubblicati (The Hacker News)
Advisory ufficiale	WSO2-2026-5328

Cos'è davvero CVE-2026-5430

WSO2 API Manager si mette davanti alle API aziendali come l'elemento che decide chi può chiamarle. Autentica i chiamanti con JSON Web Token firmati: il chiamante presenta un JWT, il gateway verifica la firma rispetto all'algoritmo e alla chiave configurati, e solo allora la richiesta raggiunge il backend. L'intero modello di sicurezza poggia su quel singolo controllo, che deve essere rigoroso.

Non lo è. Secondo l'advisory WSO2, il validatore del token non impone l'algoritmo di firma configurato. Quando riceve un JWT firmato con un algoritmo che non supporta, invece di rifiutarlo lo accetta. All'attaccante non serve la chiave di firma. Costruisce un token il cui header dichiara un algoritmo che il validatore non verifica correttamente, imposta i claim che vuole — sub: admin, l'intero scope di API management — e lo invia. Il gateway tratta il token falsificato come una sessione amministrativa valida.

È CWE-347, verifica impropria di una firma crittografica: la stessa famiglia di errori del bug alg=none che tormenta le librerie JWT da un decennio. La firma è il controllo di sicurezza, e il ramo di codice che dovrebbe rifiutarne una non valida la lascia passare.

Ciò che il bypass consegna non è un appiglio. Quando watchTowr ha rigiocato il payload contro il prodotto corretto, l'autenticazione si è aperta verso le destinazioni backend delle API, le credenziali memorizzate e le consumer key e secret di ogni applicazione registrata. Su un deployment multi-tenant lo scope attraversa i tenant, ed è per questo che il vettore CVSS riporta S:C (scope changed) e arriva a un netto 10.0; un'installazione single-tenant è valutata 9.8. In entrambi i casi, un attaccante non autenticato diventa l'amministratore della macchina che autentica tutti gli altri.

Il catalogo dice "path traversal". CVE-2026-5430 è un bypass JWT

Ecco la trappola che costerà ai team la prima caccia. Il record KEV di CISA la chiama "WSO2 Multiple Products Path Traversal Vulnerability" e la descrive come un path traversal che consente "unrestricted file upload and lead to remote code execution". L'advisory del vendor, il record NVD, la classificazione CWE e i token effettivamente catturati in rete dicono tutti un'altra cosa: un bypass di autenticazione JWT. In questo bug non c'è alcun caricamento di file.

La distinzione non è pedanteria — cambia dove si cerca.

"Abbiamo catturato token JWT falsificati che prendevano di mira la falla il 13 settembre e abbiamo riprodotto la vulnerabilità noi stessi, nonostante l'assenza di dettagli tecnici pubblici."

Chi risponde fidandosi della descrizione del catalogo cercherà nel filesystem JSP scritte di fresco, farà il diff della directory delle webapp e darà la caccia a una web shell depositata. Non troverà nulla, concluderà di non essere stato colpito e passerà oltre. La prova reale vive altrove: nei log di autenticazione, nei record di accesso all'API di amministrazione e nei JWT il cui header alg non corrisponde a quello che il gateway è configurato ad accettare. Se il vostro contenuto di detection è stato scritto a partire dalla frase del KEV, sta cercando l'artefatto sbagliato.

Una patch di maggio, armata a settembre

The Hacker News ha riportato che la rete di honeypot di watchTowr ha catturato i primi JWT admin falsificati il 13 settembre 2026 — quattro mesi dopo che WSO2 aveva pubblicato gli update level per ogni branch supportata. I token arrivavano già pronti con i claim amministrativi, il che significa che l'attaccante conosceva il bug abbastanza bene da armarlo prima di qualsiasi analisi tecnica pubblica. CISA l'ha inserita undici giorni dopo.

È la forma della maggior parte delle compromissioni reali del 2026: non uno zero-day, ma una vulnerabilità nota e corretta che nessuno ha applicato perché nessun orologio ticchettava finché non era troppo tardi. La classe dei bypass di validazione della firma JWT vi è particolarmente esposta. Nel nostro AI Gym Knowledge RAG — un'osservazione interna di Zero Hunt, non una statistica di settore — lo stesso difetto ricorre in un ecosistema dopo l'altro: accettazione di alg=none, confusione di algoritmo tra HMAC e RSA, e validatori che si aprono su un algoritmo non riconosciuto compaiono nelle librerie JWT e negli identity proxy anno dopo anno. WSO2 è l'ultimo nome di una lista che continua a crescere perché la correzione è una modifica di rigore di una riga e la conseguenza è totale.

La lezione non è "applicate le patch più in fretta". È che la stringa di versione su una dashboard vi dice un numero di build, non se il gateway in produzione sia raggiungibile, sfruttabile o già compromesso. Sono domande diverse, e solo a una risponde apt list --installed.

Remediation

1. Sono esposto?

Verificate prodotto e update level di ogni gateway WSO2, comprese le istanze di staging e quelle interne dimenticate. I prodotti colpiti sono API Manager 4.1.0–4.6.0, API Control Plane 4.5.0–4.6.0, Traffic Manager 4.5.0–4.6.0 e Universal Gateway 4.5.0–4.6.0. Dalla home del prodotto, confermate l'update level in esecuzione:

# WSO2 registra l'update level applicato nella config degli aggiornamenti
cat $CARBON_HOME/updates/product.txt 2>/dev/null
cat $CARBON_HOME/wso2/lib/product.txt 2>/dev/null
# e il client WUM/wso2update riporta la versione
$CARBON_HOME/bin/wso2update_linux --version

Qualsiasi porta di management o di gateway esposta a Internet (di default 9443 per la console di amministrazione e Publisher/DevPortal, 8243/8280 per le porte di traffico API) su una build non corretta va considerata esposta a un attaccante non autenticato.

2. Patch — update level corretti esatti

Applicate l'update level della vostra branch alla lettera, come da WSO2-2026-5328:

Prodotto	Branch → update level corretto
API Manager	4.6.0 → U21 · 4.5.0 → U57 · 4.4.0 → U72 · 4.3.0 → U108 · 4.2.0 → U197 · 4.1.0 → U257
API Control Plane	4.6.0 → U22 · 4.5.0 → U58
Traffic Manager	4.6.0 → U21 · 4.5.0 → U56
Universal Gateway	4.6.0 → U21 · 4.5.0 → U57

3. Non potete applicare la patch subito? — controlli compensativi

• Togliete la console di management da Internet. La porta 9443 e Publisher/DevPortal non hanno motivo di essere pubblici. Vincolateli a una rete di gestione o a una allow-list.
• Validate l'algoritmo del JWT al perimetro. Mettete davanti al gateway un reverse proxy o un WAF che rifiuti i token il cui header alg sia diverso dall'esatto algoritmo che emettete (tipicamente RS256), e che rifiuti in blocco alg=none e i valori non riconosciuti. Questo blocca la forma del token falsificato senza attendere l'update WSO2.
• Applicate rate-limit e alert sull'API di management, così una raffica di chiamate con scope admin da una nuova sorgente non passa in silenzio.

4. Cacciate la compromissione — segnali e mappatura ATT&CK

Poiché l'attacco è abuso di autenticazione, non deposito di file, cacciate sulla superficie di auth:

• JWT anomali — qualsiasi token accettato il cui header alg non sia il vostro algoritmo configurato, o che porti alg=none. È il segnale a più alta fedeltà. (ATT&CK T1550.001 – Application Access Token.)
• Sessioni admin senza login — chiamate all'API di amministrazione o azioni in console senza un evento di autenticazione precedente per quel principale. (T1078 – Valid Accounts.)
• Accesso iniziale sul gateway — richieste agli endpoint di management/token da ASN mai visti, immediatamente seguite da azioni privilegiate. (T1190 – Exploit Public-Facing Application.)
• Furto post-accesso — letture massive delle consumer key/secret delle applicazioni e delle credenziali backend, e connessioni in uscita dal gateway verso destinazioni che normalmente non raggiunge mai.

5. Bonificate e verificate

La patch chiude la porta; non annulla ciò che è già passato. Se trovate prove di accesso — o non potete escluderlo, cosa che il flag obbligatorio di triage forense su questo record KEV impone di saper fare — considerate bruciati i segreti che il gateway custodiva:

• Ruotate tutto ciò che il gateway conteneva: consumer key e secret delle applicazioni, credenziali dei servizi backend e le stesse chiavi di firma dei token. Una chiave di firma rubata significa che l'attaccante può coniare token validi anche dopo la patch.
• Invalidate sessioni attive e token emessi, così le sessioni falsificate e rigiocate muoiono.
• Preservate i log di autenticazione e uno snapshot del sistema prima di ricostruire — il flag forensicTriage: Yes sotto BOD 26-04 esiste proprio perché un'appliance compromessa può riscrivere i propri record.
• Ri-verificate dopo la patch con la stessa forma di payload a token falsificato contro la build specifica che ora eseguite — un numero di versione corretto non è la prova che la correzione sia atterrata nella vostra configurazione.

Dove si colloca Zero Hunt

Ogni passo di quella lista di bonifica è una decisione — cosa ruotare, in che ordine, se la correzione abbia davvero tenuto — ed è esattamente il lavoro che l'AI Remediation Advisor di Zero Hunt è costruito per portare. L'advisor classifica il finding per sfruttabilità reale, non per CVSS grezzo: una voce in KEV con traffico di token falsificati osservato batte un silenzioso 9.8, così un gateway WSO2 sul vostro perimetro sale in cima alla coda. Poi produce il piano specifico — l'update level esatto per la vostra branch, la allow-list di algoritmo da mettere al perimetro mentre pianificate il cambiamento, e la rotazione completa di consumer key, credenziali backend e chiavi di firma che una compromissione via bypass JWT impone — con note di rollback, e ri-verifica la correzione con la stessa prova che avrebbe dimostrato il problema.

Quella prova è l'altra metà. Come red team AI autonomo che gira on-premise sui propri modelli, con un umano nel loop per ogni azione che conta, Zero Hunt non legge una stringa di versione e dichiara il gateway sicuro. Il suo swarm di 10 agenti scrive un exploit per-target con un modello locale — senza bisogno di un PoC pubblico, cosa che conta per un bug armato prima di qualsiasi analisi — e risponde alla domanda che la dashboard non può: questo gateway è raggiungibile dalla posizione di un attaccante, il bypass a token falsificato atterra sulla vostra build e, dopo la patch, la correzione ha davvero tenuto? Ogni passo è ri-testato nell'AI Gym prima di toccare la produzione e firmato in scrittura in una catena di evidenze con hash concatenati. E poiché un gateway API compromesso possiede i propri log, il modello di analisi del traffico che osserva il filo — leggendo l'abuso anomalo di token con scope admin e il furto di credenziali in uscita mentre accadono — è l'unico testimone onesto rimasto quando la macchina stessa è stata istruita a mentire. La copertura si mappa in continuo sui framework che rendono questo un incidente da dichiarare, ovunque operiate.

CVE-2026-5430 era correggibile a maggio. Le organizzazioni che ne verranno colpite a ottobre non saranno quelle a cui mancava una patch. Saranno quelle che non hanno mai avuto un modo per sapere che la patch serviva, era stata applicata e stava tenendo.