Check Point CVE-2026-123039: root via DynamicCLI, sfruttata in attacchi distruttivi ai gateway

Check Point ha rilasciato hotfix d'emergenza per CVE-2026-123039, una local privilege escalation di Gaia OS che consegna root su un firewall, un management server o un orchestratore Maestro. Da sola è un bug locale — serve prima l'esecuzione di codice sull'apparato. Sul campo da sola non era: gli attaccanti sono entrati dal portale Mobile Access con le falle PHP2Shell, hanno usato questa per diventare root e poi hanno cancellato un host di virtualizzazione. CISA l'ha inserita nel catalogo Known Exploited Vulnerabilities lo stesso giorno, con scadenza federale di tre giorni e obbligo di triage forense.

Notizia in evoluzione — pubblicata alle 19:50 (18:50 UTC) del 13 novembre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-123039
Prodotto / versioni colpite	Check Point Gaia OS — Security Gateway (firewall "Force"), Management e Log Server, Multi-Domain Security Management e Log Server, Maestro Orchestrator; Gaia R82.20, R82.10, R82, R81.20 e le end-of-support R81.10 / R81. Non colpiti · firewall Spark, Smart-1 Cloud
Corretta in	Jumbo Hotfix Accumulator — R82.20 da Take 14 · R82.10 da Take 52 · R82 da Take 132 · R81.20 da Take 174. Nessuna correzione per le end-of-support R81.10 / R81
CVSS	7.8 HIGH · CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H · assegnato da Check Point (CNA); NVD in stato "Awaiting Analysis", non ancora valutato
Sfruttata attivamente	Sì — Check Point ha osservato sfruttamento attivo contro "un paio di dozzine" di clienti; ondata distruttiva dal 30 ottobre 2026
CISA KEV	Aggiunta 2026-11-13; scadenza federale 2026-11-16 (BOD 26-04, triage forense richiesto)
PoC pubblico	Nessuno pubblico al 2026-11-13
Advisory ufficiale	Check Point sk1000362

Che cos'è davvero CVE-2026-123039

Gaia OS esegue un demone, dynamic_server, che sta dietro all'interfaccia DynamicCLI. Gira come root e ascolta su un socket Unix locale, /tmp/dynamic_socket. Il socket viene creato scrivibile da tutti — permessi 0777 — e il demone non autentica il processo che si connette. Qualunque utente locale che raggiunge quel socket può inviare un comando e farlo eseguire come root. Il bug è tutto qui: una coppia classica di assegnazione errata dei permessi e autorizzazione mancante (CWE-732 e CWE-862), valutata 7.8 da Check Point come CNA, secondo il record NVD.

Poiché il vettore è locale (AV:L) e richiede un utente autenticato (PR:L), da sola non è una porta esposta su internet. È il secondo piolo di una scala. E negli attacchi descritti da Check Point il primo piolo era già al suo posto.

La catena: da PHP2Shell a root al wiper

Secondo SecurityWeek (Ionut Arghire, 13 novembre) e BleepingComputer (Sergiu Gatlan, 13 novembre), entrambi che riportano la ricerca di Check Point, l'operazione si è svolta così:

• Accesso iniziale tramite PHP2Shell — la coppia di RCE sull'interprete PHP CVE-2026-109618 e CVE-2026-109619, corrette il 21 ottobre, di cui abbiamo scritto nella nostra analisi di PHP2Shell. Il punto d'ingresso era il portale Mobile Access del gateway.
• Escalation dei privilegi a root con CVE-2026-123039.
• Persistenza: webshell PHP piazzate in una directory che il portale Mobile Access usa per costruire le pagine di login, poi il backdoor TSGA e TSProxy — varianti del framework PhiliKit già visto nelle intrusioni di UNC5221 (collegata alla Cina) contro gli apparati Ivanti.
• Impatto: ricognizione degli asset interni, movimento laterale verso un host VMware ESXi e un wiper eseguito su di esso.

Un apparato comprato per stare sul bordo e osservare la rete è diventato il punto di lancio per distruggere un host di virtualizzazione dietro di esso. La stringa di versione sulla scatola diceva quale Take stavi eseguendo. Non diceva che un wiper era già pronto due salti più in là.

Check Point distingue due ondate: una distruttiva dal 30 ottobre contro organizzazioni israeliane, e una seconda dal 2 novembre in diversi Paesi senza attività distruttiva osservata. Dichiara di non poter attribuire la campagna con certezza — l'attaccante operava nel tipico orario lavorativo cinese, ma il wiper e la distruzione "non si allineano con le note operazioni cyber cinesi", lasciando aperta la lettura di un initial-access broker o di una false flag.

Remediation

1. Sono esposto?

In Clish, verifica la versione Gaia (show version all) e la Jumbo Hotfix Accumulator Take installata, poi confronta con le Take corrette sotto. In Expert mode, controlla se il demone vulnerabile è presente e in esecuzione — questo comando è dall'advisory:

ps auxw | grep -v grep | grep 'dynamic_server'

I firewall Spark e Smart-1 Cloud non sono colpiti. R81.10 e R81 sono end-of-support e non hanno correzione.

2. Patch — le Take corrette esatte

Installa la Jumbo Hotfix Accumulator alla Take indicata o superiore per il tuo ramo (da sk1000362):

Ramo Gaia	Corretta da
R82.20	Take 14
R82.10	Take 52
R82	Take 132
R81.20	Take 174
R81.10 / R81 (EOS)	Nessuna correzione — migra a un ramo supportato

3. Non puoi applicare la patch ora? Controlli compensativi

Il ripiego dell'advisory è fermare il processo dynamic_server e impedirne il riavvio tramite i comandi dbset documentati — tieni presente che questo disabilita le funzioni Dynamic CLI descritte in sk144112, quindi valuta il costo operativo. Usa i comandi esatti come pubblicati in sk1000362.

