CVE-2026-118636: RCE in Apache MINA 3.0 senza patch, come verificare e migrare a 2.2.x

Se la tua azienda ha un'applicazione Java che usa Apache MINA 3.0 e il suo modulo codec, devi controllarla ora. La vulnerabilità CVE-2026-118636 permette l'esecuzione di codice remoto tramite deserializzazione Java non filtrata e ha punteggio CVSS 9.8. Il punto più delicato è questo: il progetto ha dichiarato che il ramo 3.0 è inattivo e che non uscirà una versione corretta. L'unica strada indicata è passare all'ultima release del ramo Apache MINA 2.2.x.

Cosa è successo: la vulnerabilità CVE-2026-118636 in Apache MINA 3.0

Apache MINA è una libreria Java per costruire applicazioni di rete ad alte prestazioni. Il componente JavaNativeMessageDecoder, nel modulo codec di MINA 3.0, ricostruisce oggetti Java dai byte ricevuti in rete chiamando ObjectInputStream.readObject() senza alcun filtro sulle classi ammesse. Se l'applicazione espone questo decoder a un peer non fidato, chi invia i dati può far deserializzare una catena di oggetti costruita ad arte (gadget chain) e ottenere l'esecuzione di codice sul server. La segnalazione è marcata UNSUPPORTED WHEN ASSIGNED: il codice interessato non è più mantenuto.

Chi è colpito: versioni vulnerabili di Apache MINA 3.0

Il brief indica il ramo Apache MINA 3.0, in particolare il modulo codec con la classe JavaNativeMessageDecoder. Non esistono versioni corrette di quel ramo. Sei esposto se:

• la tua applicazione dipende da artefatti MINA della serie 3.0.x;
• usa JavaNativeMessageDecoder, direttamente o tramite codice che lo configura nella catena di filtri;
• il servizio di rete che lo usa riceve connessioni da client non controllati da te.

Le applicazioni che si appoggiano al ramo 2.2.x non sono oggetto di questa segnalazione. Eventuali dettagli aggiuntivi sui componenti coinvolti vanno verificati sull'advisory ufficiale linkato in fondo.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio è 9.8 su 10, gravità critica, con vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In parole semplici: attacco via rete, bassa complessità, nessuna credenziale richiesta, nessuna azione dell'utente, impatto alto su riservatezza, integrità e disponibilità. L'esito è una RCE, esecuzione di codice remoto con i privilegi del processo Java.

Al momento la vulnerabilità non risulta nel catalogo CISA KEV, quindi non ci sono conferme pubbliche di sfruttamento attivo. Le vulnerabilità di deserializzazione Java sono però ben conosciute e gli strumenti per costruire gadget chain sono di dominio pubblico. Non conviene attendere.

Come capire se sei esposto: verifica versione, esposizione e log

Verifica della versione di Apache MINA

• Con Maven: mvn dependency:tree | grep -i mina dalla cartella del progetto. Con Gradle: gradle dependencies | grep -i mina.
• Su un server già in produzione: find / -iname "mina-*.jar" 2>/dev/null e controlla il numero di versione nel nome del file o nel MANIFEST.MF all'interno del jar.
• Nel codice sorgente: grep -r JavaNativeMessageDecoder src/. Se compare, il decoder è in uso.

Verifica dell'esposizione in rete

• Sul server: ss -tulpn (Linux) oppure netstat -ano (Windows) per vedere su quali porte ascolta il processo Java.
• Dal firewall perimetrale: controlla se quelle porte hanno regole di NAT o accesso da internet, oppure da reti interne non segmentate.
• Chiediti chi sono i client: se sono solo sistemi tuoi, il rischio è più contenuto; se possono collegarsi terzi, l'esposizione è piena.

Log e indicatori di compromissione

• Nei log applicativi cerca eccezioni come ClassNotFoundException, InvalidClassException o StreamCorruptedException in corrispondenza di connessioni insolite: possono indicare tentativi di deserializzazione malevola.
• Verifica processi figli inattesi avviati dal processo Java (shell, curl, wget, powershell).
• Controlla connessioni in uscita verso indirizzi sconosciuti e modifiche a crontab, servizi o attività pianificate.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

Per CVE-2026-118636 non esiste e non è prevista una patch per il ramo 3.0. Il progetto raccomanda di usare l'ultima release del ramo Apache MINA 2.2.x. La versione esatta va presa dalla pagina ufficiale di download di Apache MINA e dall'advisory in fondo all'articolo.

Nella pratica il rimedio è una migrazione, non un semplice aggiornamento di numero di versione. Le API di MINA 3.0 e 2.2.x differiscono: serve adeguare il codice, ricompilare e testare. Nel frattempo, se l'applicazione non può essere migrata subito, l'alternativa è eliminare l'uso di JavaNativeMessageDecoder e sostituire il formato di scambio dati con uno che non si basi sulla serializzazione nativa Java (ad esempio JSON o Protocol Buffers con parser dedicati).

Cosa fare subito: mitigazioni e hardening

1. Chiudi l'esposizione. Se il servizio è raggiungibile da internet o da reti non fidate, bloccalo sul firewall e consenti solo gli indirizzi dei client legittimi.
2. Segmenta. Sposta il servizio in una VLAN dedicata con regole esplicite verso il resto della rete, così che un'eventuale compromissione non si propaghi.
3. Limita i privilegi del processo Java. Non deve girare come root o amministratore e non deve avere accesso a file system e credenziali oltre il necessario.
4. Valuta un filtro di deserializzazione a livello JVM. Le versioni moderne di Java offrono il meccanismo ObjectInputFilter, configurabile anche tramite la proprietà jdk.serialFilter, per rifiutare classi non previste. È una difesa aggiuntiva, non un sostituto della migrazione, e va testata con attenzione perché può rompere il protocollo esistente.
5. Ruota le credenziali presenti nella configurazione dell'applicazione (database, servizi, chiavi API) se il servizio è stato esposto, anche senza prove di compromissione.
6. Pianifica la migrazione a 2.2.x con una data e un responsabile.

Se sospetti una compromissione: incident response e analisi forense

Se trovi gli indicatori descritti sopra, non spegnere il server e non reinstallare nulla. Spegnere cancella la memoria RAM, dove spesso risiedono le tracce dell'attaccante. Procedi così:

• isola la macchina dalla rete a livello di switch o firewall, lasciandola accesa;
• preserva i log applicativi, di sistema e del firewall copiandoli su un supporto separato;
• fai eseguire una copia forense del sistema e, se possibile, un'acquisizione della memoria, prima di qualsiasi bonifica;
• valuta con il titolare del trattamento se ricorrono i presupposti per la notifica al Garante entro 72 ore prevista dal GDPR.

Come perito informatico forense mi occupo di incident response e analisi post incidente: il listino indicativo va da 1.500 a 6.000 € per l'incident response e da 2.000 a 8.000 € per un audit di cybersecurity completo, con preventivo a prezzo fisso. Trovi il dettaglio nella pagina dei servizi dello studio.

Fonti ufficiali

• Annuncio sulla mailing list Apache
• Record CVE-2026-118636 su cve.org
• Segnalazione su oss-security (Openwall)

Serve una mano a verificare o migrare?

Se non sai se le tue applicazioni Java usano Apache MINA 3.0, o se le usano e non puoi migrarle da solo, posso fare un'analisi delle dipendenze, verificare l'esposizione in rete e impostare le mitigazioni. Richiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti, anche su WhatsApp.