FortiSandbox CVE-2026-25089: RCE non autenticato nella sandbox che giudica il malware

CISA ha dato alle agenzie federali statunitensi tempo fino a domenica 19 luglio 2026 per correggere due falle di Fortinet FortiSandbox — una finestra di tre giorni che esiste solo perché gli attaccanti sono già dentro il parco installato. Entrambe sono OS command injection non autenticate, valutate CVSS 9.8 su NVD, e Fortinet ha rilasciato le patch già ad aprile e giugno. Il punto interessante non è il ritardo nell'applicazione delle patch. È quale apparato è stato compromesso. FortiSandbox non è un firewall né un concentratore VPN. È l'appliance che il resto del fabric Fortinet interroga prima di decidere se un file è malware. Un'esecuzione di codice remoto sul giudice è un problema di categoria diversa rispetto a una RCE su una guardia.

Che cos'è davvero FortiSandbox

FortiSandbox è una piattaforma di detonazione del malware. FortiGate, FortiMail, FortiWeb, FortiClient e il resto del fabric le inoltrano file e URL sospetti, lei li detona in VM strumentate e restituisce un verdetto — pulito, sospetto, malevolo. Quei verdetti non sono consultivi. Help Net Security lo descrive senza giri di parole: FortiSandbox è "una piattaforma da cui gli altri prodotti di sicurezza Fortinet dipendono per i verdetti sulle minacce, per applicare decisioni di blocco e innescare risposte automatiche". Quando la sandbox dice pulito, il gateway di posta consegna l'allegato. Quando dice malevolo, il firewall scarta il flusso e il SOC riceve un ticket.

È questa architettura la ragione per cui questa CVE conta più di quanto suggerisca il suo numero. La maggior parte delle appliance di frontiera sta davanti alla cosa che ti interessa. La sandbox sta dentro il ciclo decisionale. Compromettila e non stai più aggirando il controllo — sei il controllo.

Le due falle: command injection non autenticata

Entrambe le falle sfruttate attivamente appartengono alla stessa classe di debolezza — CWE-78, OS command injection — raggiungibile senza credenziali e senza interazione dell'utente.

CVE	Tipo	Vettore	CVSS (NVD)	Corretta in	Divulgata
CVE-2026-25089	OS command injection (UI web)	Non autent., HTTP forgiata	9.8 (Fortinet valuta 9.1)	4.4.9 / 5.0.6	9 giu 2026
CVE-2026-39808	OS command injection	Non autent., HTTP forgiata	9.8	4.4.9	14 apr 2026
CVE-2026-39813	Path traversal nella JRPC API	Bypass autenticazione	—	4.4.9 / 5.0.6	giu 2026

CVE-2026-25089 risiede nell'interfaccia web di gestione (advisory Fortinet FG-IR-26-141, attribuita ad Adham El Karn del team di product security di Fortinet). Una richiesta HTTP appositamente costruita inietta in un comando di sistema che l'appliance esegue per conto dell'attaccante. Nessun passaggio di login, nessun prerequisito privilegiato, nessun phishing. La terza falla del cluster, CVE-2026-39813, è un path traversal nella JRPC API di FortiSandbox che permette di bypassare del tutto l'autenticazione — un abbinamento naturale che consente a un intruso di raggiungere funzioni di gestione a cui non avrebbe mai dovuto accedere.

Le versioni interessate sono ampie: FortiSandbox 4.2.0–4.2.8, 4.4.0–4.4.8 e 5.0.0–5.0.5, più le build Cloud e PaaS sulla linea 5.0.4–5.0.5. Se usi FortiSandbox e non lo tocchi dalla primavera, sei quasi certamente su una build vulnerabile.

Corretta ad aprile e giugno. Sfruttata a luglio

La cronologia è la parte scomoda. Fortinet ha corretto CVE-2026-39808 il 14 aprile e CVE-2026-25089 il 9 giugno. Settimane dopo, la società di threat intelligence Defused ha segnalato le falle abusate in the wild attorno al 16 giugno, e Qualys ha tracciato la stessa attività il giorno seguente. Il 16 luglio CISA ha aggiunto entrambe al catalogo Known Exploited Vulnerabilities e, ai sensi della Binding Operational Directive 26-04, ha fissato una scadenza federale di rimedio di tre giorni al 19 luglio.

