Non attribuito. CISA registra lo sfruttamento senza indicare un gruppo; la voce di catalogo riporta «knownRansomwareCampaignUse: Unknown»high
La correzione che ha spento la cifratura: CVE-2026-34486 su Apache Tomcat
Ad aprile 2026 Apache corregge una vulnerabilità dell'EncryptInterceptor, il componente che cifra il traffico di replica delle sessioni fra i nodi di un cluster Tomcat. La correzione però ne introduce un'altra: CVE-2026-34486, «Missing Encryption of Sensitive Data», dove la patch precedente consente di aggirare del tutto l'EncryptInterceptor. CVSS 3.1 pari a 7.5, con impatto esclusivamente sulla riservatezza. Il 4 agosto 2026 la CVE entra nel catalogo CISA delle vulnerabilità sfruttate davvero, con termine di rimedio al 7 agosto. Il paradosso è tutto qui: le versioni vulnerabili sono esattamente quelle che contenevano la correzione.
A cosa serve il componente di cui parliamo
Quando un'applicazione Java gira su più server Tomcat dietro un bilanciatore, i nodi devono scambiarsi le sessioni degli utenti: se il vostro carrello, la vostra autenticazione o il vostro token vivono nella sessione, e la richiesta successiva finisce su un altro nodo, quella sessione deve essere già arrivata lì. Il meccanismo si chiama replica delle sessioni, e viaggia sulla rete interna del cluster.
Dentro quel traffico c'è materiale sensibile: identificativi di sessione, attributi applicativi, a volte dati dell'utente. Per questo Tomcat mette a disposizione EncryptInterceptor, un componente che si inserisce nel canale di comunicazione fra i nodi e ne cifra il contenuto. È una misura pensata proprio per chi non si fida della rete su cui sta parlando — un data center condiviso, una rete cloud, un segmento a cui accedono più team.
Due difetti in fila
Il 9 aprile 2026 l'Apache Software Foundation pubblica due CVE che vanno lette insieme.
La prima è CVE-2026-29146: «Padding Oracle vulnerability in Apache Tomcat's EncryptInterceptor with default configuration». In parole semplici, il modo in cui il componente gestiva il riempimento dei blocchi cifrati permetteva a chi osservava il traffico di ricavare informazioni sul contenuto, un pezzo alla volta. Colpiva un intervallo molto ampio di versioni — da 11.0.0-M1 a 11.0.18, da 10.0.0-M1 a 10.1.52, da 9.0.13 a 9.0.115, e le vecchie serie 8.5 e 7.0 — e la correzione arriva con le versioni 11.0.19, 10.1.53 e 9.0.116. Il merito della scoperta, come indicato nel record CVE, è di Uri Katz e Avi Lumelsky di Oligo Security.
La seconda è CVE-2026-34486, e il titolo che le ha dato Apache dice già tutto: «Fix for CVE-2026-29146 allowed bypass of EncryptInterceptor». La descrizione ufficiale è «Missing Encryption of Sensitive Data vulnerability in Apache Tomcat due to the fix for CVE-2026-29146 allowing the bypass of the EncryptInterceptor». Classificazione CWE-311, mancata cifratura di dati sensibili. Versioni affette: 11.0.20, 10.1.53 e 9.0.116. Correzione nelle versioni 11.0.21, 10.1.54 e 9.0.117. Segnalata da Bartlomiej Dmitruk di striga.ai.
- 9 aprile 2026Le due CVE
Apache pubblica CVE-2026-29146 (padding oracle) e CVE-2026-34486 (bypass della correzione).
- 9 aprile 2026La patch della patch
Escono 11.0.21, 10.1.54 e 9.0.117.
- 4 agosto 2026In CISA KEV
La CVE entra nel catalogo delle vulnerabilità sfruttate davvero.
- 7 agosto 2026La scadenza
Termine di rimedio fissato da CISA per le agenzie federali statunitensi.
Il dettaglio che vale la pena guardare due volte
Le versioni 10.1.53 e 9.0.116 compaiono in entrambe le liste: sono le versioni che correggono il padding oracle e sono le versioni affette dal bypass. Chi ha aggiornato appena uscita la prima correzione — cioè chi ha fatto esattamente la cosa giusta, e in fretta — si è ritrovato con un componente di cifratura aggirabile.
Vale la pena essere precisi su cosa cambia fra i due difetti, perché non sono equivalenti. Un padding oracle è una debolezza crittografica: la cifratura c'è, ma perde informazione se qualcuno la sonda con pazienza. Un bypass dell'interceptor è un'altra cosa: significa che la cifratura può non esserci affatto. Il primo problema costringe l'attaccante a lavorare. Il secondo gli chiede solo di ascoltare.
Questo spiega anche il punteggio. Il CVSS 3.1 assegnato è 7.5, con vettore AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N: attaccabile dalla rete, senza privilegi né interazione dell'utente, impatto alto sulla riservatezza e nullo su integrità e disponibilità. Non è una presa di controllo del server: è il traffico del cluster che smette di essere protetto.
Perché è finita in KEV, e cosa significa davvero
Il catalogo Known Exploited Vulnerabilities della CISA non elenca vulnerabilità pericolose in teoria: elenca vulnerabilità di cui esistono prove di sfruttamento reale. La voce riporta dateAdded: 2026-08-04, dueDate: 2026-08-07, cwes: ["CWE-311"] e knownRansomwareCampaignUse: "Unknown". L'azione richiesta è ancorata alla direttiva BOD 26-04, che impone alle agenzie federali statunitensi di applicare le mitigazioni del produttore o dismettere il prodotto.
Una vulnerabilità che espone traffico interno di cluster finisce in KEV per un motivo preciso: il traffico di replica delle sessioni contiene, molto spesso, identificativi di sessione validi. Un identificativo di sessione valido è, per la maggior parte delle applicazioni, un'autenticazione già fatta. Chi lo intercetta non deve indovinare una password.
Va detto con altrettanta chiarezza cosa non sappiamo: CISA non pubblica i dettagli dello sfruttamento osservato, non indica un attore, e la finestra fra la disponibilità della patch (aprile) e l'ingresso in KEV (agosto) è di quasi quattro mesi. Non è noto pubblicamente quando lo sfruttamento sia iniziato.
Cosa fare
Verificate la versione, non la data dell'ultimo aggiornamento. Le versioni sicure sono 11.0.21, 10.1.54 e 9.0.117 o successive. Se siete su 11.0.20, 10.1.53 o 9.0.116 siete esposti anche se avete aggiornato di recente — anzi, lo siete proprio perché avete aggiornato di recente.
Controllate se usate davvero l'EncryptInterceptor. Il difetto riguarda chi ha configurato la cifratura del canale di cluster. Se il vostro Tomcat non è in cluster, o non usa quel componente, questa CVE specifica non vi tocca — ma allora vale la pena chiedersi cosa protegge oggi il traffico di replica, se c'è.
Non trattate la rete del cluster come una zona fidata. Il caso mostra la fragilità dell'assunto: il componente che rendeva sicuro quel canale è stato prima indebolito e poi disattivabile, senza che nulla cambiasse nel comportamento visibile dell'applicazione. Segmentazione della rete di replica, controllo di chi può raggiungere quelle porte e monitoraggio del traffico restano difese valide anche quando il livello crittografico si rompe.
Aggiungete un controllo al vostro processo di patching: la patch è stata a sua volta corretta? È il vero insegnamento di questa storia. Aggiornare rapidamente è la strategia giusta e va mantenuta — ma un aggiornamento non è un punto di arrivo. Le due CVE portano la stessa data di pubblicazione: chi ha letto l'advisory fino in fondo, ad aprile, aveva già entrambe le informazioni.
