Il 24 settembre 2026 la CISA statunitense ha inserito nel catalogo Known Exploited Vulnerabilities (KEV) la CVE-2026-5430, una falla critica nei prodotti di API management di WSO2. L'aggiunta arriva dopo che la società di exposure management watchTowr ha documentato tentativi di sfruttamento reali contro i propri honeypot a partire dal 13 settembre. La patch esiste da aprile e l'advisory del produttore è di inizio maggio: chi è ancora esposto oggi lo è da quasi cinque mesi.

Il punto che rende questa vulnerabilità diversa da molte altre è il ruolo del prodotto colpito. Un API gateway non è un server qualsiasi: è il punto di passaggio obbligato fra le applicazioni esposte e i sistemi interni, e custodisce le credenziali per parlare con entrambi.

I fatti verificati

  • Identificativo: CVE-2026-5430 (advisory WSO2-2026-5328, pubblicato il 3 maggio 2026).
  • Gravità: CVSS 3.1 pari a 10.0 secondo WSO2 nei deployment multi-tenant, ridotto a 9.8 nelle installazioni single-tenant. È il punteggio 9.8 quello riportato da CISA.
  • Natura del difetto: secondo il produttore, l'autenticazione basata su JWT può essere aggirata presentando un token firmato con un algoritmo non supportato. Il server accetta il token malformato come valido e concede l'accesso, fino alla compromissione di account amministrativi.
  • Descrizioni divergenti: nella scheda KEV la falla compare come path traversal con possibile caricamento arbitrario di file ed esecuzione di codice. Chi gestisce la vulnerabilità deve sapere che le due descrizioni convivono: nella pratica l'effetto osservato sul campo è l'aggiramento dell'autenticazione.
  • Prodotti e versioni colpite: WSO2 API Manager 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 e 4.6.0; API Control Plane 4.5.0 e 4.6.0; Traffic Manager 4.5.0 e 4.6.0; Universal Gateway 4.5.0 e 4.6.0.
  • Sfruttamento attivo: sì. watchTowr ha osservato il primo tentativo il 13 settembre; CISA ha fissato alle agenzie federali la scadenza del 27 settembre per correggere.

Perché un token falso vale così tanto

Secondo quanto riferito da watchTowr a SecurityWeek, il token contraffatto usato dall'attaccante dà accesso a tutti gli endpoint backend registrati nel gateway, alle relative credenziali e alle consumer key e ai secret di ogni applicazione registrata. I ricercatori hanno definito il prodotto, con una battuta amara, un servizio di "movimento laterale" pronto all'uso: da lì si possono intercettare le richieste API in transito verso i sistemi interni e interrogare servizi che normalmente non sono raggiungibili da Internet.

Un altro dettaglio merita attenzione. Il record CVE è stato pubblicato solo a inizio agosto e i dettagli tecnici non sono ancora pubblici, eppure watchTowr ha riprodotto la falla semplicemente confrontando il codice prima e dopo la patch. È la dinamica ormai consueta del patch diffing: la correzione stessa diventa la documentazione dell'exploit, e il tempo a disposizione di chi difende si misura in settimane, non in mesi.

Cosa significa per le aziende italiane

WSO2 dichiara quasi mille clienti enterprise nel mondo, concentrati in banche, pubblica amministrazione, telecomunicazioni e logistica, più una base molto più ampia di installazioni open source. In Italia la piattaforma è diffusa soprattutto tramite system integrator, che la adottano come API gateway in progetti di interoperabilità, open banking e integrazione fra applicazioni: proprio lo scenario in cui spesso manca un "proprietario" chiaro del componente dopo la messa in produzione.

Il rischio concreto non è tanto il defacement del gateway quanto ciò che sta dietro:

  • Settore finanziario: nelle architetture di open banking il gateway espone le API verso terze parti e custodisce le credenziali verso i sistemi core. Per i soggetti che ricadono in DORA, un accesso abusivo a questo livello è con ogni probabilità un incidente ICT grave da classificare e notificare secondo i criteri del regolamento.
  • Pubblica amministrazione e fornitori: gli enti che usano WSO2 per esporre servizi applicativi, direttamente o tramite fornitori, devono chiedere conferma formale del livello di aggiornamento. Se il gateway è gestito in outsourcing, la responsabilità dell'aggiornamento va verificata contrattualmente, non presunta.
  • Soggetti NIS2: un gateway API compromesso è un evento che può incidere sulla continuità di servizi essenziali o importanti; se c'è impatto significativo scatta la catena di notifica verso il CSIRT Italia (pre-notifica entro 24 ore, notifica entro 72 ore).
  • GDPR: se dalle API transitano dati personali, anche il solo accesso non autorizzato configura una violazione da valutare ai sensi degli articoli 33 e 34, con notifica al Garante entro 72 ore quando il rischio non è improbabile.

La lezione più ampia riguarda la governance: un componente installato anni fa da un integratore, stabile e "invisibile", è il candidato ideale a restare indietro con gli aggiornamenti. È esattamente il tipo di asset che un inventario serio dovrebbe far emergere.

Cosa fare subito

  • Censire tutte le istanze WSO2 API Manager, API Control Plane, Traffic Manager e Universal Gateway, comprese quelle gestite da fornitori o in ambienti di test esposti.
  • Aggiornare: i clienti con sottoscrizione devono portarsi almeno ai livelli di update indicati nell'advisory (ad esempio API Manager 4.6.0 update 21, 4.5.0 update 57, 4.4.0 update 72, 4.3.0 update 108, 4.2.0 update 197, 4.1.0 update 257); gli utenti open source devono applicare le correzioni pubbliche o migrare a una versione non vulnerabile.
  • Presumere la compromissione se l'istanza era esposta dopo il 13 settembre senza patch: analizzare i log di accesso alla ricerca di token JWT con algoritmi insoliti o richieste amministrative anomale.
  • Ruotare i segreti: rigenerare consumer key e secret delle applicazioni registrate e le credenziali verso i backend, perché un attaccante potrebbe averli già estratti.
  • Ridurre l'esposizione: le console di amministrazione e i portali di gestione non devono essere raggiungibili da Internet; limitare l'accesso via VPN o rete di management.
  • Documentare le verifiche svolte: in caso di ispezione o di incidente, poter dimostrare quando e come si è intervenuti è parte della conformità, non un dettaglio.