Java ha avuto due release di sicurezza in due giorni. Il 20 ottobre 2026 il Critical Patch Update trimestrale di Oracle ha corretto 55 vulnerabilità in Java SE, 49 delle quali sfruttabili attraverso la rete senza effettuare il login. Il 21 ottobre Oracle ha fatto seguire un Security Alert fuori programma per CVE-2026-91403, una falla nell’implementazione TLS di Java (JSSE) con un punteggio CVSS di 9.1, e le versioni interessate comprendono quelle rilasciate il giorno prima. Il 21 ottobre l’IPA giapponese ha avvertito che lo sfruttamento può mandare in crash le applicazioni o permettere a un attaccante di prendere il controllo del computer. Questa guida mostra a quali versioni passare, come trovare ogni runtime Java in esecuzione e come verificare che l’aggiornamento sia davvero in uso.
Cosa è stato corretto il 20 ottobre
Il Critical Patch Update di ottobre riguarda Oracle Java SE 27, 26.0.2, 25.0.4.1, 21.0.12.1, 17.0.20.1, 11.0.32.1 e 8u503, e quindi ogni update precedente di quelle versioni. Nessuna delle 55 correzioni di Java è classificata come critica, ma 49 possono essere sfruttate da remoto senza autenticazione.
| Versione Java | Interessata | Corretta in (20 ottobre) |
|---|---|---|
| 27 | 27 | 27.0.1 |
| 25 (LTS) | fino a 25.0.4.1 | 25.0.5 |
| 21 (LTS) | fino a 21.0.12.1 | 21.0.13 |
| 17 (LTS) | fino a 17.0.20.1 | 17.0.21 |
| 11 (LTS) | fino a 11.0.32.1 | 11.0.33 |
| 8 (LTS) | fino a 8u503 | 8u511 |
Java 26 non ha ricevuto alcuna correzione: i suoi update sono terminati a settembre 2026. Se usa ancora la 26, passi alla 27 o alla release a lungo termine 25.
CVE-2026-91403: anche le nuove versioni sono interessate
CVE-2026-91403 si trova in JSSE, la parte di Java che gestisce le connessioni TLS. Secondo Oracle è facile da sfruttare, non richiede né un account né l’interazione dell’utente e può essere raggiunta attraverso la rete tramite diversi protocolli, per esempio tramite un servizio web che passa dati alle API interessate. Un attacco riuscito può leggere e modificare dati critici (CVSS 9.1, AV:N/AC:L/PR:N/UI:N, impatto elevato su riservatezza e integrità).
Le versioni interessate sono esattamente quelle del 20 ottobre: Java SE 8u511, 11.0.33, 17.0.21, 21.0.13, 25.0.5 e 27.0.1, oltre a GraalVM for JDK 17.0.21 e 21.0.13 e GraalVM Enterprise 21.3.20. Quindi il solo update di ottobre non la protegge da questa falla.
Oracle distribuisce la correzione per Oracle JDK tramite il documento di patch indicato nel Security Alert, per i clienti che hanno accesso a My Oracle Support. Al momento della stesura, le pagine pubbliche di Oracle non riportano ancora i nuovi numeri di versione e Oracle non ha dichiarato se la falla sia già sfruttata. Il progetto OpenJDK ha pubblicato il proprio advisory il 21 ottobre, quindi le build basate su OpenJDK (Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat e i pacchetti delle distribuzioni Linux) ricevono le correzioni dai rispettivi vendor. Controlli la pagina di sicurezza del suo vendor e installi la prima release che cita CVE-2026-91403. Aggiorneremo questo articolo quando i numeri di versione pubblici saranno disponibili.
Passo 1: trovare ogni runtime Java
java -version mostra solo il Java presente nel suo PATH. I server ne eseguono spesso diversi: uno incluso in un’applicazione, uno in un container, uno installato anni fa in /opt.
Su Linux, elenchi ogni binario Java con la sua versione:
sudo find / -xdev -type f -name java -perm -u+x 2>/dev/null | while read -r j; do echo "$j: $("$j" -version 2>&1 | head -n 1)"; done
Mostri quale Java usano effettivamente i processi in esecuzione:
for p in $(pgrep -f java); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done
In Docker, verifichi la versione di Java di ogni container in esecuzione:
for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" java -version 2>&1 | head -n 1)"; done
Su Windows, in PowerShell:
Get-ChildItem 'C:\Program Files','C:\Program Files (x86)' -Recurse -Filter java.exe -ErrorAction SilentlyContinue | ForEach-Object { "$($_.FullName): $((& $_.FullName -version 2>&1 | Select-Object -First 1))" }
Non dimentichi il software che porta con sé il proprio Java, come Jenkins, Elasticsearch, Keycloak, i prodotti Atlassian, i bundle di Tomcat, gli agent di build e i server di gioco.
Passo 2: aggiornare
Ubuntu e Debian (pacchetti OpenJDK):
sudo apt update && apt list --upgradable 2>/dev/null | grep -i jdk
sudo apt install --only-upgrade 'openjdk-*'
Red Hat, Rocky, AlmaLinux e Fedora:
sudo dnf upgrade 'java-*-openjdk*'
Oracle JDK: installi la release di ottobre per la sua versione dalla pagina di download di Oracle, poi la patch per CVE-2026-91403 da My Oracle Support appena possibile. Controlli prima la licenza: a partire dalla 21.0.13, gli update di Oracle JDK 21 non rientrano più nei No-Fee Terms and Conditions gratuiti e l’uso commerciale può richiedere un abbonamento a pagamento. Per le altre build di OpenJDK come Temurin o Corretto, installi la release più recente dal vendor.
Container: un aggiornamento sull’host non modifica un container. Scarichi l’immagine di base aggiornata, ricostruisca le sue immagini e le ridistribuisca.
Passo 3: riavviare e verificare
Java carica il proprio codice all’avvio, quindi un servizio in esecuzione mantiene la vecchia versione finché non viene riavviato. Dopo un aggiornamento dei pacchetti su Linux, questo comando elenca i processi Java che eseguono ancora i file sostituiti:
sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'java.*(deleted)'
Riavvii quei servizi, esegua di nuovo i comandi del passo 1 e confronti le versioni con la tabella qui sopra.
Finché la correzione di CVE-2026-91403 non è installata
- Consenta solo ai sistemi che ne hanno bisogno di raggiungere i servizi Java attraverso la rete, in particolare i servizi che accettano connessioni TLS da internet.
- Dove possibile, termini le connessioni TLS davanti al servizio Java, per esempio in un reverse proxy, così che meno connessioni TLS non attendibili raggiungano JSSE. Questo riduce l’esposizione, ma non sostituisce la correzione.
- Controlli nei log dei servizi Java esposti a internet la presenza di errori TLS e crash insoliti, e tenga pronti i backup.
Cosa succede dopo
Oracle ha portato Java a release di sicurezza più frequenti. La prossima, un Critical Security Patch Update, è prevista per il 17 novembre 2026, e il successivo Critical Patch Update trimestrale per il 19 gennaio 2027. Segni entrambe le date nel suo calendario e ripeta ogni volta i tre passi qui sopra.
Se non è sicuro di quali suoi sistemi eseguano Java, o se un servizio Java potrebbe essere già stato attaccato, i nostri team di sicurezza gestita e risposta agli incidenti possono aiutarla.
