Oracle Java CVE-2026-114820: le root CA eMudhra rimosse dal trust store del JDK

Oracle ha rotto la sua cadenza trimestrale per rilasciare una sola patch Java. CVE-2026-114820, pubblicata sull'NVD alle 19:17 UTC del 24 ottobre 2026, non è un bug di codice nella JVM: è un problema di trust store. Ogni JDK Oracle supportato continua a distribuire i certificati root della CA eMudhra nel proprio store cacerts predefinito, e otto delle chiavi private intermedie di eMudhra erano state generate così male che un ricercatore le ha ricalcolate tutte dai certificati pubblici in meno di un secondo. Il Security Alert fuori ciclo di Oracle rimuove quelle root dal trust store di Java. Finché non lo applichi, i tuoi JDK accetteranno un certificato TLS firmato con una chiave che chiunque può falsificare.

Notizia in evoluzione — pubblicata alle 23:43 (21:43 UTC) del 24 ottobre 2026. Aggiornata man mano che Oracle e CISA pubblicano.

In breve

CVE	CVE-2026-114820
Prodotto / versioni colpite	Oracle Java SE 8u511 · 11.0.33 · 17.0.21 · 21.0.13 · 25.0.5 · 27.0.1 e precedenti; Oracle GraalVM for JDK 17.0.21 e 21.0.13; GraalVM Enterprise Edition 21.3 — qualsiasi build il cui cacerts si fidi ancora delle root eMudhra
Corretta in	Security Alert fuori ciclo di Oracle del 2026-10-24 (aggiornamenti Java che rimuovono le root eMudhra da cacerts); applica l'ultima build del tuo ramo di rilascio secondo il Patch Availability Document di Oracle
CVSS	9.1 Critical · CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N · assegnato da Oracle (Secondary); l'NVD non ha un punteggio Primary
Sfruttata attivamente	No — CISA SSVC exploitation: none al 2026-10-24; Google non ha trovato certificati fraudolenti nei log di Certificate Transparency
CISA KEV	Non presente (catalogo versione 2026.10.23)
PoC pubblico	Nessuno pubblico al 2026-10-24; il recupero della chiave debole è banale — un ricercatore ha recuperato tutte e otto le chiavi private su un laptop in meno di un secondo
Advisory ufficiale	Oracle Security Alert — CVE-2026-114820

Cosa è successo

In una cerimonia di generazione delle chiavi dell'aprile 2025, eMudhra — una certification authority indiana le cui root sono (o erano) nei programmi Mozilla, Microsoft, Apple e Chrome — ha prodotto un secondo set di chiavi private deboli per otto CA intermedie. Nei certificati sono finite le chiavi deboli, non quelle forti previste. Il 17 ottobre 2026 un ricercatore ha riportato ai programmi root la prova firmata di controllo su tutte e otto le chiavi (sito dell'incidente eMudhra, gestito da Dennis Jackson). The Next Web ha riferito che una chiave privata valeva semplicemente il numero intero 4, laddove una chiave di quel tipo dovrebbe essere un numero casuale a 384 bit; Scott Helme le ha recuperate tutte e otto in meno di un secondo.

I browser si sono mossi in poche ore. Google ha bloccato le CA interessate in Chrome tramite un CRLSet basato sull'hash delle chiavi pubbliche il 17 ottobre, senza alcun aggiornamento del browser, e ha confermato che — poiché nessun certificato che risaliva a queste intermedie era mai stato registrato in Certificate Transparency — nessuno avrebbe potuto essere usato contro i client che applicano CT (blog di sicurezza Google, 20 ottobre). Apple ha bloccato il 19 ottobre, Microsoft il 20.

I browser sono la parte facile. La coda lunga è ogni client TLS che porta con sé il proprio trust store e non applica Certificate Transparency: runtime di linguaggio, immagini container e la JVM. Il lato Python, pip e certifi lo abbiamo trattato in un articolo collegato. L'alert di Oracle è il capitolo Java della stessa vicenda — ed è il motivo per cui CVE-2026-114820 porta la classe CWE-327 ("uso di un algoritmo crittografico debole o rischioso") e non una classe di memory safety: l'algoritmo va bene, non vanno bene le chiavi di cui si fida.

Chi è esposto — e come controllare i tuoi JDK

L'esposizione è qualunque applicazione che usi il cacerts predefinito del JDK per validare una connessione TLS e non faccia pinning dei certificati né applichi CT. È il caso comune: client HTTP, driver JDBC/TLS, broker di messaggi, chiamanti di webhook in uscita e qualsiasi servizio costruito su javax.net.ssl / JSSE con il trust store di serie.

L'attacco non è remote-code-execution e non è drive-by. Richiede che un attaccante (a) possieda una delle chiavi eMudhra ricalcolate — banale — e (b) si trovi sul percorso di rete tra il tuo JDK e l'host con cui parla, per poi presentare un certificato falsificato. Il bersaglio realistico è quindi un runner di CI su un segmento condiviso, un build server che raggiunge un registry interno, o un workload su una rete in cui l'attaccante ha già un punto d'appoggio — non un laptop ben protetto dietro NAT. Il vettore CVSS lo riflette: confidenzialità e integrità alte (leggere e riscrivere dati protetti da TLS), disponibilità nessuna.

Trova le root prima di decidere quanto è urgente. Su ciascun JDK:

# Elenca le root eMudhra / emSign ancora attendibili nel cacerts di questo JDK
keytool -list -cacerts -storepass changeit 2>/dev/null | grep -i -A1 emsign
# Forma esplicita se -cacerts non è disponibile:
keytool -list -keystore "$JAVA_HOME/lib/security/cacerts" -storepass changeit | grep -i emsign

