Un’altra appliance di sicurezza perimetrale finisce nel mirino degli attaccanti, e stavolta il bersaglio è il cuore della posta elettronica aziendale. Il 1° ottobre 2026 Fortinet ha reso pubblico un avviso su una falla critica in FortiMail, la piattaforma di secure email gateway usata da migliaia di organizzazioni in Europa per filtrare phishing, malware e spam in transito. Nel giro di 24-48 ore la vulnerabilità, classificata CVE-2026-104286 con un punteggio CVSS di 9,8 su 10, è finita nel catalogo Known Exploited Vulnerabilities (KEV) della Cybersecurity and Infrastructure Security Agency (CISA) statunitense. Per le agenzie federali USA la scadenza per applicare la patch è fissata al 4 ottobre 2026, appena tre giorni dopo la pubblicazione dell’advisory ufficiale. Per tutti gli altri, Italia compresa, il countdown è iniziato comunque: la storia recente di Fortinet insegna che gli zero-day sulle sue appliance raramente restano un caso isolato.
Cosa sta succedendo davvero con CVE-2026-104286
Il bollettino tecnico descrive una falla che permette a un attaccante non autenticato di scrivere file arbitrari sul sistema sottostante di FortiMail attraverso richieste HTTP o HTTPS costruite ad arte. Non serve un account valido, non serve interazione dell’utente: basta che l’interfaccia web dell’appliance sia raggiungibile da internet. Il problema nasce dalla combinazione di due debolezze classificate separatamente nel sistema CWE: la numero 22, relativa al path traversal, e la numero 158, legata alla gestione scorretta dei caratteri NULL. Prese singolarmente sono difetti noti da vent’anni. Insieme, su un apparato che processa migliaia di allegati e intestazioni email al giorno, diventano una porta d’ingresso diretta.
Fortinet, secondo quanto riportato dall’advisory, ha scoperto il problema internamente. Questo però non significa che l’azienda abbia preceduto gli attaccanti: CISA inserisce una voce nel catalogo KEV solo quando dispone di prove di sfruttamento attivo, quindi è ragionevole pensare che qualcuno stesse già usando la falla prima della divulgazione pubblica. Testate come The Hacker News hanno ripreso la notizia nelle stesse ore, segnalando la gravità della combinazione tra assenza di autenticazione e scrittura di file sul filesystem.
L’anatomia tecnica: path traversal più byte NULL
Per capire perché questa combinazione è pericolosa bisogna tornare a come funzionano i parser scritti in C, il linguaggio su cui si basano ancora molte appliance di rete. Una richiesta HTTP che punta a un percorso tipo ../../../etc/cron.d/task viene normalmente bloccata da un controllo che rifiuta sequenze “punto-punto-slash”. Se però l’attaccante inserisce un byte NULL (%00) dopo l’estensione attesa, alcune routine di validazione interrompono la lettura della stringa proprio in quel punto, giudicano il percorso innocuo, mentre il livello sottostante del sistema operativo continua a processare l’intera stringa, incluso il tentativo di uscita dalla directory consentita.
POST /upload HTTP/1.1
Host: fortimail.esempio-aziendale.it
Content-Type: multipart/form-data
filename=../../../../opt/fortinet/fortimail/bin/scheduled%00.png
[contenuto del file caricato]L’esempio sopra è puramente illustrativo della classe di vulnerabilità, non un exploit funzionante contro CVE-2026-104286: Fortinet non ha pubblicato dettagli sull’endpoint specifico né sul parametro vulnerabile, e questo articolo non intende colmare quella lacuna. Il punto per i team di sicurezza è un altro: una scrittura di file arbitraria su un’appliance che gestisce la posta può tradursi in un webshell, in un cron job malevolo o in una modifica alla configurazione di instradamento della posta, a seconda di dove finisce il file scritto. L’OWASP Top 10 colloca da anni il controllo degli accessi rotto proprio ai primi posti delle categorie di rischio più sfruttate, e questo caso ne è un esempio da manuale applicato a un’appliance invece che a una web app tradizionale.
Quali versioni di FortiMail sono a rischio
Secondo i dati pubblicati dal National Vulnerability Database e ripresi da diverse analisi indipendenti, la falla coinvolge quattro rami di sviluppo di FortiMail, dalla serie 7.2 fino alla neonata serie 8.0. Chi gestisce un’infrastruttura di posta aziendale dovrebbe controllare subito la build installata e confrontarla con questo schema.
| Ramo FortiMail | Versioni coinvolte | CVSS | Azione raccomandata |
|---|---|---|---|
| 8.0 | 8.0.0 – 8.0.1 | 9,8 | Verificare l’advisory Fortinet per la build corretta più recente |
| 7.6 | 7.6.0 – 7.6.6 | 9,8 | Aggiornare alla release indicata dal PSIRT Fortinet |
| 7.4 | 7.4.0 – 7.4.8 | 9,8 | Aggiornare alla release indicata dal PSIRT Fortinet |
| 7.2 | 7.2.0 – 7.2.9 | 9,8 | Aggiornare o isolare l’interfaccia di amministrazione |
Un dettaglio che merita attenzione: alcune fonti secondarie indicano “8.0.1 o successiva” come versione corretta, ma questo è in contraddizione con il fatto che la 8.0.1 compaia tra le versioni affette. Prima di considerarsi al sicuro, ogni amministratore dovrebbe consultare direttamente l’avviso PSIRT di Fortinet e confrontare il build number esatto, non fidarsi di un numero di versione letto su un articolo di terze parti, compreso questo.
La cronologia dei fatti, ora per ora
| Data | Evento |
|---|---|
| 1 ottobre 2026 | Fortinet pubblica l’advisory PSIRT per CVE-2026-104286 |
| 1-2 ottobre 2026 | CISA inserisce la CVE nel catalogo Known Exploited Vulnerabilities |
| 2 ottobre 2026 | The Hacker News e altre testate di settore riprendono la notizia |
| 3 ottobre 2026 | Nessun attore è stato pubblicamente attribuito, nessun conteggio ufficiale delle vittime |
| 4 ottobre 2026 | Scadenza per la messa in sicurezza da parte delle agenzie federali USA |
Tre giorni tra advisory e scadenza federale sono pochi, ma non un’eccezione: è lo standard che CISA applica alle vulnerabilità già sfruttate attivamente, a differenza delle finestre più lunghe riservate a falle non ancora armate. Lo stesso schema si era visto pochi mesi fa con il caso SharePoint, finito in KEV in appena tre giorni dalla divulgazione.
CISA, il catalogo KEV e la direttiva BOD 26-04
Il catalogo KEV non è un semplice elenco di CVE gravi. È lo strumento con cui CISA obbliga, tramite la Binding Operational Directive in vigore (indicata dalle fonti come BOD 26-04), tutte le agenzie del ramo esecutivo civile statunitense a correggere entro una scadenza vincolante le falle per cui esiste evidenza di sfruttamento reale, non teorico. Per i governi e le aziende fuori dagli Stati Uniti la direttiva non ha valore legale diretto, ma negli ultimi anni è diventata lo standard di fatto anche per i CSIRT europei e per molti framework di gestione del rischio, compresi quelli che le aziende italiane devono rispettare sotto NIS2. In pratica: se una falla finisce in KEV, qualsiasi analista di sicurezza europeo la tratta come priorità operativa indipendentemente dalla giurisdizione.
Vale la pena ricordare che l’obbligo copre solo le agenzie federali civili USA, non le aziende private, non i governi statali o locali, e non le forze armate. Questo lascia ai team di sicurezza europei un margine di interpretazione: la scadenza del 4 ottobre non è legalmente vincolante per un’azienda di Milano o di Monaco, ma ignorarla significa correre un rischio che altri, con un obbligo di legge alle spalle, stanno già eliminando.
Chi sta sfruttando la falla, e i tanti punti ancora oscuri
Qui arriva la parte più scomoda di questa storia: a tre giorni dalla divulgazione, mancano quasi tutti i dettagli che normalmente accompagnano un caso di questa portata. Non esiste un gruppo di minacce pubblicamente attribuito, non c’è un numero ufficiale di dispositivi compromessi, non ci sono cifre verificate su quante istanze FortiMail esposte su internet siano effettivamente vulnerabili rispetto a quelle semplicemente raggiungibili. I ricercatori di watchTowr e runZero hanno pubblicato analisi sulle versioni interessate, ma senza arrivare a un conteggio globale delle installazioni a rischio.
Questa scarsità di dati pubblici non è un dettaglio secondario per chi scrive di sicurezza: significa che ogni cifra sull’impatto reale circolata finora va presa con cautela, perché un servizio web rilevato da una scansione di massa non prova automaticamente che quell’istanza esegua ancora una versione vulnerabile di FortiMail, né che sia già stata compromessa. Fino a quando Fortinet o CISA non pubblicheranno indicatori di compromissione più dettagliati, il consiglio pratico resta uno solo: trattare ogni installazione nelle fasce di versione indicate come potenzialmente a rischio, punto.
Il precedente: la storia recente degli zero-day Fortinet
CVE-2026-104286 non arriva da sola nella storia dell’azienda californiana. Negli ultimi quattro anni Fortinet ha dovuto gestire almeno due episodi paragonabili per gravità, entrambi sulla sua piattaforma SSL-VPN, non sulla posta elettronica. Il confronto aiuta a capire se si tratti di un incidente isolato o di uno schema ricorrente.
| CVE | Anno | Prodotto | CVSS | Tipo di difetto |
|---|---|---|---|---|
| CVE-2026-104286 | 2026 | FortiMail | 9,8 | Path traversal + byte NULL, scrittura file arbitraria |
| CVE-2023-27997 (“XORtigate”) | 2023 | FortiOS / FortiProxy SSL-VPN | 9,2 | Buffer overflow in heap, esecuzione di codice remoto |
| CVE-2022-42475 | 2022 | FortiOS / FortiProxy SSL-VPN | 9,3 (fonte Fortinet) | Buffer overflow in heap, esecuzione di codice remoto |
2023: XORtigate e CVE-2023-27997
Soprannominata XORtigate dai ricercatori che l’hanno analizzata, questa falla ha colpito il modulo SSL-VPN di FortiOS e FortiProxy con un buffer overflow in heap sfruttabile da remoto. Gli attacchi documentati hanno preso di mira enti governativi, aziende manifatturiere e operatori di infrastrutture critiche, con un pattern di sfruttamento limitato ma mirato, non di massa.
2022: il bug sfruttato da un attore legato alla Cina
CVE-2022-42475 condivide con XORtigate la stessa classe di difetto, un buffer overflow in heap nel medesimo componente SSL-VPN, ed è stata associata nel tempo a un attore di minaccia con legami riportati verso la Cina. Il punto in comune con il caso attuale non è la tecnica, ma il bersaglio di sempre: un componente perimetrale, raggiungibile da internet 24 ore su 24, con privilegi elevati sul sistema sottostante.
Fortinet contro la concorrenza nel mercato dei secure email gateway
FortiMail compete in un mercato affollato, dove le alternative principali sono Cisco Secure Email, Proofpoint, Barracuda Email Security Gateway e le soluzioni cloud-native come Microsoft Defender for Office 365. Ogni fornitore ha attraversato almeno un incidente di sicurezza significativo negli ultimi anni: Barracuda, per esempio, ha vissuto nel 2023 uno scenario tanto grave da costringere l’azienda a raccomandare ai clienti la sostituzione fisica dell’hardware compromesso, non bastando il solo aggiornamento software. Nessuno di questi vendor può quindi rivendicare un vantaggio competitivo basato sull’assenza di vulnerabilità gravi.
La differenza che conta per un responsabile IT non è “quale vendor non ha mai avuto un bug”, perché quella lista è vuota per tutti i grandi player del settore. La differenza sta nella velocità e nella trasparenza della risposta: quanto tempo passa tra la scoperta e l’advisory pubblico, quanto è dettagliata l’informazione fornita ai clienti, e se il fornitore offre strumenti di rilevamento della compromissione oltre alla semplice patch. Su questo fronte, l’advisory di Fortinet per CVE-2026-104286 arriva rapido ma resta avaro di dettagli sugli indicatori di compromissione, un’area dove i clienti dovranno probabilmente attendere aggiornamenti successivi.
L’impatto economico e operativo per le aziende europee
Un’appliance di posta compromessa non è un problema isolato di un singolo server. FortiMail siede nel punto di snodo di ogni comunicazione aziendale in entrata e in uscita, il che lo rende un bersaglio ideale per chi vuole intercettare fatture, contratti o comunicazioni riservate, oppure lanciare campagne di business email compromise usando l’infrastruttura legittima dell’azienda colpita come trampolino. Per i team di sicurezza, questo significa che una patch da sola non chiude il cerchio: serve una verifica forense su log, configurazioni di instradamento e regole di inoltro, prima di dichiarare l’incidente concluso.
Sul piano dei costi, ogni ora di fermo di un gateway di posta aziendale si traduce in email bloccate, ticket di supporto e, nei casi peggiori, in comunicazioni commerciali perse durante la finestra di aggiornamento. A questo si aggiunge il costo, spesso sottovalutato, delle ore di analisi forense necessarie per escludere una compromissione pregressa su un sistema che per settimane o mesi potrebbe essere stato esposto a una falla non ancora nota pubblicamente.
Perché le appliance di posta sono diventate il bersaglio preferito
Negli ultimi anni le aziende hanno investito pesantemente in strumenti di rilevamento sugli endpoint, rendendo più difficile per un attaccante muoversi indisturbato su un laptop o un server applicativo monitorato. Il risultato collaterale è uno spostamento dell’attenzione verso ciò che resta meno osservato: le appliance perimetrali, VPN, firewall, gateway di posta, che spesso eseguono codice proprietario, raramente vengono sottoposte a scansioni interne approfondite, e restano comunque raggiungibili da internet senza interruzioni. Lo stesso schema si è visto quest’anno con i due zero-day su Citrix NetScaler, e in generale con l’aumento costante di voci riferite a dispositivi di rete nel catalogo KEV di quest’anno.
Il paradosso è che più le aziende si difendono bene sul fronte endpoint, più diventa attraente un’appliance di rete poco monitorata ma dotata di privilegi di sistema elevati. FortiMail, come molte soluzioni simili, gira tipicamente con permessi ampi perché deve poter scrivere log, mettere in quarantena allegati e modificare configurazioni di instradamento in autonomia: esattamente il tipo di privilegio che un bug di scrittura file arbitraria trasforma in un problema sistemico.
Cosa devono fare subito i team IT e di sicurezza
Le priorità operative, in ordine, dovrebbero essere queste:
- Verificare la build esatta installata su ogni istanza FortiMail e confrontarla con i rami 7.2, 7.4, 7.6 e 8.0 indicati come vulnerabili
- Applicare l’aggiornamento indicato nell’advisory PSIRT Fortinet non appena disponibile per il proprio ramo di versione
- Limitare l’accesso all’interfaccia di amministrazione e web alle sole reti di gestione fidate, rimuovendo l’esposizione diretta a internet dove non strettamente necessaria
- Analizzare i log per richieste HTTP o HTTPS con sequenze di path traversal o caratteri NULL codificati, creazioni di file anomale, modifiche di configurazione non programmate
- Trattare ogni evidenza di sfruttamento come potenziale compromissione completa, non come un semplice evento da patchare e archiviare
Strumenti di monitoraggio come i SIEM, inclusi quelli open source descritti nella nostra guida su Wazuh per l’incident response, possono aiutare a correlare rapidamente i log di FortiMail con altri segnali di compromissione sulla rete, soprattutto se configurati per cercare specificamente pattern di traversal nei log HTTP.
Oltre la patch: bonifica forense e rotazione delle credenziali
Un errore comune dopo una vulnerabilità di questo tipo è considerare l’incidente chiuso una volta installata la patch. Una falla di scrittura file arbitraria può aver lasciato dietro di sé una backdoor, un cron job malevolo o una modifica di configurazione che sopravvive all’aggiornamento stesso, perché agisce a un livello diverso dal codice che viene sostituito dalla patch. Chi gestisce un’istanza FortiMail in uno dei rami vulnerabili dovrebbe, prima di dichiarare l’incidente risolto, conservare un’immagine forense del sistema, verificare l’integrità dei file di sistema critici, controllare le regole di inoltro della posta per deviazioni non autorizzate e ruotare le credenziali amministrative e di servizio collegate all’appliance.
Questo approccio costa più tempo del semplice aggiornamento, ma è l’unico modo per escludere con ragionevole certezza che un attaccante abbia sfruttato la finestra tra la comparsa della falla e la sua divulgazione pubblica, un periodo per cui, come detto, non esistono ancora stime affidabili sulla durata reale.
Il contesto normativo europeo: NIS2 e l’obbligo di notifica
Per le aziende italiane ed europee classificate come soggetti essenziali o importanti sotto la direttiva NIS2, una compromissione confermata di un’appliance di posta che gestisce comunicazioni aziendali rientra tra gli eventi potenzialmente soggetti a notifica, con la tempistica nota di preallarme entro 24 ore e notifica più dettagliata entro 72 ore dalla scoperta dell’incidente significativo. Questo aggiunge una dimensione di compliance che va oltre il semplice rischio tecnico: un ritardo nell’identificare una compromissione legata a CVE-2026-104286 può trasformarsi in un problema normativo, non solo informatico, per le organizzazioni che rientrano nel perimetro della direttiva.
Previsioni: cosa aspettarsi nei prossimi mesi
- È probabile che CISA e altri ricercatori pubblichino ulteriori dettagli tecnici, incluso un profilo più chiaro degli indicatori di compromissione, nelle settimane successive alla divulgazione iniziale
- Il numero di dispositivi effettivamente compromessi, oggi sconosciuto pubblicamente, verrà probabilmente rivelato in parte attraverso report di incident response pubblicati da vendor terzi nei prossimi mesi
- Altre appliance di posta elettronica, non solo FortiMail, resteranno un bersaglio privilegiato nel 2026-2027, seguendo lo stesso schema già visto su VPN e gateway di rete negli anni precedenti
- È ragionevole attendersi che le aziende europee soggette a NIS2 comincino a chiedere ai fornitori di appliance perimetrali tempi di risposta e trasparenza sugli indicatori di compromissione più stringenti rispetto al passato
- Il catalogo KEV di CISA continuerà a crescere come riferimento de facto anche fuori dagli Stati Uniti, nonostante la sua natura di obbligo solo per le agenzie federali USA
Resoconti più dettagliati, se e quando arriveranno, potrebbero emergere da testate come BleepingComputer o SecurityWeek, che storicamente seguono da vicino l’evoluzione di questi casi con interviste a ricercatori e aggiornamenti sui conteggi di dispositivi esposti.
Domande frequenti
Cos’è esattamente CVE-2026-104286?
È una vulnerabilità critica in FortiMail, il secure email gateway di Fortinet, con punteggio CVSS 9,8. Combina un difetto di path traversal con una gestione scorretta dei byte NULL, permettendo a un attaccante remoto e non autenticato di scrivere file arbitrari sul sistema sottostante tramite richieste HTTP o HTTPS costruite ad arte.
Quali versioni di FortiMail sono vulnerabili?
Sono coinvolti i rami 7.2.0-7.2.9, 7.4.0-7.4.8, 7.6.0-7.6.6 e 8.0.0-8.0.1. Chiunque gestisca un’istanza in queste fasce dovrebbe consultare l’advisory PSIRT ufficiale di Fortinet per individuare la build corretta più recente, senza affidarsi a numeri di versione riportati da articoli di terze parti.
La vulnerabilità è già sfruttata attivamente?
Sì, secondo i criteri di inclusione nel catalogo KEV di CISA, che richiede evidenza di sfruttamento reale, non teorico. Non sono però ancora disponibili pubblicamente un’attribuzione a un gruppo specifico, un numero ufficiale di vittime o cifre verificate sulle istanze compromesse.
Cosa significa l’inserimento nel catalogo CISA KEV?
Significa che CISA ha evidenza di sfruttamento attivo e, tramite la direttiva operativa vincolante in vigore, obbliga le agenzie federali civili statunitensi a correggere la falla entro una scadenza fissa, in questo caso il 4 ottobre 2026. Per le organizzazioni fuori da quel perimetro non è un obbligo legale diretto, ma è diventato uno standard di riferimento per la definizione delle priorità di patching.
Le aziende italiane sono obbligate ad aggiornare entro il 4 ottobre?
No, la scadenza della direttiva CISA vincola solo le agenzie federali civili statunitensi. Le aziende italiane non hanno un obbligo legale diretto legato a quella data, ma dovrebbero comunque trattare la falla come priorità massima vista la gravità del punteggio CVSS e la conferma di sfruttamento attivo.
Come posso verificare se il mio FortiMail è stato compromesso?
Controllare i log per richieste HTTP o HTTPS con sequenze di traversal di percorso o caratteri NULL codificati, cercare file creati o modificati in modo anomalo, verificare le regole di inoltro della posta e le configurazioni di sistema per cambiamenti non autorizzati, e conservare un’immagine forense prima di procedere con la bonifica completa.
Quali altre vulnerabilità Fortinet sono state sfruttate in passato?
I precedenti più noti sono CVE-2023-27997, soprannominata XORtigate, sul modulo SSL-VPN di FortiOS e FortiProxy con CVSS 9,2, e CVE-2022-42475, sempre su SSL-VPN, con CVSS 9,3 secondo Fortinet e associata a un attore di minaccia con legami riportati verso la Cina. Entrambe erano buffer overflow in heap, una classe di difetto diversa da quella di CVE-2026-104286.
Cosa cambia con il NIS2 se la mia azienda viene colpita?
Se l’organizzazione rientra tra i soggetti essenziali o importanti secondo NIS2 e la compromissione viene classificata come incidente significativo, scattano gli obblighi di preallarme entro 24 ore e notifica dettagliata entro 72 ore alle autorità competenti. Ignorare o ritardare questa valutazione può trasformare un problema tecnico in un problema di compliance.
