SICUREZZA

FortiMail CVE-2026-104286: zero-day attiva, mitigazione e controlli IoC

CVE-2026-104286 è sfruttata attivamente contro FortiMail: versioni esposte, mitigazione immediata, indicatori di compromissione e percorso operativo.

Gateway FortiMail che isola un percorso ostile durante la mitigazione di CVE-2026-104286
Indice dell'articolo

Rischio e azione: Fortinet ha pubblicato CVE-2026-104286, vulnerabilità critica di FortiMail già sfruttata attivamente. Un attaccante non autenticato può scrivere file arbitrari sul sistema tramite richieste HTTP o HTTPS costruite ad hoc. Le release corrette non sono ancora disponibili per tutti i rami: disabilitate subito IBE oppure rimuovete l’interfaccia FortiMail da Internet, preservando prima log e prove utili.

Versioni coinvolte e prerequisiti

L’avviso riguarda FortiMail 8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8 e 7.2.0-7.2.9. L’attacco richiede raggiungibilità HTTP/HTTPS del servizio interessato, ma non credenziali valide. CISA ha inserito la vulnerabilità nel catalogo delle falle note come sfruttate, confermando che non si tratta di un rischio soltanto teorico.

Fortinet indica come soluzioni 8.0.2, 7.6.7 e 7.4.9 o successive, ancora riportate come “upcoming” al momento dell’avviso. Gli ambienti 7.2 devono migrare al ramo 7.4 o superiore. Finché la release compatibile non è disponibile e verificata, la riduzione dell’esposizione è il controllo primario.

Mitigazione immediata

La misura raccomandata è disabilitare il supporto IBE dalla CLI:

config system encryption ibe
set status disable
end

Se IBE è necessario, Fortinet indica in alternativa di disabilitare l’accesso Internet all’interfaccia di gestione oppure limitarlo a reti private fidate. Questa scelta va accompagnata da una prova funzionale della posta e dei flussi amministrativi. Una regola di rete applicata senza verificare dipendenze, monitoraggio e accesso di emergenza può trasformare una mitigazione in un’interruzione operativa.

Come difesa temporanea aggiuntiva, il documento CSAF del vendor suggerisce di bloccare a monte le richieste POST /ibe che contengono sequenze ../. È un filtro compensativo, non una correzione: va verificato sui log reali, mantenuto insieme alla restrizione di rete e rimosso solo dopo l’aggiornamento e i test.

Patching e incident response non coincidono

Installare una release corretta impedirà nuovi tentativi attraverso il percorso noto, ma non dimostra che l’appliance fosse integra prima dell’intervento. Fortinet pubblica indicatori concreti: file aggiunti o modificati in percorsi di sistema, l’account di archivio archive234, attività verso 79[.]141.169.187 e 45[.]129.0.192, oltre a specifici eventi nei log.

Prima di aggiornare, riavviare o ricostruire, esportate log, configurazione, elenco account, cronologia amministrativa e metadati dei file sospetti. Se emerge un indicatore, aprite un incidente: isolate l’host, conservate le prove, ruotate le credenziali potenzialmente esposte e valutate una ricostruzione controllata con il supporto del vendor. Non cancellate un file sospetto come prima azione: potreste eliminare evidenze e lasciare persistenza altrove.

Checklist verificabile

  1. Inventariare tutte le appliance FortiMail, incluse secondarie, disaster recovery e laboratori.
  2. Registrare versione, esposizione HTTP/HTTPS, uso di IBE, owner e finestra di intervento.
  3. Salvare configurazione e log su una destinazione esterna, annotando fuso orario e retention.
  4. Disabilitare IBE oppure limitare l’interfaccia a reti private e host amministrativi autorizzati.
  5. Controllare hash e percorsi pubblicati da Fortinet, account archive234, IP e messaggi di log indicati nell’advisory.
  6. Se non emergono indicatori, installare la prima release corretta compatibile appena disponibile.
  7. Se emergono indicatori, separare il contenimento dalla bonifica e coinvolgere Fortinet PSIRT o il supporto.
  8. Dopo l’intervento, verificare ricezione e invio, code, quarantena, policy, integrazioni, amministrazione e backup.
  9. Documentare versione iniziale e finale, mitigazione, query eseguite, esiti e decisione di chiusura.

Limiti del controllo

L’assenza degli IoC pubblicati non esclude una compromissione: log incompleti, retention breve o varianti operative possono nascondere l’attività. Allo stesso modo, una versione vulnerabile prova l’esposizione tecnica ma non l’avvenuto attacco. La chiusura richiede quindi evidenze sullo stato precedente, sul cambiamento applicato e sui test successivi.

Devi mettere in sicurezza gateway email e appliance esposte senza perdere continuità? Richiedi una valutazione tecnica a MSP In Cloud.

Fonti primarie