Un risultato vuoto significa che quel JDK è già corretto o non ha mai incluso le root. Qualunque alias emsign… (ad esempio emsignrootcag1, emsigneccrootcag3) significa che quel runtime si fiderà di una catena falsificata finché non intervieni.

Remediation

1. Sono interessato? Esegui il controllo keytool -list … | grep -i emsign su ogni JRE/JDK del parco — non solo quelli che installi deliberatamente. I runtime incorporati negli application server, negli appliance dei fornitori, nelle immagini Docker e nei runtime personalizzati creati con jlink portano ciascuno il proprio cacerts.

2. Patch — la correzione esatta. Applica l'aggiornamento del Security Alert fuori ciclo di Oracle del 24 ottobre 2026: porta ogni ramo di rilascio alla build che rimuove le root eMudhra (Java SE 8, 11, 17, 21, 25, 27; GraalVM for JDK 17 e 21; GraalVM Enterprise Edition 21.3), secondo il Patch Availability Document collegato all'alert. Le distribuzioni OpenJDK (Temurin, Zulu, Corretto, Liberica, Microsoft) rilasciano la stessa rimozione con la propria cadenza — controlla la nota di ottobre 2026 del tuo fornitore e aggiorna il runtime, non solo il sistema operativo.

3. Non puoi applicare la patch subito? — rimuovi le root a mano. La correzione è una cancellazione dal trust store, quindi puoi farla immediatamente senza attendere l'aggiornamento completo del runtime:

# Cancella ogni root eMudhra/emSign trovata dal controllo list, ad esempio:
keytool -delete -alias emsignrootcag1    -cacerts -storepass changeit
keytool -delete -alias emsigneccrootcag3 -cacerts -storepass changeit

Fallo nella build dell'immagine, non solo sugli host in esecuzione, altrimenti il prossimo redeploy del container reintroduce le root. Per un runtime jlink, ricostruiscilo da un JDK corretto. Se un'applicazione sovrascrive lo store predefinito con il proprio -Djavax.net.ssl.trustStore, correggi anche quel file: la patch del JDK non tocca i trust store personalizzati.

4. Cerca segni di compromissione. Qui non ci sono IOC d'attaccante da inseguire — nulla è stato osservato in the wild. La caccia utile è l'inverso: interroga il monitoraggio di Certificate Transparency e l'ispezione TLS per qualsiasi certificato che risalga a una intermedia eMudhra/emSign presentato ai tuoi client, e rivedi i log di proxy e JSSE (-Djavax.net.debug=ssl:handshake) sui percorsi d'uscita ad alto valore per catene di issuer inattese. Mappa su MITRE ATT&CK T1557 (Adversary-in-the-Middle) e T1588.004 (Obtain Capabilities: Digital Certificates).

5. Bonifica e verifica. Dopo la patch o la cancellazione, riesegui il controllo keytool -list … | grep -i emsign e conferma che non restituisca nulla su ogni runtime. Tratta qualunque host che abbia terminato TLS attraverso la catena compromessa come bisognoso di rotazione delle credenziali per tutto ciò che è transitato su quella connessione.

Cosa non si sa ancora

• Se una delle chiavi ricalcolate sia mai stata usata per falsificare un certificato contro un client non-browser. Google non ha trovato nulla nei log CT, ma la CT non copre i client che non la controllano mai — esattamente la popolazione Java e Python.
• L'insieme preciso dei numeri di build OpenJDK per distribuzione che includono la rimozione; i fornitori stanno pubblicando durante la settimana.
• Se la CISA aggiungerà CVE-2026-114820 al catalogo KEV. Al catalogo 2026.10.23 non è presente e la valutazione SSVC registra l'exploitation come none.

Aggiorneremo questo articolo man mano che arrivano il Patch Availability Document di Oracle, le note dei fornitori OpenJDK e un'eventuale azione della CISA.

Dove ti lascia sul piano operativo

La domanda difficile stanotte non è "esiste una patch" — esiste — ma "quanti JDK eseguiamo davvero, e quali di essi si fidano ancora di queste root?" La maggior parte dei parchi non sa rispondere in fretta, perché i runtime si nascondono dentro appliance, immagini e application server che nessuno cataloga come "Java". È il lavoro che un red team autonomo fa per primo: l'AI Remediation Advisor di Zero Hunt classifica la correzione per sfruttabilità reale — non per il grezzo CVSS 9.1 — e poiché qui nulla è in KEV o sfruttato in the wild, la collocherebbe sotto una CVE di edge attivamente sfruttata, pur dandoti l'azione esatta per ogni runtime, la cancellazione da cacerts come controllo compensativo e una ri-verifica che esegue lo stesso controllo del trust store dopo la modifica invece di fidarsi di una stringa di versione. Trovare ogni runtime, prima ancora, è un problema di recon e validazione che lo swarm di 10 agenti affronta su tutta la flotta, su un appliance on-premise, con un umano che approva qualsiasi azione che tocchi un host di produzione.

Se un attaccante assume davvero la posizione di rete che questa falla richiede, la sessione TLS falsificata è l'unica prova — non c'è alcun log sull'endpoint che dica "è stato accettato un certificato fraudolento". È il caso per cui è stata costruita l'AI Traffic Analysis di Zero Hunt: un modello di deep learning con quattro teste di inferenza parallele, addestrato su miliardi di sequenze PCAP e in esecuzione localmente sulla GPU dell'appliance, segnala un handshake TLS anomalo verso una destinazione mai vista o una catena di issuer inattesa mentre la sessione è in corso — non nel digest SIEM del mattino dopo, quando i dati sono già stati letti.