CVE-2026-120201: bypass di autenticazione in Jpom, come verificare e aggiornare

CVE-2026-120201 è una vulnerabilità critica (CVSS 9.8) in Jpom, la piattaforma open source di build, deploy e gestione server del progetto dromara. Le versioni dalla 2.10.0 alla 2.11.12 permettono a chiunque, senza credenziali, di ottenere i privilegi di super amministratore iniettando una condizione di query nell'header HTTP JPOM-USER-TOKEN. Da lì l'attaccante può eseguire comandi tramite le funzioni di script di Jpom. Se usi Jpom e il server è raggiungibile da internet, considera l'istanza esposta e agisci oggi.

Cosa è successo: la vulnerabilità CVE-2026-120201 in Jpom

Jpom legge il token di sessione dall'header JPOM-USER-TOKEN nel componente LoginInterceptor del modulo server. Il valore viene usato per cercare l'utente nel database tramite la libreria Hutool. Il parser Condition di Hutool interpreta alcune stringhe come operatori SQL invece che come valori letterali: inviando qualcosa come is not null, la condizione non confronta più il token con quello salvato ma seleziona un utente qualsiasi con token valorizzato. Il risultato è un bypass di autenticazione che restituisce una sessione con i privilegi più alti disponibili.

Il problema non è un bug di una singola pagina. È nell'intercettore che protegge tutte le API del server, quindi ogni funzione riservata diventa raggiungibile.

Chi è colpito: versioni vulnerabili di Jpom

• Jpom server da 2.10.0 a 2.11.12 inclusa.
• Tutte le modalità di installazione: pacchetto jar, script di installazione, container Docker e docker-compose.
• Il componente interessato è il modulo server. Gli agent (plugin end) comunicano via HTTP con il server e, una volta compromesso il server, sono raggiungibili con le credenziali che il server conserva.

La versione corretta non risulta indicata nelle fonti disponibili. Va verificata direttamente sul repository GitHub di dromara/Jpom e nel CHANGELOG. Il README rimanda inoltre a una pagina sulla sospensione del progetto e annuncia una futura versione 3.0: prima di contare su un aggiornamento, controlla che il ramo 2.x riceva ancora correzioni.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio è 9.8 con vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In pratica: attacco dalla rete, bassa complessità, nessun privilegio richiesto, nessuna interazione dell'utente, impatto alto su riservatezza, integrità e disponibilità. Al momento la vulnerabilità non compare nel catalogo CISA KEV, quindi non risulta uno sfruttamento attivo documentato. Un advisory pubblico con dettagli sull'header e sul valore da iniettare rende però l'exploit facile da riprodurre.

Cosa ottiene un attaccante: accesso come super amministratore, poi esecuzione di comandi arbitrari tramite gli script di Jpom. Jpom gestisce terminali SSH verso i server collegati, container Docker, file di progetto, configurazioni nginx e pipeline di build. Compromettere il server Jpom equivale spesso a compromettere l'intera infrastruttura di deploy.

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

Verifica della versione

• Interfaccia web: la versione è mostrata nelle informazioni di sistema del pannello server.
• Installazione jar: controlla il nome del file jar del server nella cartella di installazione o nello script di avvio.
• Docker: docker ps e docker inspect sul container del server mostrano il tag dell'immagine in uso.

Verifica dell'esposizione

• Sul server: ss -tlnp (Linux) o netstat -ano (Windows) per vedere su quale porta e interfaccia ascolta il server Jpom.
• Controlla firewall, NAT del router e regole del cloud provider: la porta del server o il virtual host del reverse proxy devono essere raggiungibili solo da VPN o rete interna.
• Da una rete esterna prova a raggiungere l'URL del pannello. Se risponde la pagina di login, sei esposto.

Log e indicatori di compromissione

• Log di accesso di nginx o del reverse proxy: richieste alle API del server da IP sconosciuti, in particolare verso funzioni di script, SSH e utenti. Gli access log standard non registrano gli header personalizzati, quindi l'assenza della stringa is not null nei log non prova nulla.
• Log operativi interni di Jpom: accessi del super amministratore da IP o orari anomali, script creati o modificati di recente, esecuzioni di comandi, nuovi utenti, nuove chiavi SSH o nodi aggiunti.
• Sui server gestiti: cronjob, processi, chiavi in authorized_keys e container non riconosciuti.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

Il rimedio definitivo è aggiornare a una versione che corregga la lettura del token nel LoginInterceptor. Al momento non è disponibile, nelle fonti citate, una versione corretta confermata: verifica release e CHANGELOG sul repository ufficiale e nell'advisory VulnCheck prima di aggiornare. Se non esiste una release corretta o il progetto non riceve più manutenzione, i workaround della sezione successiva diventano l'unica difesa e va valutata la sostituzione dello strumento.

Se aggiorni: ferma il servizio, esegui un backup completo della directory dati, sostituisci il jar o il tag dell'immagine Docker, riavvia e verifica la versione dal pannello. Ricorda l'avvertenza del progetto: dopo l'upgrade dalla 2.7.x in poi il downgrade non è supportato.

Cosa fare subito: mitigazioni e hardening

1. Togli il pannello da internet. Chiudi la porta sul firewall e rendi il server raggiungibile solo tramite VPN. Se non ne hai una, in questa guida su WireGuard per PMI spiego come impostarla.
2. Filtra l'header sul reverse proxy. Se usi nginx o un WAF, blocca le richieste il cui JPOM-USER-TOKEN contiene spazi o parole chiave SQL. Un token legittimo è una stringa compatta, non una frase.
3. Limita gli IP sorgente alle sole postazioni che amministrano Jpom.
4. Ruota le credenziali. Password degli utenti Jpom, token, password e chiavi SSH dei server collegati, credenziali dei repository Git e SVN usati nelle build, webhook.
5. Attiva MFA sugli account Jpom. Non impedisce il bypass, ma riduce altri rischi.
6. Segmenta la rete: il server Jpom non deve avere accesso diretto a sistemi che non gestisce.

Se sospetti una compromissione: incident response e analisi forense

Se trovi script sconosciuti, accessi anomali o comandi non tuoi, non spegnere il server e non reinstallare subito. Isolalo dalla rete mantenendolo acceso, così da preservare memoria RAM, processi e connessioni. Conserva i log del reverse proxy, di Jpom e di sistema su un supporto separato. Fai eseguire una copia forense prima di ogni bonifica: serve per capire cosa è stato fatto e, se ci sono dati personali coinvolti, per la notifica al Garante prevista dal GDPR. Estendi il controllo ai server gestiti da Jpom, perché l'attaccante poteva raggiungerli con le credenziali salvate. Con il mio studio gestisco incident response con preventivo fisso da 1.500 a 6.000 € e audit di sicurezza da 2.000 a 8.000 €.

Fonti ufficiali

• Advisory VulnCheck su CVE-2026-120201
• Codice del LoginInterceptor in Jpom 2.11.12
• Issue sul repository Jpom
• Repository ufficiale dromara/Jpom

Hai bisogno di una verifica?

Se usi Jpom o un altro strumento di deploy esposto e vuoi sapere se sei a rischio, posso controllare esposizione, log e configurazione e aiutarti a mettere in sicurezza l'infrastruttura. Richiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti.