Threat feed attivoAggiornato — 24.07.2026 09:37 CET30 dossierMappatura MITRE ATT&CKThreat feed attivoAggiornato — 24.07.2026 09:37 CET30 dossierMappatura MITRE ATT&CK

Non attribuito (nessuna campagna pubblica; sfruttamento segnalato da CISA)critical

La scatola che esegue malware, eseguita da chi bussa: due RCE su FortiSandbox

FortiSandbox è la scatola dove i file sospetti vengono fatti esplodere in sicurezza. Due vulnerabilità di OS command injection senza autenticazione — una nella WEB UI, una in un endpoint API — permettono a chiunque di eseguire comandi sull'appliance stessa. Patchate in silenzio ad aprile e giugno con la dicitura «Known Exploited: No», sono state aggiunte entrambe al catalogo CISA KEV il 16 luglio: segnale che qualcuno ha iniziato a usarle, con la patch già vecchia di mesi.

Il paradosso al centro del dispositivo

Un sandbox di rete come FortiSandbox esiste per una ragione precisa: essere il posto dove le cose pericolose possono succedere senza fare danni. FortiGate, FortiMail e gli altri componenti del Security Fabric gli passano i file e gli URL sospetti; lui li fa detonare dentro macchine virtuali isolate, osserva cosa combinano e restituisce un verdetto. È, per progetto, la stanza blindata in cui si accende la miccia.

Il 16 luglio 2026 CISA ha aggiunto al suo catalogo delle vulnerabilità note come sfruttate due falle di FortiSandbox. Nessuna delle due riguarda la stanza blindata. Riguardano la porta d'ingresso: entrambe permettono a un attaccante non autenticato di eseguire comandi di sistema sull'appliance stessa, con una semplice richiesta HTTP. La scatola costruita per eseguire in sicurezza il codice altrui può essere fatta eseguire da chiunque bussi.

  1. 14 aprile 2026
    FG-IR-26-100

    Fortinet pubblica CVE-2026-39808: OS command injection su un endpoint API.

  2. 9 giugno 2026
    FG-IR-26-141

    Fortinet pubblica CVE-2026-25089: injection nella WEB UI, funzione «start vnc».

  3. 16 luglio 2026
    exploitation

    CISA aggiunge entrambe le CVE al catalogo KEV.

  4. 19 luglio 2026
    Scadenza

    Data limite per la remediation imposta da CISA alle agenzie federali.

Due porte, stessa stanza

Le due vulnerabilità sono varianti dello stesso difetto — CWE-78, improper neutralization of special elements used in an OS command — su due superfici diverse.

CVE-2026-39808 (FG-IR-26-100), pubblicata il 14 aprile e segnalata da Samuel de Lucas Maroto di KPMG Spagna, vive in un endpoint API: una richiesta HTTP costruita ad arte porta all'esecuzione di comandi. Colpisce FortiSandbox 4.4.0–4.4.8; il ramo 5.0 non è affetto.

CVE-2026-25089 (FG-IR-26-141), pubblicata il 9 giugno e trovata internamente da Fortinet, è più insidiosa: è una injection di secondo ordine che passa da un input JSON della funzione «start vnc» nella WEB UI. «Secondo ordine» significa che il valore ostile non viene eseguito nel momento in cui entra, ma più tardi, quando l'applicazione lo riusa in un contesto dove diventa comando. Copre più prodotti: FortiSandbox 5.0.0–5.0.5, 4.4.0–4.4.8, oltre a FortiSandbox Cloud e PaaS 5.0.4–5.0.5.

In entrambi i casi l'attaccante non ha bisogno di credenziali. È il punto che rende queste falle da massima priorità: nessun login, nessun token, nessun utente — solo la capacità di raggiungere via rete l'interfaccia di gestione o l'API.

  1. 01
    Richiesta HTTP
    l'attaccante raggiunge WEB UI o endpoint API, senza autenticarsi
  2. 02
    Input non neutralizzato
    JSON di «start vnc» (25089) o parametro API (39808)
  3. 03
    OS command injection
    i caratteri speciali finiscono in un comando di sistema
  4. 04
    Esecuzione sull'appliance
    il codice gira sul sandbox, non nella VM isolata