Il punto più importante: questa escalation scatta solo dopo che un attaccante ha già esecuzione di codice locale. Nella campagna osservata è arrivata da PHP2Shell sul portale Mobile Access. Chiudere quella porta è di per sé un controllo compensativo — verifica che la patch PHP2Shell (CVE-2026-109618 / CVE-2026-109619) sia applicata e limita l'esposizione del portale Mobile Access e delle interfacce di gestione alle sole reti che ne hanno davvero bisogno.

4. Cerca segni di compromissione

KEV marca questa voce come triage-forense-richiesto, cioè assumi la compromissione finché i log non dicono il contrario. Il demone registra ogni comando ricevuto in /var/log/dynamicCli.log. Le richieste legittime portano un wrapper Clish fisso; tutto il resto è sospetto. Le query di rilevamento di Check Point stesso:

grep "Received =" /var/log/dynamicCli.log \
  | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"
grep -F "Received = #return_value#" /var/log/dynamicCli.log
grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" /var/log/dynamicCli.log

Oltre al socket: webshell nella directory delle pagine di login di Mobile Access, gli impianti TSGA / TSProxy, connessioni inattese dal gateway verso ESXi e l'intero set di IOC pubblicato da Check Point con la ricerca. Mappatura su MITRE ATT&CK: T1190 (exploit di applicazione esposta — PHP2Shell), T1068 (exploit per privilege escalation — questa CVE), T1505.003 (web shell), T1021 (movimento laterale), T1041/T1071 (C2 sul canale TSProxy), T1485 (distruzione dei dati — il wiper).

5. Bonifica e verifica

Dove la ricerca trova riscontri, la patch non basta — sono stati installati persistenza e un backdoor, quindi ricostruisci l'apparato colpito da supporto integro, rimuovi webshell e impianti e ruota ogni credenziale e chiave che la macchina conteneva (admin, SIC, API, qualunque segreto raggiungibile da root). Dopo la patch, verifica che il socket non sia più scrivibile da tutti — deve mostrare srw-rw---- root config (0660), non 0777 — e che i tentativi di escalation bloccati compaiano ora come righe Rejected connection from unauthorized uid in dynamicCli.log. Verifica la correzione rieseguendo la catena contro l'apparato, non leggendo la stringa di versione.

Cosa non si sa ancora

• Punteggio e analisi NVD. NVD elenca ancora il record come "Awaiting Analysis"; il 7.8 è il punteggio di Check Point. NVD potrebbe modificarlo.
• Date di rilascio degli hotfix. L'advisory indica le Take corrette ma non pubblica i loro timestamp di rilascio; verifica che la Take che installi sia aggiornata.
• Attribuzione. Check Point rinuncia esplicitamente a una valutazione ad alta confidenza. La sovrapposizione con l'orario lavorativo punta da una parte, il wiper dall'altra.
• Perimetro reale. "Un paio di dozzine di clienti" è il conteggio di sfruttamento osservato da Check Point, non un tetto. L'obbligo di triage forense esiste proprio perché le vittime silenziose non hanno ancora tutte segnalato.

Dove lascia i difensori

La domanda onesta che un operatore Check Point si fa stasera non è "su quale Take sono" — è "qualcuno potrebbe davvero passare dal mio portale Mobile Access a root su questa scatola e poi al mio ESXi". Uno scan di versione risponde alla prima e schiva la seconda. L'unica risposta alla seconda è eseguire la catena.

È ciò che fa un red team autonomo con AI, ed è il caso primario per cui Zero Hunt è costruito. Lo sciame di 10 agenti riproduce esattamente questo percorso — un agente Web ed Exploit conquista il foothold, un agente Post-Exploit guida l'escalation locale, un agente Pivot verifica il raggio dal gateway verso lo strato di virtualizzazione — contro il tuo apparato, in gray-box, con ogni exploit eseguito in un container effimero rinforzato che non tocca mai l'host dell'apparato. Gira on-premise su modelli privati, quindi puntare il motore su un firewall che custodisce SIC e credenziali di gestione non le invia mai a terzi, e un umano approva ogni azione che conta. Ti dice se la tua R81.20 su Take 170 è portabile a root, non solo che è sotto la Take 174. Per la decisione "patch, o fermo il demone, e in che ordine", l'AI Remediation Advisor ordina per sfruttabilità reale — prima CISA KEV, poi ciò che la campagna ha davvero dimostrato raggiungibile — e riverifica la correzione con la stessa prova che aveva dimostrato il buco.

E la parte che la stringa di versione non ha mai mostrato — il wiper pronto due salti più in là — è un problema di traffico. Un paio di dozzine di clienti hanno tenuto gateway compromessi per circa due settimane. Il movimento laterale verso ESXi, il canale TSProxy, lo staging prima della cancellazione: tutto questo è rumoroso sul filo. Il modello di analisi del traffico di Zero Hunt, con quattro teste di inferenza sulla GPU dell'apparato, fa da baseline a ciò con cui un gateway parla normalmente e segnala il firewall che si allunga verso un host ESXi che non ha motivo di toccare — mentre accade, non nel digest SIEM del mattino dopo.

CVE-2026-123039 è un orologio KEV di tre giorni. Se gestisci gateway Check Point, il runbook completo di patch-e-caccia qui sopra, la nostra analisi di PHP2Shell e la guida al patching basato sul rischio BOD 26-04 sono il punto di partenza; se stai decidendo come validare gli apparati di bordo in continuo anziché una volta l'anno, vedi la nostra guida al penetration test automatizzato. Domande sulla validazione del tuo parco: scrivici.