CVE-2026-104286: viene sfruttato uno zero-day di FortiMail - workaround e verifica della compromissione

Il 1° ottobre 2026 Fortinet ha pubblicato l’advisory FG-IR-26-175 relativo a una vulnerabilità critica in FortiMail. Tramite richieste HTTP o HTTPS appositamente predisposte, un aggressore può scrivere file arbitrari sul sistema sottostante senza autenticazione e quindi eseguire codice. La vulnerabilità è identificata come CVE-2026-104286 e ha un punteggio CVSS di 9.8. Fortinet conferma che è già sfruttata; nello stesso giorno l’agenzia statunitense CISA l’ha inserita nel proprio catalogo delle vulnerabilità sfruttate (KEV). Al 2 ottobre non è ancora disponibile un aggiornamento, ma solo un workaround.

Certificato: Fortinet FortiMail 7.4 Administrator

Sono certificato da Fortinet come FortiMail 7.4 Administrator. L'esame comprende distribuzione, amministrazione, gestione operativa e risoluzione dei problemi di FortiMail. Verifica il badge su Credly

In breve

Cronologia

Tutti gli orari sono espressi nell’ora legale dell’Europa centrale (CEST). Laddove non è indicato un orario, non sono disponibili informazioni temporali affidabili.

1. Mer, 1° ottobre

   Advisory FG-IR-26-175

   Fortinet pubblica l'advisory con versioni interessate, workaround e indicatori. A questo punto lo sfruttamento è già noto; secondo l'advisory non esiste una patch virtuale per FortiGate-IPS.

2. Mer, 1° ottobre, 08:46

   Articolo su heise online

   heise riferisce degli attacchi in corso e del workaround; secondo l'articolo, gli aggiornamenti per chiudere la vulnerabilità non sono ancora disponibili.

3. Mer, 1° ottobre

   Inserimento nel catalogo CISA

   CISA inserisce CVE-2026-104286 nel catalogo Known Exploited Vulnerabilities. Secondo BleepingComputer e The Hacker News, le agenzie federali statunitensi devono implementare aggiornamenti o workaround entro il 4 ottobre.

4. Situazione a gio, 2 ottobre

   Ancora aperta

   Le versioni corrette 8.0.2, 7.6.7 e 7.4.9 sono annunciate, ma non pubblicate. Non sono disponibili informazioni sulla portata degli attacchi, sulle organizzazioni coinvolte e sull'origine degli aggressori.

Versioni interessate

Per il ramo 7.2 non verrà pubblicato alcun aggiornamento; questi sistemi devono passare alla 7.4 o a una versione successiva. Pianificare ora il percorso di aggiornamento in base alle Release Notes riduce il tempo necessario per aggiornare non appena sarà disponibile la versione corretta. Fino ad allora rimane solo il workaround.

La versione attuale è visualizzata dalla CLI con:

get system status

Misura immediata: implementare il workaround

Fortinet indica due varianti. Secondo l’advisory è sufficiente una di esse; ove l’operatività lo consenta, sono sensate entrambe.

Variante 1: disabilitare IBE

IBE (Identity-Based Encryption) è la funzione con cui FortiMail recapita messaggi cifrati a destinatari esterni: il destinatario riceve il messaggio come allegato cifrato (push) oppure lo richiama tramite il portale web di FortiMail (pull). Fortinet indica la funzione IBE come workaround, quindi gli attacchi transitano attraverso un percorso di codice di questa funzione. La disattivazione avviene nella CLI:

config system encryption ibe
    set status disable
end

È possibile verificare lo stato prima e dopo con:

show system encryption ibe

La disattivazione ha conseguenze sul traffico email. Fortinet non le descrive nell’advisory. Prima della modifica occorre quindi chiarire:

1. Quali criteri utilizzano IBE: nei profili di contenuto e dei criteri, IBE è configurato come azione di cifratura, ad esempio per parole chiave nell’oggetto come [secure] o per regole di protezione dei dati. Durante la disattivazione, questi messaggi non potranno più essere recapitati cifrati tramite IBE.

2. Come trattare questi messaggi: trattenerli, recapitarli con un altro metodo (S/MIME, TLS obbligatorio) oppure fornire un riscontro ai mittenti. Il recapito non cifrato di messaggi che un criterio dovrebbe cifrare non è generalmente consentito.

3. Chi è interessato: devono essere informati i destinatari esterni che recuperano messaggi nel portale IBE e gli utenti che inviano messaggi cifrati.