Rileggi quel divario: la correzione era disponibile da tre mesi per una falla e da un mese per l'altra, e il parco installato è stato comunque colpito. Le security appliance sono l'infrastruttura peggio patchata che la maggior parte delle organizzazioni gestisce, per una ragione prevedibile — sono fidate. Nessuno programma una finestra di manutenzione per riavviare la cosa che dovrebbe vigilare sui problemi. Sta fuori dalla cadenza di patching dei server, spesso sotto gestione del vendor o dell'MSP, spesso con un'eccezione del tipo "non toccarlo, funziona". Il risultato è un parco di 9.8 esposto a internet molto tempo dopo che la patch esisteva.

Il problema dell'oracolo dei verdetti

Ecco cosa compra a un attaccante una RCE sulla sandbox che una RCE su un firewall non offre.

Primo, la manipolazione del verdetto. Se controlli il processo che decide pulito contro malevolo, puoi far tornare pulito il tuo payload. Il gateway di posta che avrebbe messo in quarantena il tuo loader ora lo consegna, perché l'oracolo di cui si fida glielo ha detto. Non hai eluso il livello di rilevamento — lo hai arruolato.

Secondo, il catalogo. Una sandbox di detonazione conserva un registro continuo di tutto ciò che il fabric ha ritenuto sospetto: i campioni, gli URL, le caselle di posta d'origine, i report di detonazione. È una mappa di ciò che le tue difese intercettano e, per inferenza, di ciò che si lasciano sfuggire. Dice a un intruso quali dei suoi strumenti sono già bruciati e quali sono ancora validi.

Terzo, il pivot. La sandbox è cablata nel fabric per progettazione — dialoga con FortiGate, FortiMail e il piano di gestione. Un apparato con così tanta portata est-ovest è un punto di appoggio ideale, ed è uno di quelli che i difensori raramente osservano come origine di traffico, perché il suo mestiere è ricevere.

Controfattuale. Il tuo SOC riceve un verdetto FortiSandbox: allegato X, pulito. Viene consegnato. Tre settimane dopo X è l'accesso iniziale di un caso ransomware. La domanda post-incidente non è "perché la sandbox se l'è fatto sfuggire" — la sandbox non se l'è fatto sfuggire. Le è stato detto cosa rispondere. Su un oracolo compromesso, un verdetto pulito non è prova di nulla.

Nulla di tutto ciò richiede un exploit inedito. Richiede una richiesta HTTP non autenticata verso un apparato rimasto senza patch dalla primavera.

Remediation

FortiSandbox è infrastruttura di gestione. Trattalo come un incidente Tier-0, non come un aggiornamento di routine di un'appliance.

1. Sono interessato? Verifica la build in esecuzione da CLI o dalla dashboard:

diagnose sys version
# oppure, nella GUI: System > FortiSandbox > Firmware

Sei vulnerabile se usi FortiSandbox 4.2.0–4.2.8, 4.4.0–4.4.8 o 5.0.0–5.0.5, oppure FortiSandbox Cloud/PaaS 5.0.4–5.0.5. Poi verifica l'esposizione — l'interfaccia di gestione non dovrebbe mai essere raggiungibile da internet:

# da un punto di osservazione esterno
curl -sk -o /dev/null -w "%{http_code}\n" https://<ip-mgmt-sandbox>/

2. Patch — versioni corrette esatte. Aggiorna a FortiSandbox 4.4.9 o successiva, oppure 5.0.6 o successiva (Cloud e PaaS: 5.0.6+). La 4.4.9 chiude tutte e tre le CVE sul ramo 4.4; la 5.0.6 le chiude sul ramo 5.0. Le build su 4.2.x devono passare a un ramo corretto. Riscontra con FG-IR-26-141 sul PSIRT Fortinet prima di dichiarare chiuso.

3. Non puoi patchare subito? Controlli compensativi.

• Rimuovi immediatamente la UI di gestione/web da qualsiasi interfaccia esposta a internet — limitala a una VLAN di gestione e a un jump host. Non autenticato e raggiungibile in rete è l'intera precondizione; taglia la raggiungibilità e tagli l'attacco.
• Applica ACL rigorose in modo che solo i dispositivi del fabric che devono inviare campioni possano raggiungere le porte del servizio.
• Se non riesci a isolarlo in fretta, spegnere l'apparato è preferibile a lasciare esposta una 9.8 notoriamente sfruttata.

