La vulnerabilità zero-day di FortiMail consente agli aggressori non autenticati di scrivere file di sistema

Secondo un rapporto pubblicato il 1° ottobre 2026, una vulnerabilità critica in Fortinet FortiMail viene sfruttata contro interfacce di gestione accessibili da Internet.

Identificata come CVE-2026-104286 e internamente come FG-IR-26-175, la vulnerabilità può consentire a un aggressore non autenticato di scrivere file arbitrari nel sistema operativo sottostante dell’appliance. BleepingComputer riferisce che gli attacchi osservati hanno sfruttato la falla per eseguire codice o comandi non autorizzati.

La vulnerabilità ha un punteggio CVSS di 9.8. Fortinet ha attribuito la scoperta interna a Gwendal Guégniaud, membro del team Product Security.

Richieste web appositamente modificate possono aggirare il percorso previsto per i file

CVE-2026-104286 interessa l’interfaccia di gestione di FortiMail. Fortinet classifica i problemi alla base della vulnerabilità come path traversal, identificato da CWE-22, e gestione impropria di un byte o carattere NULL, identificata da CWE-158.

Un aggressore può inviare richieste HTTP o HTTPS appositamente modificate per indurre l’appliance a scrivere file al di fuori del percorso previsto dall’applicazione. Non è necessaria alcuna autenticazione.

Il vettore CVSS è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Descrive una vulnerabilità raggiungibile da remoto, con bassa complessità di attacco, senza privilegi richiesti né interazione da parte dell’utente. Se sfruttata con successo, può avere un impatto elevato su riservatezza, integrità e disponibilità.

La scrittura di file arbitrari è la funzionalità documentata della vulnerabilità. A seconda del percorso e del contenuto dei file scritti, questa capacità può alterare il comportamento dell’applicazione o introdurre componenti eseguibili. Il rapporto del 1° ottobre descrive l’attività esaminata come un mezzo per eseguire comandi o codice non autorizzati.

La distinzione è importante: la descrizione della vulnerabilità di Fortinet conferma la possibilità di scrivere file senza autenticazione, mentre le prove riportate sugli attacchi illustrano le modalità con cui lo sfruttamento si è manifestato sulle appliance interessate.

Build vulnerabili in quattro rami FortiMail supportati

Gli intervalli di versioni interessati sono:

Ramo FortiMail	Versioni vulnerabili
8.0	dalla 8.0.0 alla 8.0.1
7.6	dalla 7.6.0 alla 7.6.6
7.4	dalla 7.4.0 alla 7.4.8
7.2	dalla 7.2.0 alla 7.2.9

Per FortiMail 7.2, le indicazioni riportate da Fortinet raccomandano l’aggiornamento al ramo 7.4 o a uno successivo. Gli amministratori devono tenere conto di questa indicazione insieme alle informazioni sulle build corrette: le versioni fino alla 7.4.8 sono interessate, mentre la 7.4.9 era indicata come prossima versione corretta.

Secondo quanto riportato, per le installazioni interessate nei rami 7.4, 7.6 e 8.0 le correzioni non erano ancora disponibili. Fortinet ha indicato le seguenti versioni correttive previste:

• FortiMail 7.4.9
• FortiMail 7.6.7
• FortiMail 8.0.2

In attesa che sia disponibile e venga installata una versione correttiva adeguata, Fortinet raccomanda di disabilitare il supporto IBE:

config system encryption ibe
set status disable
end

In alternativa, è possibile rimuovere l’accesso da Internet all’interfaccia di gestione di FortiMail. Se è necessario mantenere l’amministrazione remota, l’accesso dovrebbe essere limitato a reti private fidate.

Gli amministratori non dovrebbero considerare il filtraggio di rete una prova che l’appliance non sia stata compromessa. I sistemi che in precedenza erano esposti devono comunque essere esaminati alla ricerca degli indicatori pubblicati.

File, hash e indicatori di rete aiutano a individuare le compromissioni

Fortinet ha fornito diversi indicatori relativi ai file associati all’attività descritta. Alcuni corrispondono a file aggiunti, altri a versioni modificate di percorsi già esistenti.

File	Stato riportato	SHA-256
/data/lib/liblog.so	Aggiunto	8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84
/bin/smit	Modificato	77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a
/data/bin/webconsole	Aggiunto	7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38
/data/bin/mailservice	Aggiunto	4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b
/data/etc/httpd.conf	Modificato	703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5
/data/etc/ld.so.preload	Aggiunto	8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6
/data/migadmin.tar.gz	Modificato	d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3

Gli indirizzi IP associati agli attacchi sono:

• 79[.]141.169.187
• 45[.]129.0.192

Questi indicatori dovrebbero servire da spunto per le indagini, non da lista di controllo da applicare in modo rigido. Le informazioni disponibili non dimostrano che ogni appliance compromessa contenga tutti i file o gli eventi di log elencati.

Le verifiche dovrebbero includere controlli sull’integrità dei file, il confronto degli hash, l’analisi delle richieste all’interfaccia di gestione e l’esame delle connessioni in uscita che coinvolgono i due indirizzi. Gli amministratori dovrebbero inoltre controllare le modifiche alla configurazione e i meccanismi di persistenza, in particolare gli interventi sul caricamento dei servizi o sull’esecuzione pianificata.

I log mostrano attività da shell e un possibile percorso di archiviazione

Gli esempi forniti da Fortinet includono un evento di debug di cron in cui root avvia un comando che inizia così:

/bin/sh -c 'O=/migadmin ...

L’estratto fornito è troncato, quindi non mostra il comando completo né il suo effetto finale. Tuttavia, la presenza di una shell root, dell’esecuzione tramite cron e di un riferimento a /migadmin rende l’evento rilevante per il triage forense.

Un altro evento registra la creazione, tramite interfaccia a riga di comando, di un account di archiviazione denominato archive234. L’evento indica il server remoto 79.141.169.187 e la directory /uploads, con i seguenti valori:

• Dimensione di rotazione: 50
• Intervallo di rotazione: 1
• Ora di rotazione: 14
• Password remota: oscurata nell’esempio

Questa configurazione potrebbe essere stata usata per inviare informazioni archiviate all’host remoto. La sola voce di log non dimostra che il trasferimento di dati sia stato completato.

Altri esempi includono un logout riuscito dell’utente admin, tentativi di autenticazione non riusciti per un utente interno indicato come *@domain.tld e un errore di decrittazione IBE. Quest’ultimo segnala una codifica Base64 non valida alla posizione 0, con un carattere di valore 0x2a.

I difensori dovrebbero correlare questi eventi in ordine cronologico con il traffico HTTP o HTTPS diretto all’interfaccia di gestione, le modifiche alla configurazione, i timestamp dei file, l’attività di cron e le sessioni di rete in uscita. Un singolo evento corrispondente non basta a ricostruire l’intera intrusione.

CISA fissa al 4 ottobre il termine per la correzione

Il 1° ottobre 2026 CISA ha aggiunto CVE-2026-104286 al catalogo Known Exploited Vulnerabilities. Le agenzie federali statunitensi devono rimediare entro il 4 ottobre 2026.

L’azione richiesta consiste nell’applicare le misure di mitigazione di Fortinet seguendo la BOD 26-04 Prioritizing Security Updates Based on Risk e i requisiti di CISA per il triage forense. Le organizzazioni interessate devono valutare l’esposizione a Internet di ciascun asset e attenersi alle indicazioni applicabili della BOD 26-04 per l’installazione delle patch.

Per i servizi cloud, le agenzie devono seguire le istruzioni corrispondenti della BOD 26-04 oppure interrompere l’uso del prodotto se non sono disponibili misure di mitigazione.

L’inclusione nel catalogo KEV conferma che lo sfruttamento non è soltanto teorico. Le priorità operative sono quindi limitare l’accesso all’interfaccia di gestione, disabilitare il supporto IBE ove applicabile, svolgere il triage forense e installare la versione corretta appropriata non appena disponibile.

La portata degli attacchi resta da chiarire

Fortinet ha dichiarato a BleepingComputer di essere in contatto con organizzazioni governative, tra cui CISA, e ha rimandato i clienti al proprio avviso per le indicazioni sulle misure correttive.

Le informazioni disponibili non attribuiscono l’attacco a un autore né indicano il numero totale di sistemi compromessi. Non specificano neppure quando sia iniziato lo sfruttamento.

Queste lacune non consentono di stabilire la portata della campagna o l’identità dei responsabili, ma non cambiano le misure immediate da adottare. Le organizzazioni che utilizzano una delle build FortiMail interessate dovrebbero considerare una precedente esposizione dell’interfaccia di gestione un motivo per avviare un’indagine, anziché affidarsi soltanto alla successiva installazione di una versione corretta.