Variante 2: bloccare l’interfaccia di amministrazione da Internet

La seconda variante blocca l’accesso da Internet all’interfaccia di amministrazione o lo limita a reti private attendibili, ad esempio una rete di gestione o una VPN. Può essere implementata su un firewall a monte oppure tramite le impostazioni di accesso delle interfacce in FortiMail (Administrative Access).

Anche la webmail, l’accesso alla quarantena per gli utenti e il portale IBE funzionano tramite HTTPS. Se si trovano sulla stessa interfaccia dell’amministrazione, un blocco HTTPS generalizzato blocca anche questi servizi. In questo caso, la variante 1 è la via più diretta. SMTP sulla porta 25 non è interessato da nessuna delle due varianti; il flusso di posta continua.

Verificare una compromissione

Poiché la vulnerabilità è stata sfruttata prima dell’advisory, il workaround non esclude un attacco precedente. Fortinet pubblica nell’advisory indicatori che consentono di verificare un sistema.

File

Fortinet ha trovato i seguenti file su sistemi compromessi. L’advisory ne indica i valori hash; per il confronto fa fede l’elenco nell’advisory.

Una voce in /data/etc/ld.so.preload precarica la libreria indicata in ogni processo. Insieme a liblog.so ciò indica una backdoor persistente che sopravvive a un riavvio.

Indirizzi IP

Questi indirizzi devono essere cercati nei log di FortiMail, del firewall a monte e del reverse proxy e bloccati fino a nuovo avviso.

Voci di log

L’advisory indica tre schemi nei log di sistema di FortiMail:

1. Voci Cron dell’utente root, che avviano una shell relativa a /migadmin, ad esempio type=event subtype=system pri=debug user=system ui=cron msg="(root) CMD (/bin/sh -c 'O=/migadmin....

2. Configurazione di account di archiviazione con l’IP remoto 79.141.169.187. Un account di archiviazione può depositare copie dei messaggi presso una destinazione esterna.

3. Errori di decodifica Base64 nel decrittatore IBE e tentativi di autenticazione falliti sospetti.

La presenza di uno di questi indicatori significa che il sistema è considerato compromesso. Prima di ogni modifica, è necessario salvare log e configurazione per mantenere possibile un’analisi forense. Un aggiornamento da solo non rimuove una backdoor configurata. La bonifica comprende una reinstallazione da una fonte attendibile, l’importazione di una configurazione verificata e la modifica di tutte le credenziali memorizzate sul sistema: account amministrativi, account di binding LDAP, autenticazione SMTP e chiavi private dei certificati. Account di archiviazione e inoltri devono essere verificati per individuare destinazioni sconosciute, poiché attraverso di essi possono fuoriuscire contenuti dei messaggi.

Contesto

I gateway email sono al confine della rete e elaborano l’intero traffico di messaggi di un’organizzazione. Una vulnerabilità che esegue codice senza autenticazione offre a un aggressore accesso ai contenuti dei messaggi, alle credenziali memorizzate e al materiale crittografico. Non è il primo caso per FortiMail: nel maggio 2025, CVE-2025-32756 (FG-IR-25-254, CVSS 9.6) riguardava, oltre a FortiVoice, anche FortiMail; all’epoca la vulnerabilità era stata sfruttata in modo dimostrabile su sistemi FortiVoice.

Alla fine di settembre, inoltre, Kiteworks ha invitato i propri clienti a spegnere preventivamente i sistemi a causa di un avvertimento delle autorità di contrasto; le circostanze restano aperte (Kiteworks: raccomandazione di spegnimento del 26 settembre). Non è nota alcuna correlazione tra i due casi.

Cosa fare ora

1. Determinare la versione con get system status e confrontarla con la tabella delle versioni interessate.

2. Verificare gli indicatori e salvare i log prima di apportare modifiche al sistema.

3. Implementare il workaround: disabilitare IBE o bloccare l’interfaccia di amministrazione da Internet, dopo aver chiarito le conseguenze per i recapiti cifrati.

4. Bloccare gli indirizzi IP e cercarli retroattivamente nei log del firewall.

5. Pianificare l’aggiornamento: installare la versione corretta non appena disponibile; portare i sistemi alla 7.2 alla 7.4 o successiva.

6. Monitorare l’advisory: Fortinet integra FG-IR-26-175 in presenza di nuove informazioni; la cronologia delle revisioni è disponibile alla fine dell’advisory.