L'apparato il cui mestiere è far detonare il malware

Una sandbox esiste per essere attaccata. FortiSandbox si compra perché i file sospetti vengano aperti in un posto che non è la vostra rete, osservati mentre si comportano male e poi giudicati. Per costruzione sta esattamente nel punto in cui arriva ciò di cui non ci si fida. È questo che rende una command injection non autenticata nella sua interfaccia web un problema di categoria diversa rispetto allo stesso bug su un server qualunque.

CVE-2026-25089 è precisamente questo. Riguarda l'interfaccia web di FortiSandbox, FortiSandbox Cloud e FortiSandbox PaaS e consente a un attaccante non autenticato di eseguire comandi non autorizzati tramite richieste HTTP costruite ad arte. Ha un punteggio CVSS di 9.1. Fortinet l'ha divulgata e corretta il 9 giugno 2026.

A metà giugno è iniziato lo sfruttamento, a metà luglio se n'è accorto il catalogo

Lo sfruttamento di tre falle di FortiSandbox è stato osservato in rete nel fine settimana tra il 14 e il 16 giugno, e un monitoraggio indipendente ha registrato lo sfruttamento di CVE-2026-39808 già dal 12 giugno. La stampa specializzata ne ha scritto allora: Help Net Security il 16 giugno, Qualys il giorno seguente, insieme a The Hacker News e SecurityWeek. Due delle tre, CVE-2026-39808 e CVE-2026-39813, erano già state divulgate da Fortinet ad aprile. La terza, CVE-2026-25089, era stata corretta il 9 giugno, pochi giorni prima che gli attacchi iniziassero.

Il 16 luglio 2026 CISA ha pubblicato la versione 2026.07.16 del catalogo aggiungendo tre voci. Due sono le falle di FortiSandbox, CVE-2026-25089 e CVE-2026-39808. La terza è una falla di deserializzazione di Microsoft SharePoint, CVE-2026-58644.

Contate i giorni. Sfruttamento confermato, riportato pubblicamente e reale a metà giugno. Voce nel catalogo federale il 16 luglio. Circa trenta giorni separano le due cose, su un apparato raggiungibile da internet con una falla di esecuzione di codice remoto senza autenticazione, e in quei trenta giorni l'informazione non era segreta. Stava negli avvisi del produttore e sulla stampa specializzata.

La terza manca ancora

In quell'ondata di giugno tre CVE di FortiSandbox sono state segnalate come sfruttate. Due sono state catalogate il 16 luglio. CVE-2026-39813, una falla di path traversal nell'API JRPC di FortiSandbox utilizzabile per aggirare l'autenticazione, non è nel catalogo.

È questa la parte che dovrebbe cambiare il modo in cui il catalogo viene usato, e non soltanto la velocità. Un inserimento nel KEV è un segnale positivo forte: se una cosa è lì dentro viene sfruttata e va affrontata. L'assenza di un inserimento è un segnale molto più debole di quanto la maggior parte dei programmi di patching creda. CVE-2026-39813 è stata segnalata come sfruttata accanto alle due elencate, nella stessa ondata e sulla stessa famiglia di prodotto, e nel catalogo non è entrata. Chi corregge ciò che CISA elenca e rimanda ciò che CISA non elenca ha appena rimandato una falla che gli attaccanti hanno usato a giugno.

Un orologio di tre giorni su una macchina sotto change control

Tutte e tre le voci aggiunte il 16 luglio portano una scadenza di rimedio al 19 luglio 2026. Tre giorni.

Per un operatore europeo la scadenza federale in sé non è vincolante, e viene la tentazione di archiviarla come un dettaglio amministrativo americano. È più utile leggerla come una misura di gravità. Una scadenza a tre giorni è il modo in cui il catalogo dice che non si aspetta che aspettiate la prossima finestra. La parte scomoda è lo scontro con la realtà: un'appliance sandbox sta sotto change control proprio perché ispeziona traffico di produzione, e tre giorni non sono una finestra di cambiamento nella maggior parte delle organizzazioni. Questa tensione è il vero problema operativo, e non si risolve leggendo la scadenza con più attenzione.

Sotto NIS2 l'esposizione non è la scadenza americana ma l'ordinario dovere di diligenza, e una falla di esecuzione di codice remoto senza autenticazione su un apparato di sicurezza, sfruttata in rete per un mese con la patch del produttore disponibile, è difficile da spiegare come rischio accettato.

Ricablate l'innesco

L'indicazione è piccola e precisa. Se il vostro processo sulle vulnerabilità parte quando qualcosa compare nel KEV, parte con circa un mese di ritardo e si perde per strada interi elementi. Non è una critica al catalogo, che fa quello che dichiara: registra ciò che è noto come sfruttato, quando le prove raggiungono la soglia. È una critica all'uso di un feed di conferma come sistema di allerta precoce.

Fate tre cose. Abbonatevi direttamente ai feed di avvisi PSIRT di ogni produttore le cui appliance terminano traffico non fidato, perché Fortinet ha pubblicato a giugno mentre il catalogo parlava a luglio. Date agli apparati di sicurezza esposti a internet una corsia di patching propria con un orologio più corto rispetto all'infrastruttura generale, dato che sono insieme gli asset più esposti e i più vincolati dal change control che possedete. E verificate il vostro parco FortiSandbox contro tutte e tre le CVE di giugno, non contro le due catalogate.

Da leggere ora: 430.000 firewall come linea di rifornimento ransomware  |  Un token falso apre ogni PC che lo strumento gestisce