La risposta breve
Il 4 agosto 2026 la CISA ha aggiunto la CVE-2026-34486 – una falla nel clustering di Apache Tomcat che aggira l'EncryptInterceptor a protezione del traffico tra nodi – al proprio catalogo delle vulnerabilità note sfruttate, il che significa che è usata negli attacchi. Il difetto è una correzione incompleta di un problema precedente (CVE-2026-29146): i messaggi di cluster la cui decifratura fallisce vengono elaborati anziché rifiutati, permettendo a un attaccante di iniettare traffico nel canale Tomcat Tribes. È valutata CVSS 7,5, ha codice proof-of-concept pubblico e colpisce Tomcat 11.0.20, 10.1.53 e 9.0.116 – le correzioni sono in 11.0.21, 10.1.54 e 9.0.117.
Ciò che conta oltre un singolo avviso è la portata. Tomcat sta sotto una larga parte delle applicazioni web Java – spesso in modo invisibile, integrato nei servizi Spring Boot – per cui « non usiamo Tomcat » è spesso falso. Se una di queste applicazioni usa il clustering per la replica delle sessioni, il canale vulnerabile potrebbe essere attivo nel vostro parco proprio ora.
Che cos'è la CVE-2026-34486
Il supporto al clustering di Apache Tomcat consente a più istanze di Tomcat di replicare le sessioni HTTP tra loro, così che un utente resti connesso anche se un nodo viene meno. Quella replica scorre su Tomcat Tribes, uno strato di comunicazione di gruppo, e può essere avvolta dall'EncryptInterceptor per cifrare il traffico tra i nodi. La CVE-2026-34486 – che la CISA etichetta come falla di mancata cifratura di dati sensibili e che è stata segnalata da Bartlomiej Dmitruk di striga.ai – vanifica quella protezione.
Fatto cruciale, si tratta di una regressione da una correzione precedente incompleta. La rimedio della CVE-2026-29146 ha cambiato il modo in cui l'EncryptInterceptor gestiva gli errori di decifratura e, così facendo, ha portato Tomcat a continuare a elaborare i messaggi anche quando la decifratura falliva, invece di scartarli. L'effetto netto è che messaggi mai decifrati correttamente possono comunque essere accettati e propagati nel cluster, annullando la garanzia che l'intercettore avrebbe dovuto fornire. Ha un punteggio CVSS di base di 7,5 e colpisce Tomcat 11.0.20, 10.1.53 e 9.0.116.
Come funziona l'aggiramento del cluster
Poiché i messaggi non decifrati correttamente non vengono più rifiutati, un attaccante in grado di inviare traffico al ricevitore Tribes del cluster – la porta TCP 4000 per impostazione predefinita – può spingere messaggi appositamente costruiti nel canale di replica che Tomcat elaborerà. Di per sé è già un grave difetto di integrità. Il pericolo si acuisce quando quei messaggi trasportano oggetti Java serializzati: se l'applicazione bersaglio ha gadget di deserializzazione utilizzabili nel classpath, i dati iniettati possono passare, come ha scritto un'analisi, « dal traffico spazzatura all'esecuzione di codice ». È per questa via che una falla di clustering diventa un rischio di esecuzione di codice da remoto non autenticata.
Due fatti aumentano l'urgenza. Primo, il codice di exploit proof-of-concept è già pubblico, il che accorcia la distanza tra « falla nota » e « scansione di massa ». Secondo, la CISA elenca una vulnerabilità nel proprio catalogo delle vulnerabilità sfruttate solo quando dispone di prove affidabili che gli attaccanti la stanno già usando – e ha aggiunto la CVE-2026-34486 il 4 agosto 2026, insieme a falle in N-able N-central e Langflow. Trattatela come una minaccia attiva, non teorica.
Perché il raggio d'impatto è ampio
Tomcat è uno dei server applicativi Java più diffusi al mondo, e gran parte di questa impronta è invisibile: framework come Spring Boot spediscono un Tomcat integrato per impostazione predefinita, così i team lo eseguono senza mai installare « Tomcat » come prodotto autonomo. Questo rende l'inventario la prima sfida – la versione vulnerabile può essere incorporata nelle dipendenze di un servizio anziché risiedere su un server che qualcuno corregge direttamente.
La nota positiva è che solo i deployment che usano il clustering di Tomcat per la replica delle sessioni espongono il canale Tribes vulnerabile; un servizio a nodo singolo, o che mantiene lo stato di sessione in uno store condiviso come Redis, non è interessato da questo percorso specifico. Ma i grandi parchi ad alta disponibilità – esattamente i sistemi Java aziendali più propensi a custodire dati regolamentati – sono quelli che più probabilmente usano il clustering. La combinazione di ampia diffusione, distribuzione integrata e una funzione di alta disponibilità è ciò che trasforma una CVSS 7,5 in un'operazione di patch su tutto il parco.
Cosa significa per i team software in Italia
Se gestite servizi Java su larga scala, il primo compito non è applicare patch ma scoprire: trovare ogni punto in cui gira un Tomcat vulnerabile, comprese le copie integrate in Spring Boot e altri framework, e individuare quali di essi usano davvero il clustering. L'analisi della composizione del software (SCA) e un inventario delle dipendenze rendono la cosa gestibile; tirare a indovinare no. Una volta noto dove il clustering è abilitato, la porta del ricevitore Tribes diventa l'elemento da blindare – non deve mai essere raggiungibile dal traffico applicativo, da altri tenant o da Internet, ma solo da peer di cluster fidati.
Cosa cambia per il mercato italiano: Java e Tomcat integrato tramite Spring Boot sostengono gran parte dei sistemi bancari, assicurativi e della pubblica amministrazione in Italia – proprio dove l'alta disponibilità si basa sul clustering di replica delle sessioni. L'ACN e il CSIRT Italia pubblicano bollettini per vulnerabilità sfruttate attivamente; per i soggetti che rientrano nel NIS2 (recepito con il D.lgs. 138/2024) e gli operatori di servizi essenziali, una falla inserita nel catalogo KEV e capace di portare all'esecuzione di codice impone una patch entro tempi definiti, non un intervento facoltativo. Sul fronte dei dati personali, il GDPR e il Garante si aspettano che il rischio sia individuato e sanato.
Per i settori regolamentati l'inquadramento è familiare. Sotto SOC 2, DORA e il GDPR, una falla non corretta, attivamente sfruttata e in grado di raggiungere l'esecuzione di codice è una lacuna di controllo che ci si aspetta venga individuata e chiusa entro una tempistica definita – e un inserimento nel KEV è esattamente il segnale su cui gli auditor si aspettano un'azione. La risposta pragmatica è integrarla nella normale pratica di audit di sicurezza e gestione delle patch: inventariare l'esposizione, applicare la patch alla versione corretta, verificare la segmentazione di rete che sarebbe dovuta essere il vero confine fin dall'inizio, e rivedere i vostri servizi Java per i gadget di deserializzazione che trasformano l'iniezione di messaggi in esecuzione di codice.
Come reagire adesso
È un intervento di tipo correggi-e-verifica, non un rifacimento completo. I passaggi seguenti portano un parco Tomcat in cluster da esposto a contenuto.
- Applicare la patch alla versione corretta. Aggiornate a Tomcat 11.0.21, 10.1.54 o 9.0.117; per Tomcat integrato, alzate la versione che il vostro framework (ad esempio Spring Boot) include, invece di presumerlo non interessato.
- Inventariare il Tomcat integrato. Usate l'analisi della composizione del software per trovare ogni servizio che spedisce 11.0.20, 10.1.53 o 9.0.116, comprese le dipendenze transitive – i server autonomi sono la parte facile.
- Individuare dove il clustering è attivo. Solo i deployment che usano il clustering di replica delle sessioni di Tomcat espongono il canale Tribes vulnerabile; identificateli per primi e dategli priorità.
- Blindare la porta Tribes. Assicuratevi che TCP/4000 (o la porta ricevente configurata) sia raggiungibile solo da membri fidati del cluster tramite regole del firewall e gruppi di sicurezza – mai da reti applicative o pubbliche.
- Ridurre l'esposizione alla deserializzazione. Rivedete il classpath delle applicazioni in cluster per individuare i gadget di deserializzazione Java noti, poiché sono questi a far raggiungere ai messaggi iniettati l'esecuzione di codice.
- Integrare il KEV nel vostro SLA di patch. Monitorate il catalogo delle vulnerabilità sfruttate della CISA e assegnate alle falle elencate nel KEV presenti nel vostro stack una scadenza di remediation accelerata e definita.
Il segnale strategico della CVE-2026-34486 è uno familiare che vale la pena riapprendere: un canale interno cifrato è uno strato di difesa, non un sostituto del tenere quel canale lontano da reti non fidate. I team che inventariano il proprio Tomcat integrato, applicano la patch alla versione corretta e confermano che la porta Tribes è segmentata dietro il confine di rete chiudono la questione in modo pulito – e ne escono con un'architettura di cluster che avrebbe resistito alla falla persino prima dell'arrivo della patch.
Domande frequenti
Che cos'è la CVE-2026-34486 in Apache Tomcat?
La CVE-2026-34486 è una vulnerabilità nel supporto al clustering di Apache Tomcat che consente a un attaccante di aggirare l'EncryptInterceptor, il componente che dovrebbe cifrare il traffico tra i nodi del cluster. Deriva da una correzione incompleta della CVE-2026-29146: quella modifica precedente ha alterato la gestione degli errori di cifratura, così che i messaggi la cui decifratura falliva venivano elaborati anziché rifiutati, permettendo di accettare messaggi di cluster non decifrati correttamente. Ha un punteggio CVSS di 7,5 e colpisce Apache Tomcat 11.0.20, 10.1.53 e 9.0.116, con correzioni in 11.0.21, 10.1.54 e 9.0.117.
La CVE-2026-34486 può portare all'esecuzione di codice da remoto?
Sì, ma a condizioni specifiche e non automaticamente. Poiché la falla consente a un attaccante di iniettare messaggi nel canale di comunicazione Tomcat Tribes del cluster, lo sfruttamento può degenerare in esecuzione di codice da remoto se l'attaccante riesce a raggiungere la porta del ricevitore Tribes (TCP/4000 per impostazione predefinita) e l'applicazione bersaglio dispone di gadget di deserializzazione Java utilizzabili nel classpath. È stato pubblicato codice di exploit proof-of-concept e la CISA ha inserito la falla nel proprio catalogo delle vulnerabilità note sfruttate sulla base di prove di sfruttamento attivo.
Quali versioni di Tomcat sono interessate e come si corregge?
La falla interessa Apache Tomcat 11.0.20, 10.1.53 e 9.0.116. Aggiornare a 11.0.21, 10.1.54 o 9.0.117, che risolvono il problema. I team che usano Spring Boot o altri framework che integrano Tomcat devono aggiornare la versione di Tomcat inclusa anziché presumere che il framework non sia interessato. Poiché la CISA ha classificato la falla come sfruttata, le agenzie federali statunitensi hanno una scadenza ai sensi della Binding Operational Directive 22-01; in Italia i soggetti che rientrano nel NIS2 dovrebbero allo stesso modo trattarla come una patch prioritaria.
Non esponiamo il clustering di Tomcat su Internet – siamo al sicuro?
Non automaticamente. Il controllo reale è che il canale di cluster Tomcat Tribes e la sua porta ricevente (TCP/4000 per impostazione predefinita) siano raggiungibili solo da altri membri fidati del cluster, mai dal traffico applicativo, da altri tenant o dalla rete più ampia. L'EncryptInterceptor era pensato come difesa in profondità per quel canale, e questa falla mostra perché non può essere l'unica salvaguardia. Verificate che regole del firewall, gruppi di sicurezza e segmentazione di rete isolino il traffico del cluster, e ricordate che un host compromesso nello stesso segmento potrebbe comunque raggiungere la porta.
Perché questo conta oltre una singola CVE?
Apache Tomcat esegue una larga parte delle applicazioni web Java del mondo, direttamente o integrato in framework come Spring Boot, quindi una falla nel suo percorso di clustering ha un'ampia portata. L'incidente ricorda che i canali di replica delle sessioni e di cluster sono interfacce interne privilegiate: vanno separati dalla rete applicativa, corretti secondo uno SLA definito e revisionati per l'esposizione alla deserializzazione Java. La cifratura su un collegamento di cluster non sostituisce il tenere quel collegamento lontano da reti non fidate.
Fonti
CISA – Adds Three Known Exploited Vulnerabilities to Catalog (4 agosto 2026)
Apache Tomcat – Security advisories (Tomcat 11), CVE-2026-34486
SOCRadar – CVE-2026-34486: Apache Tomcat Tribes Regression Creates Unauthenticated RCE Path