Perché un sandbox è un bersaglio peggiore di un firewall

Un'appliance di detonazione non è un dispositivo qualsiasi da compromettere. Per fare il suo lavoro riceve, da tutto il resto del Security Fabric, i file e gli URL che nessun altro si fida di aprire: allegati di posta, campioni scaricati, payload segnalati. Sta in una posizione fidata e vede materiale che, per definizione, è già sospetto.

Chi ottiene esecuzione di comandi su quel dispositivo eredita quella posizione. Può leggere i campioni in coda e i verdetti già emessi; può, in linea di principio, manipolare i verdetti — insegnare al sandbox a dire «pulito» su ciò che pulito non è, trasformando lo strumento di difesa in un lasciapassare; può usarlo come testa di ponte verso i componenti del Fabric che si fidano di lui. Non è un semplice RCE su un box perimetrale: è un RCE sul dispositivo a cui gli altri delegano il giudizio su cosa è pericoloso.

9.8
CVSS 3.1 (CNA Fortinet)
«Critical»; la metrica dell'advisory riporta 9.1
2
CVE distinte in KEV
aggiunte lo stesso giorno, 16 luglio 2026
0
credenziali necessarie
entrambe le falle sono pre-autenticazione

Cosa non sappiamo — e va detto

Diverse cose, ed è giusto dichiararle.

La più importante: al momento della pubblicazione, entrambi gli advisory Fortinet riportano «Known Exploited: No». Fortinet le ha discusse come scoperte interne o disclosure responsabili, senza segnalare sfruttamento. È l'inserimento nel catalogo KEV del 16 luglio a dire il contrario: CISA aggiunge una CVE a KEV solo con evidenza di sfruttamento attivo. Le due fonti non sono in contraddizione — descrivono momenti diversi — ma non esiste, a oggi, un report pubblico di un vendor o di un ricercatore che descriva la campagna, l'attore o gli indicatori. Sappiamo che qualcuno le sta usando; non sappiamo chi, come, né contro chi.

Seconda incertezza: il punteggio. NVD segna entrambe le CVE come Awaiting Enrichment e non ha ancora assegnato un proprio base score; l'unico presente è quello del CNA (Fortinet). E i due valori Fortinet non coincidono — 9.8 nel record CNA di NVD, 9.1 nella metrica in testa all'advisory. Abbiamo riportato entrambi.

Terza: il meccanismo tecnico. Non esiste un exploit pubblico né un'analisi dettagliata; la descrizione qui sopra segue i titoli e le sintesi degli advisory (injection di secondo ordine via JSON in «start vnc»; injection su un endpoint API) e non entra in dettagli operativi che non serve conoscere per difendersi.

Infine gli ID ATT&CK in testa a questo dossier — T1190 e T1059 — non provengono dagli advisory, che non li riportano: sono una mappatura ragionata di ciò che le falle consentono (raggiungere un'applicazione esposta ed eseguire comandi), non un dato copiato da una fonte primaria.

Cosa si fa, e subito

La remediation è netta perché la patch esiste da mesi. Aggiornare FortiSandbox e FortiSandbox Cloud/PaaS a 4.4.9 o 5.0.6 e superiori chiude entrambe le falle. Chi è ancora su 4.4.0–4.4.8 è esposto a tutt'e due; chi è su 5.0.0–5.0.5 alla injection della WEB UI.

Nell'attesa della finestra di manutenzione, la mitigazione a impatto più alto è la più semplice: la WEB UI e l'API di gestione di un sandbox non dovrebbero essere raggiungibili da internet, né esposte oltre la rete di amministrazione. Un dispositivo che riceve input solo dagli altri componenti del Fabric non ha ragione di offrire la propria interfaccia al mondo.

Per la caccia retrospettiva, in assenza di IOC pubblici, l'indicatore è il comportamento: richieste inattese verso l'interfaccia o l'API di FortiSandbox da sorgenti esterne, processi anomali sull'appliance, modifiche alla configurazione o account comparsi fuori dai flussi previsti. La data che conta è il 16 luglio, ma la falla aspettava dal 14 aprile: chi ha guardato solo il calendario delle patch, e non la propria esposizione, ha avuto tre mesi di finestra aperta senza saperlo.

Altri dossier