Se gestisci Apache Tomcat e usi endpoint WebSocket protetti, verifica subito la versione: CVE-2026-76183 può permettere il bypass dei vincoli di sicurezza configurati sugli endpoint interessati. Apache classifica il problema come Important e indica come corrette le versioni 11.0.26, 10.1.60 e 9.0.122. Le serie 8.5 e 7 risultano coinvolte ma sono fuori supporto, quindi non vanno mantenute come soluzione stabile.
La vulnerabilità è stata resa pubblica il 23 settembre 2026. Il problema nasce dal modo in cui Tomcat interpreta alcuni percorsi di richiesta come template degli endpoint WebSocket: in determinate condizioni questo può far sì che i vincoli di sicurezza previsti per l’endpoint non vengano applicati come atteso. NVD riporta inoltre un punteggio CVSS 3.1 di 9,8 fornito da CISA-ADP, mentre la valutazione ufficiale del progetto Apache resta “Important”.
Quali versioni di Tomcat sono vulnerabili
| Ramo Tomcat | Versioni interessate | Versione corretta |
|---|---|---|
| 11.0.x | 11.0.0-M1 fino a 11.0.25 | 11.0.26 |
| 10.1.x | 10.1.0-M1 fino a 10.1.59 | 10.1.60 |
| 9.0.x | 9.0.0.M1 fino a 9.0.121 | 9.0.122 |
| 8.5.x | 8.5.0 fino a 8.5.100 | Serie fuori supporto |
| 7.0.x | 7.0.43 fino a 7.0.109 | Serie fuori supporto |
Apache avverte che anche altre versioni non più supportate potrebbero essere coinvolte. Se utilizzi un ramo EOL, non cercare una patch isolata come strategia definitiva: pianifica la migrazione a una versione ancora mantenuta.
1. Controlla la versione realmente in esecuzione
Non affidarti soltanto al nome dell’immagine container, alla documentazione interna o a una vecchia CMDB. Verifica la versione sull’istanza realmente attiva. In un’installazione classica puoi usare lo script bin/version.sh su Linux o binversion.bat su Windows. Nei container controlla anche il tag dell’immagine e l’output del processo in esecuzione.
Se Tomcat arriva da un pacchetto della distribuzione Linux, confronta il numero di versione con l’advisory del vendor: alcune distribuzioni applicano backport di sicurezza mantenendo un numero di versione apparentemente più vecchio. In quel caso il riferimento corretto è il pacchetto del distributore, non un confronto meccanico con il tarball upstream.
2. Se rientri nell’intervallo vulnerabile, aggiorna
Per le installazioni upstream, Apache raccomanda il passaggio a 11.0.26, 10.1.60 o 9.0.122 in base al ramo utilizzato. Prima dell’upgrade salva configurazione, applicazioni e file necessari al rollback, quindi prova l’aggiornamento in staging se il servizio è critico.
Non modificare contemporaneamente connettori, reverse proxy, certificati e regole di autenticazione. Se dopo l’upgrade l’applicazione non parte, separa il problema di compatibilità dalla vulnerabilità. Abbiamo già affrontato un caso diverso nella guida su Apache che non parte su Ubuntu dopo un aggiornamento: qui però il prodotto e la causa sono differenti, perché CVE-2026-76183 riguarda Tomcat e gli endpoint WebSocket.
3. Capisci se la tua applicazione usa WebSocket protetti
La falla non va descritta come un bypass universale di ogni autenticazione Tomcat. L’advisory parla specificamente di security constraints per endpoint WebSocket. Controlla quindi le applicazioni che espongono WebSocket e le regole di accesso associate. Se il server ospita solo applicazioni HTTP tradizionali senza endpoint WebSocket, lo scenario concreto può essere diverso, ma la versione vulnerabile resta da aggiornare.
Verifica anche eventuali applicazioni distribuite da terze parti: un endpoint WebSocket può essere presente in un prodotto senza essere evidente all’utente finale. Inventaria i WAR, la configurazione e le dipendenze prima di concludere che il server non utilizzi questa funzione.
4. Reverse proxy e WAF non sostituiscono la patch
Un reverse proxy può limitare l’esposizione, filtrare percorsi o imporre ulteriori controlli, ma non corregge il parsing interno di Tomcat. Se il backend vulnerabile resta raggiungibile, considera proxy e WAF come livelli aggiuntivi, non come sostituti dell’aggiornamento.
Lo stesso principio vale per altre vulnerabilità della supply chain o dell’ecosistema Java: la guida su MavenGate e librerie Java abbandonate mostra perché inventario e provenienza dei componenti contano quanto la configurazione del server.
5. Dopo l’upgrade controlla log e comportamento degli endpoint
Dopo l’aggiornamento riavvia il servizio secondo le procedure previste, verifica che la versione corretta sia realmente attiva e prova gli endpoint WebSocket con account autorizzati e non autorizzati. L’obiettivo è confermare che l’applicazione continui a funzionare e che i controlli di accesso restino applicati.
Conserva i log del periodo precedente all’upgrade se il server è esposto a Internet. L’assenza di anomalie visibili non prova da sola che non ci siano stati tentativi. Allo stesso tempo, al momento della stesura non abbiamo una fonte primaria che dimostri uno sfruttamento massivo in corso di CVE-2026-76183: evita quindi conclusioni non supportate.
Cosa evitare
- Non lasciare esposto un ramo vulnerabile solo perché l’applicazione sembra funzionare normalmente.
- Non trattare il punteggio 9,8 riportato da NVD come una valutazione NVD: è attribuito a CISA-ADP.
- Non considerare reverse proxy o WAF una patch per Tomcat.
- Non mantenere Tomcat 7 o 8.5 come soluzione a lungo termine: sono rami fuori supporto.
- Non eseguire upgrade direttamente in produzione senza backup e verifica dell’applicazione quando il servizio è critico.
Verifica finale
Se la tua installazione rientra negli intervalli vulnerabili, la risposta pratica è aggiornare al ramo corretto e verificare gli endpoint WebSocket protetti. Per Tomcat 11 il riferimento è 11.0.26, per 10.1 è 10.1.60 e per 9.0 è 9.0.122. Se usi pacchetti della distribuzione, verifica l’advisory del vendor per eventuali backport.
Le versioni e la valutazione ufficiale sono riportate nelle pagine di sicurezza di Apache Tomcat. Il record NVD di CVE-2026-76183 riepiloga gli intervalli interessati e il punteggio fornito da CISA-ADP.
