Una falla critica scoperta cinque mesi fa in WSO2 API Manager è finita sotto attacco attivo a metà settembre 2026. La società di threat intelligence watchTowr ha intercettato nei propri honeypot dei token JWT contraffatti con privilegi di amministratore, prova che qualcuno sta sfruttando la vulnerabilità CVE-2026-5430 per prendere il controllo di infrastrutture API usate da banche, enti pubblici e operatori delle telecomunicazioni. Il punteggio di gravità è tra i più alti possibili: CVSS 10.0 su ambienti multi-tenant, 9.8 su quelli single-tenant. Per l’Europa, dove WSO2 è da anni un pilastro delle piattaforme di open banking legate alla PSD2, la vicenda pone una domanda scomoda: perché ci sono voluti mesi prima che l’exploit arrivasse in circolazione, e quante organizzazioni non hanno ancora installato la patch?
Cosa è successo: attacco in corso contro WSO2 API Manager
Il 13 settembre 2026 i sensori di watchTowr hanno registrato richieste anomale dirette verso installazioni WSO2 esposte online. Le richieste trasportavano token JWT già pronti, con dentro codificati permessi da amministratore. Non erano tentativi casuali: erano token costruiti a tavolino per sfruttare un difetto preciso nella libreria di validazione firma di WSO2, quello descritto nell’advisory WSO2-2026-5328 e catalogato come CVE-2026-5430. Secondo quanto riportato da The Hacker News, si tratta della prima ondata di exploitation documentata pubblicamente per questa falla, comparsa esattamente 133 giorni dopo la pubblicazione della patch ufficiale.
Il ritardo tra correzione e sfruttamento non è un dettaglio secondario. Racconta una dinamica comune nel mondo enterprise: molte aziende trattano gli aggiornamenti dei gateway API come manutenzione a bassa priorità, spesso perché toccare l’infrastruttura che smista il traffico verso decine di applicazioni interne comporta rischi operativi percepiti come maggiori del rischio di sicurezza stesso. Cinque mesi dopo, quella scelta si è trasformata in una finestra di attacco aperta e sfruttata.
La falla CVE-2026-5430 spiegata: bypass di autenticazione via JWT
Il problema riguarda il modo in cui WSO2 API Manager, API Control Plane, Traffic Manager e Universal Gateway verificano la firma dei token JWT (JSON Web Token) usati per autenticare le richieste. Nella configurazione difettosa, il sistema accetta token firmati con un algoritmo diverso da quello previsto, senza bloccarli. Un attaccante può quindi generare un JWT con qualsiasi payload desideri, firmarlo con un algoritmo non supportato dal validatore e ottenere accesso come se fosse un utente legittimo, incluso un amministratore.
Nella pratica il rischio si traduce in tre capacità concrete per chi sfrutta la falla: leggere e modificare le configurazioni degli endpoint API, recuperare le chiavi consumer e i secret di ogni applicazione registrata sulla piattaforma, e ottenere il controllo amministrativo completo dell’istanza. Non serve autenticazione preventiva né interazione dell’utente: il vettore d’attacco è di rete, a bassa complessità, esattamente il tipo di combinazione che spinge il punteggio CVSS al massimo.
// Esempio semplificato del difetto: il validatore accetta
// qualsiasi "alg" dichiarato nell'header, invece di forzare
// l'algoritmo configurato lato server.
// Comportamento vulnerabile
function verifyToken(token) {
const header = decodeHeader(token);
return verifySignature(token, header.alg); // alg preso dal token stesso
}
// Comportamento corretto (allowlist fissa)
const ALLOWED_ALG = "RS256";
function verifyTokenSicuro(token) {
const header = decodeHeader(token);
if (header.alg !== ALLOWED_ALG) {
throw new Error("Algoritmo non consentito");
}
return verifySignature(token, ALLOWED_ALG);
}Questo schema, noto come “algorithm confusion”, non è una novità assoluta nel mondo dei JWT. Lo si legge più avanti in questo articolo nella sezione dedicata alla storia della vulnerabilità. Quello che cambia nel caso WSO2 è la scala dell’esposizione: si parla di un middleware usato da quasi mille organizzazioni enterprise a livello globale, secondo la stima riportata da SecurityWeek, con una concentrazione significativa in banche, amministrazioni pubbliche e telco.
Chi ha scoperto l’exploit: il ruolo di watchTowr
watchTowr è la società di exposure management che ha segnalato per prima l’attività sospetta, grazie a una rete di honeypot pensata per intercettare tentativi di exploitation reale su vulnerabilità note. Yordan Ganchev, Principal Threat Intelligence Specialist dell’azienda, ha spiegato a SecurityWeek che il token forgiato garantisce accesso a ogni endpoint delle API backend e alle relative credenziali, comprese le consumer key e i secret di ogni applicazione registrata sulla piattaforma. Ganchev ha aggiunto che l’unico vero mistero, a questo punto, è perché nessun altro se ne fosse accorto prima.
Il riferimento dell’analista di watchTowr aiuta a inquadrare il livello di rischio reale, oltre il numero sulla scala CVSS. Un token amministrativo forgiato non è un incidente isolato su un singolo endpoint: è una chiave universale che apre l’intera superficie API gestita da quella istanza WSO2, incluse le integrazioni verso sistemi bancari o governativi collegati a monte.
Cronologia dei fatti: dalla patch di aprile all’exploit di settembre
WSO2 aveva corretto il difetto internamente già ad aprile 2026, pubblicando poi l’advisory formale WSO2-2026-5328 il 3 maggio 2026. Per quattro mesi la vulnerabilità è rimasta nota solo a chi seguiva con attenzione i bollettini di sicurezza del vendor. Il 13 settembre 2026 watchTowr ha osservato le prime richieste con token forgiati nei propri sensori, e il 16 settembre 2026 ha reso pubblico l’allarme, ripreso da testate come The Hacker News e SecurityWeek. A oggi, 22 settembre 2026, la falla non risulta ancora inserita nel catalogo Known Exploited Vulnerabilities di CISA, nonostante l’exploitation attiva documentata da fonti indipendenti: un disallineamento che lascia molte organizzazioni fuori dagli obblighi di rimedio accelerato previsti per le voci del catalogo.
Quali prodotti e versioni sono a rischio
L’advisory ufficiale elenca quattro prodotti della suite WSO2 coinvolti, con range di versioni piuttosto ampio: praticamente tutte le release ancora supportate di API Manager risultano vulnerabili. La tabella seguente riassume prodotti, versioni interessate e livello minimo di aggiornamento che chiude la falla, secondo i dati pubblicati da WSO2 e ripresi da CybersecurityNews.
| Prodotto WSO2 | Versioni interessate | Update minimo per la patch |
|---|---|---|
| API Manager | 4.1.0 – 4.6.0 | 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.5.0 – 4.6.0 | 4.6.0 U22 · 4.5.0 U58 |
| Traffic Manager | 4.5.0 – 4.6.0 | 4.6.0 U21 · 4.5.0 U56 |
| Universal Gateway | 4.5.0 – 4.6.0 | 4.6.0 U21 · 4.5.0 U57 |
Chi gestisce una di queste installazioni dovrebbe verificare la versione esatta in produzione e confrontarla con questa tabella prima di considerare l’ambiente al sicuro. Le versioni precedenti alla 4.1.0, ormai fuori supporto, non risultano coperte da patch ufficiali: per quegli ambienti l’unica strategia realistica è isolare l’accesso di rete o pianificare una migrazione.
Perché WSO2 è un obiettivo critico in Europa
WSO2 non è un nome familiare al pubblico generalista, ma nell’infrastruttura bancaria europea è tutt’altro che marginale. Secondo il materiale pubblicato dallo stesso vendor, le sue piattaforme di integrazione, identità e gestione API sono alla base di oltre 200 istituti finanziari attivi in più di 60 paesi, con un pacchetto dedicato all’open banking pensato proprio per la conformità PSD2. Una violazione che colpisca un nodo di questo tipo non resta confinata a un singolo servizio: può propagarsi verso ogni applicazione bancaria terza collegata tramite quelle API.
La dimensione pubblica del problema è altrettanto rilevante. Diverse amministrazioni statali europee usano WSO2 per esporre servizi digitali ai cittadini attraverso gateway centralizzati, spesso condivisi tra più enti. In quel modello, una singola istanza compromessa diventa un punto di ingresso verso decine di sistemi collegati, dai portali fiscali ai registri sanitari, con un effetto domino difficile da contenere una volta che un attaccante ottiene privilegi amministrativi sul gateway.
Il problema non nuovo: storia degli attacchi di algorithm confusion nei JWT
La classe di vulnerabilità dietro CVE-2026-5430 ha oltre un decennio di storia documentata. Nel marzo 2015 il ricercatore Tim McLean pubblicò la prima analisi sistematica di questo difetto nelle librerie JWT, mostrando come alcune implementazioni accettassero token firmati con l’algoritmo “none”, bypassando completamente la verifica della firma. Quella scoperta portò alla registrazione di CVE-2015-9235 sulla libreria auth0/jsonwebtoken, con un punteggio CVSS di 5.5, e a patch rapide in node-jsonwebtoken, PyJWT, jjwt e php-jwt, secondo la ricostruzione pubblicata su chosenplaintext.ca.
Undici anni dopo, lo stesso schema logico riemerge in un prodotto enterprise diverso, con conseguenze più gravi perché applicato a un gateway che smista traffico bancario e governativo invece che a una singola libreria applicativa. La lezione che l’industria non ha ancora imparato del tutto è semplice: l’algoritmo di firma di un JWT non dovrebbe mai essere una scelta lasciata al token stesso. Deve essere fissato lato server, con una allowlist che ignora qualunque valore diverso dichiarato nell’header.
Confronto con altre falle critiche del 2026
Il 2026 è stato un anno particolarmente intenso per le vulnerabilità con punteggio CVSS al massimo o quasi. Confrontare CVE-2026-5430 con altri casi recenti aiuta a capire se il gap di 133 giorni tra patch e exploitation di WSO2 sia un’eccezione o la norma nel settore enterprise.
| Vulnerabilità | Prodotto | CVSS | Tipo di difetto |
|---|---|---|---|
| CVE-2026-5430 | WSO2 API Manager | 10.0 / 9.8 | Bypass autenticazione JWT |
| CVE-2026-44756 | SAP NetWeaver / S/4HANA (OVERPASS) | 10.0 | RCE pre-autenticazione |
| CVE-2026-85706 | GitLab | 10.0 | Path traversal |
| CVE-2026-76461 | Cisco Secure Email Gateway | 9.8 | SQL injection |
| CVE-2026-86218 | N-central (N-able) | 10.0 | Terzo zero-day in 6 settimane |
Il denominatore comune non è il tipo di bug, ma la fascia di prodotti colpiti: gateway, piattaforme di gestione remota e strumenti di integrazione che siedono al centro dell’infrastruttura, con accesso privilegiato a molti altri sistemi. È proprio questa posizione centrale che rende ogni singola falla in questa categoria più pericolosa di una vulnerabilità equivalente in un’applicazione periferica.
L’impatto sul mercato della sicurezza delle API
Il caso WSO2 arriva in un momento in cui la sicurezza delle API sta già crescendo come priorità di spesa per i team di sicurezza enterprise. Le stime di mercato più prudenti collocano il settore della API security a circa 1,8 miliardi di dollari nel 2026, in crescita da 1,35 miliardi nel 2025, con un tasso composto annuo attorno al 33%. I dati sugli attacchi confermano perché: secondo il report 2026 di Salt Security, il numero di attaccanti unici che colpiscono le API è cresciuto del 400% in soli sei mesi. Akamai, nel proprio report, ha misurato un aumento del 32% negli attacchi che sfruttano le categorie della OWASP API Security Top 10, con una media giornaliera di attacchi per organizzazione salita da 121 a 258, un incremento del 113% su base annua.
Guardando alle cause profonde, l’autenticazione debole o mal configurata resta il problema numero uno: secondo OWASP, i controlli di autorizzazione a livello di oggetto (BOLA) sono coinvolti in circa il 40% degli attacchi contro API, mentre un’analisi indipendente su 60 violazioni reali avvenute nel 2025 attribuisce il 52% degli incidenti a difetti di autenticazione. CVE-2026-5430 rientra esattamente in questa seconda categoria: non è un bug di logica applicativa, è un cedimento del meccanismo che dovrebbe stabilire chi sei prima di lasciarti entrare.
| Indicatore | Valore 2026 | Fonte |
|---|---|---|
| Crescita attaccanti unici API (6 mesi) | +400% | Salt Security |
| Aumento attacchi su categorie OWASP API Top 10 | +32% | Akamai |
| Media attacchi giornalieri per organizzazione | 121 → 258 (+113%) | Akamai |
| Quota attacchi API legata a BOLA | ~40% | OWASP |
| Incidenti causati da autenticazione debole | 52% su 60 breach analizzati | Analisi indipendente 2025 |
| Mercato globale API security | 1,35 Mld$ (2025) → 1,8 Mld$ (2026) | Stima di settore, CAGR ~33% |
Perché tante aziende non hanno ancora applicato la patch
Il gap di 133 giorni tra la pubblicazione dell’advisory e la prima exploitation osservata non nasce da mancanza di informazione. WSO2 aveva già pubblicato update numerati con precisione per ogni versione supportata a inizio maggio. Il problema è quasi sempre operativo: aggiornare un gateway API in produzione significa toccare il punto di passaggio di tutto il traffico verso i sistemi collegati, con finestre di manutenzione che vanno pianificate, testate e spesso approvate da più team.
In molte organizzazioni bancarie e pubbliche, inoltre, il gateway API non è gestito da un unico team di sicurezza ma condiviso tra più divisioni, ciascuna con priorità diverse. Quando un aggiornamento richiede coordinamento tra sicurezza, operations e i team applicativi che consumano quelle API, il rischio percepito di un’interruzione di servizio finisce spesso per pesare più del rischio, meno visibile fino a quando non si materializza, di una violazione.
Cosa devono fare ora i team IT: mitigazioni immediate
Per chi gestisce un’istanza WSO2 ancora non aggiornata, le priorità operative sono chiare e vanno affrontate in parallelo, non in sequenza.
- Applicare immediatamente gli update elencati nella tabella dei prodotti interessati, partendo dagli ambienti esposti direttamente su internet.
- Verificare i log di autenticazione alla ricerca di token JWT con claim amministrativi generati da IP o pattern di richiesta inusuali, in particolare a partire dal 13 settembre 2026.
- Ruotare le credenziali, i consumer key e i secret di tutte le applicazioni registrate sull’istanza, dato che un token forgiato può averle già esposte.
- Mappare quali sistemi a valle (bancari, governativi, di terze parti) si fidano ciecamente dei token emessi dal gateway compromesso, per valutare l’impatto reale di un eventuale accesso non autorizzato.
- Limitare temporaneamente l’esposizione internet dell’interfaccia amministrativa, se la patch non può essere applicata entro poche ore.
Nessuna di queste azioni richiede strumenti particolarmente sofisticati. Richiede però che qualcuno, all’interno dell’organizzazione, tratti l’aggiornamento del gateway API con la stessa urgenza riservata a un incidente in corso, non a un ticket di manutenzione ordinaria.
La lezione per gli sviluppatori: come blindare i JWT
Fissare l’algoritmo, non fidarsi dell’header
Il principio che avrebbe evitato CVE-2026-5430 esiste da oltre dieci anni ed è alla base di ogni libreria JWT moderna se configurata correttamente: l’algoritmo di verifica deve essere deciso dal server, mai letto dal campo alg dentro il token che si sta verificando. Le librerie più recenti permettono di specificare esplicitamente un algoritmo o una lista ristretta consentita in fase di verifica, ignorando qualsiasi valore diverso presente nel token.
Testare anche i percorsi che sembrano già sicuri
Molti team assumono che, una volta scelto un algoritmo asimmetrico come RS256, il rischio di algorithm confusion sia chiuso. Non è così: se il validatore non forza esplicitamente quell’algoritmo e si limita a fidarsi del token, un attaccante può comunque tentare di far accettare una firma calcolata con un algoritmo simmetrico usando la chiave pubblica come segreto condiviso. È un test che dovrebbe rientrare in ogni revisione di sicurezza di un sistema di autenticazione basato su JWT, incluse le librerie di terze parti integrate in piattaforme enterprise come quella di WSO2.
Previsioni: cosa aspettarsi nei prossimi mesi
- È probabile che CISA aggiunga CVE-2026-5430 al catalogo Known Exploited Vulnerabilities nelle prossime settimane, dato che l’exploitation attiva è già documentata da più fonti indipendenti.
- Altre organizzazioni che non hanno ancora applicato la patch di maggio verranno identificate come compromesse nelle prossime settimane, con la possibilità di violazioni divulgate pubblicamente entro fine 2026.
- Ci si aspetta un aumento delle scansioni automatizzate contro istanze WSO2 esposte, man mano che l’exploit diventa di dominio pubblico e viene integrato in strumenti di attacco più ampi.
- I fornitori di gateway API concorrenti probabilmente useranno il caso WSO2 come argomento commerciale, rilanciando controlli di validazione algoritmica come differenziatore nelle proposte alle banche europee.
- È plausibile che enti regolatori europei, in particolare nell’ambito della vigilanza PSD2 e delle verifiche NIS2, chiedano alle banche che usano WSO2 di documentare formalmente lo stato di patching di questa specifica CVE.
Domande frequenti
Cos’è esattamente CVE-2026-5430?
È una vulnerabilità critica in WSO2 API Manager, API Control Plane, Traffic Manager e Universal Gateway che permette di bypassare l’autenticazione JWT forgiando token firmati con un algoritmo non previsto dal validatore. Il punteggio CVSS assegnato da WSO2 è 10.0 in ambienti multi-tenant e 9.8 in ambienti single-tenant.
La mia azienda è a rischio se usa WSO2?
Dipende dalla versione installata. Sono interessate le versioni di API Manager comprese tra 4.1.0 e 4.6.0, oltre alle versioni 4.5.0 e 4.6.0 di API Control Plane, Traffic Manager e Universal Gateway. Occorre verificare la versione esatta e applicare l’update minimo indicato nell’advisory WSO2-2026-5328.
La patch è disponibile?
Sì, WSO2 ha pubblicato la correzione già ad aprile 2026 e l’advisory formale il 3 maggio 2026, con update numerati per ogni versione supportata. Il problema non è la disponibilità della patch, ma il ritardo con cui molte organizzazioni l’hanno applicata: l’exploitation attiva è stata osservata solo a settembre.
Chi ha scoperto l’exploitation attiva?
La società di exposure management watchTowr, tramite la propria rete di honeypot, ha intercettato il 13 settembre 2026 richieste con token JWT contraffatti contenenti privilegi amministrativi, rendendo pubblico l’allarme tre giorni dopo.
CVE-2026-5430 è nel catalogo CISA KEV?
No, al 22 settembre 2026 la vulnerabilità non risulta ancora inserita nel catalogo Known Exploited Vulnerabilities di CISA, nonostante l’exploitation attiva documentata da fonti indipendenti come watchTowr, SecurityWeek e The Hacker News.
Perché questa falla è rilevante per le banche europee?
WSO2 alimenta le piattaforme di integrazione e identità di oltre 200 istituti finanziari in più di 60 paesi, con un pacchetto dedicato all’open banking per la conformità PSD2. Un’istanza compromessa può diventare un punto di ingresso verso le applicazioni bancarie terze collegate tramite quelle API.
È la prima volta che un bug di questo tipo colpisce i JWT?
No. Il primo caso ampiamente documentato di algorithm confusion nei JWT risale al marzo 2015, quando il ricercatore Tim McLean pubblicò l’analisi che portò alla registrazione di CVE-2015-9235 su una libreria JWT molto diffusa. CVE-2026-5430 applica lo stesso schema logico a un prodotto enterprise di scala molto maggiore.
Cosa deve fare subito un’azienda che non ha ancora applicato la patch?
Aggiornare immediatamente alla versione corretta indicata nell’advisory, controllare i log di autenticazione per token amministrativi anomali generati dopo il 13 settembre 2026, e ruotare le credenziali e i secret di tutte le applicazioni registrate sull’istanza, dato che potrebbero essere già stati esposti.
