FortiMail sotto attacco, AWS corregge tre falle tra MCP, Lambda e Ion

🛡️ Executive Summary

• FortiMail CVE-2026-104286 è sfruttata attivamente e dispone di IoC: patch e triage forense hanno priorità.
• AWS corregge argument injection in security-agent-mcp-server e un fail-open nella mascheratura dati di Lambda Powertools.
• Amazon Ion Python può andare in crash con input profondamente annidati; la correzione arriva con la versione 0.15.0.

FortiMail passa direttamente dalla disclosure all’incident response: Fortinet conferma che CVE-2026-104286 è stata sfruttata in attacchi reali e pubblica versioni coinvolte, workaround e indicatori di compromissione. Nello stesso ciclo di sicurezza, AWS corregge tre vulnerabilità in componenti open source utilizzati per agenti AI, funzioni serverless e parsing dei dati: security-agent-mcp-server, Powertools for AWS Lambda e Amazon Ion Python. I quattro problemi non hanno lo stesso livello operativo. FortiMail richiede anche verifica retrospettiva della compromissione; i tre casi AWS, invece, richiedono aggiornamenti mirati sulla base delle dipendenze effettivamente presenti e degli input raggiungibili dagli attaccanti.

FortiMail CVE-2026-104286 è già sfruttata e lascia indicatori concreti

Il PSIRT FG-IR-26-175 di Fortinet descrive una combinazione di path traversal CWE-22 e neutralizzazione impropria dei NULL byte CWE-158 nella GUI di FortiMail. Un aggressore remoto non autenticato può inviare richieste HTTP o HTTPS appositamente costruite e arrivare alla scrittura arbitraria di file sul sistema sottostante; Fortinet assegna alla vulnerabilità un CVSS 9,8, la classifica come Critical e dichiara esplicitamente Known Exploited: Yes. Sono coinvolti 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. Le correzioni sono previste nelle versioni 8.0.2, 7.6.7 e 7.4.9, mentre per il ramo 7.2 Fortinet prescrive il passaggio alla 7.4 o successiva. Il quadro è più serio di una normale patch urgente perché il vendor pubblica IoC che comprendono nuovi file, binari modificati, ld.so.preload, modifiche a httpd.conf, cron job sospetti e due IP associati all’attività. Il precedente dossier sulla campagna FortiBleed contro apparati FortiGate aveva già mostrato quanto i dispositivi Fortinet esposti possano diventare punti di raccolta di credenziali e accesso iniziale, ma qui il livello di prova è diverso: Fortinet documenta direttamente lo sfruttamento della vulnerabilità.

Leggi anche: Cisco Secure Email Gateway sotto attacco: una SQL injection porta a root, AWS corregge TEAM

Il workaround Fortinet riduce l’esposizione ma non sostituisce il triage

Fortinet indica due mitigazioni immediate: disabilitare il supporto IBE attraverso la configurazione CLI prevista oppure togliere la management interface da Internet, limitandola a reti private fidate. La seconda indicazione rende evidente il nodo operativo: la superficie sfruttabile è la GUI di gestione, quindi l’esposizione amministrativa pubblica aumenta direttamente il rischio. Tuttavia, chi applica oggi il workaround non può dedurre che il sistema fosse integro ieri. Gli IoC pubblicati dal vendor servono proprio a distinguere patching e bonifica: file come /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice e /data/etc/ld.so.preload, insieme alle modifiche a /bin/smit, httpd.conf e migadmin.tar.gz, devono essere confrontati con lo stato dell’appliance. Anche i log mostrano elementi utili, inclusa l’aggiunta di un account di archiviazione remoto verso uno degli IP indicati dal PSIRT. L’assenza di una virtual patch rafforza la necessità di intervenire sulla configurazione o sulla versione. In un contesto analogo, la gestione delle vulnerabilità Fortinet e AWS già affrontata a luglio aveva evidenziato l’importanza di separare la correzione del difetto dalla verifica dell’eventuale persistenza.

AWS corregge argument injection, data masking e recursion in tre componenti

Il bollettino AWS 2026-121 riguarda CVE-2026-97662 in security-agent-mcp-server: nelle versioni dalla 0.1.1 precedenti alla 0.2.0, un reference value costruito ad hoc può essere interpretato come opzione della riga di comando durante una diff scan, consentendo a un attore dipendente dal contesto di creare, sovrascrivere o troncare file fuori dal workspace previsto. AWS corregge il problema nella 0.2.0 e non indica workaround equivalenti all’upgrade; fino all’aggiornamento raccomanda repository fidati, privilegi minimi e ambiente isolato. È un rischio coerente con la superficie già emersa nei precedenti Security Agent, DJL e SSM di AWS, dove componenti ausiliari potevano raggiungere sorgenti, credenziali o risorse più privilegiate del previsto.

Il bollettino AWS 2026-123 descrive invece CVE-2026-104002 in Powertools for AWS Lambda Python, versioni 3.6.0-3.34.0: un errore fail-open nella utility di data masking può restituire il valore originale che l’applicazione intendeva oscurare. La versione 3.35.0 cambia il comportamento e solleva una DataMaskingError; AWS non pubblica workaround. Il bollettino AWS 2026-122 riguarda infine CVE-2026-104020 in Amazon Ion Python prima della 0.15.0: valori Ion profondamente annidati possono causare ricorsione incontrollata, errore o crash e quindi denial of service. In attesa dell’upgrade, AWS indica la disabilitazione dell’estensione C di ion-python e la gestione esplicita di RecursionError. Il precedente caso AWS IoT Device SDK e validazione TLS mostra la stessa necessità di guardare non solo al servizio cloud, ma alle librerie integrate nelle applicazioni.

Continua con:
CISA mette SharePoint e Check Point nel KEV, AWS corregge MCP
CISA porta Cisco ISE, Acronis e Pixel nel KEV, AWS corregge il bypass EKS

La priorità operativa dipende dalla prova di sfruttamento e dall’esposizione

Il confronto tra FortiMail e i tre bollettini AWS evita un errore frequente nel vulnerability management: trasformare il punteggio o la gravità nominale in un ordine automatico di intervento. FortiMail ha exploitation confermata, accesso non autenticato, possibilità di scrittura arbitraria e IoC pubblicati: richiede quindi patch o workaround immediato, verifica della superficie di management e triage sugli indicatori forniti dal vendor. Per AWS, le fonti disponibili descrivono vulnerabilità e correzioni ma non documentano sfruttamento attivo; la priorità dipende dalla presenza delle versioni vulnerabili, dalla raggiungibilità degli input e dal valore delle risorse accessibili al processo. security-agent-mcp-server è sensibile quando opera su repository non fidati o con privilegi eccessivi, Powertools diventa critico quando il data masking protegge campi realmente sensibili, mentre Ion Python assume peso nei servizi che processano input Ion controllabili dall’esterno. La strategia corretta non è quindi “patchare tutto allo stesso modo”, ma separare incident response e remediation preventiva: nel primo caso bisogna chiedersi se l’attaccante sia già entrato, nel secondo occorre chiudere il percorso prima che una disclosure pubblica venga trasformata in exploit operativo.