4. Cerca segni di compromissione. La patch non sfratta un intruso arrivato prima della patch. Mappa la caccia su MITRE ATT&CK:

• T1190 — Exploit Public-Facing Application: richieste HTTP anomale o malformate verso la UI web / JRPC API di FortiSandbox nei log dell'appliance, soprattutto con metacaratteri di shell nei parametri.
• T1059 — Command and Scripting Interpreter: processi figli inattesi generati dal servizio web della sandbox; comandi che l'appliance non ha motivo di eseguire.
• T1078 — Valid Accounts / bypass autenticazione (CVE-2026-39813): azioni amministrative senza un evento di login riuscito che le precede.
• T1041 / T1071 — Esfiltrazione e C2: connessioni in uscita originate dall'interfaccia di gestione della sandbox verso destinazioni mai viste. Questo apparato riceve e scarica aggiornamenti; non dovrebbe fare beaconing.
• Manomissione dei verdetti: campioni restituiti puliti che altra telemetria (EDR, log di posta) contraddice in seguito — tratta le discrepanze verdetto/realtà come segnale di compromissione, non come un problema di tuning.

5. Bonifica e verifica. Se trovi un qualsiasi indicatore, presumi la compromissione totale dell'appliance. La command injection significa che è stato eseguito codice arbitrario nel contesto del servizio. Ricostruisci l'appliance da un'immagine nota-buona anziché fidarti di un upgrade in place, ruota ogni credenziale e token API che la sandbox deteneva o poteva raggiungere nel fabric, riesamina i verdetti recenti per qualsiasi cosa un attaccante possa aver ribaltato, e conferma che l'apparato sia pulito dopo la patch — non prima.

Dove si colloca Zero Hunt

Il fallimento ricorrente in questa storia è l'assicurazione basata sull'inventario. "Abbiamo patchato FortiSandbox ad aprile" è un'affermazione su un record di change, non sull'apparato in rete. Il parco colpito aveva quasi certamente la correzione disponibile — semplicemente non era applicata, e nessuno verificava di continuo la differenza.

È questo divario la ragione per cui l'AI generative pentest di Zero Hunt valida per evidenza e non per version banner. Lo sciame di 10 agenti — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report sotto un AI Controller — scrive un tentativo di exploit specifico per il tuo FortiSandbox con un LLM locale, non uno script preconfezionato da ExploitDB, e lo esegue contro l'appliance reale dentro un container effimero irrobustito con gVisor. La risposta che restituisce non è "il tuo CMDB dice 4.4.9". È "la richiesta HTTP forgiata ha raggiunto una shell su questo apparato oppure no", ritestata nell'AI Gym prima di toccare la produzione e firmata ECDSA come finding consegnabile a un auditor. Le sue campagne innescate dai cambiamenti sono fatte esattamente per il problema dell'appliance dimenticata: un asset nuovo o modificato sul perimetro innesca una campagna completa entro un'ora, così la sandbox che nessuno riavvia non marcisce in silenzio in una 9.8 notoriamente sfruttata.

E poiché un intruso che possiede l'oracolo acceca la telemetria stessa del fabric, il motore di AI Traffic Analysis osserva l'unica superficie che la compromissione non può riscrivere: il filo. Il suo modello di deep learning esegue quattro teste di inferenza — traffico sospetto, classificazione malware, tipo di attacco, fingerprint applicativo — a 2,7+ Gbit/s sulla GPU dell'appliance, in locale, senza cloud. Segnala le richieste di command injection forgiate che colpiscono la UI di gestione e, cosa più rivelatrice, le sessioni in uscita che una sandbox di detonazione non dovrebbe mai aprire — il beacon del giudice, mentre accade, non nel digest del SIEM di domani. Quando l'apparato che emette i verdetti non è più affidabile nel riferire su se stesso, la rete è il testimone che dice ancora la verità.

Per l'argomento più ampio sul perché un finding validato batte una stima da inventario, vedi la nostra nota su validazione degli exploit — evidenza contro stima.