Cisco ha confermato che un'altra vulnerabilità critica del Secure Email Gateway (SEG) è sfruttata in attacchi reali. Si tratta della CVE-2026-76519, valutata CVSS 9.8: un mittente non autenticato può inviare una email con un allegato costruito ad arte, scrivere file arbitrari sul sistema operativo dell'appliance ed eseguire comandi come root. Il PSIRT di Cisco ha rilevato lo sfruttamento attivo nell'ottobre 2026; l'avviso è stato aggiornato il 14 ottobre e CISA ha aggiunto la falla al catalogo KEV con scadenza di rimedio fissata al 17 ottobre per le agenzie federali statunitensi.

Per chi segue il prodotto, la notizia è una seconda puntata: a metà settembre avevamo raccontato la zero-day CVE-2026-76461, una SQL injection nel parsing delle email. Questa è una falla diversa, in un'altra parte del software, e richiede controlli diversi.

Cosa è successo

Secondo le ricostruzioni di BleepingComputer, The Hacker News e SecurityWeek, il difetto è un relative path traversal nella funzione Advanced Malware Protection (AMP), causato da una gestione scorretta degli allegati. Cisco l'ha scoperto con le proprie scansioni di sicurezza interne.

La vulnerabilità non riguarda tutte le installazioni. Perché l'appliance sia esposta devono essere vere entrambe le condizioni seguenti:

  • il servizio File Reputation, parte di AMP, è abilitato e assegnato a una mail policy;
  • la versione dei Content Scanner Tools è precedente alla 25.3.0.5525.

Sono coinvolti sia i gateway fisici sia quelli virtuali. Non risultano interessati Secure Email and Web Manager e Secure Web Appliance. Non esiste un workaround.

La parte meno intuitiva riguarda le patch. Le build di AsyncOS rilasciate il 14 settembre con una release di hardening (15.5.5-014 e 16.5.0-780) coprono anche questa falla, come Cisco ha poi confermato. Per il ramo 16.0, invece, non esiste una build corretta: la 16.0.4-302, che sistemava la zero-day di settembre, non risolve questo bug, e occorre migrare a un'altra release. In alternativa, i Content Scanner Tools 25.3.0.5525 o successivi si installano senza aggiornare AsyncOS e senza riavvio, e per questo sono la via più rapida per chiudere l'esposizione.

Sul fronte dello sfruttamento, Cisco indica come attivamente sfruttate sia questa falla di scrittura file sia la SQL injection di settembre, ma non collega gli attacchi tra loro e non fornisce dettagli sugli autori né indicatori tecnici precisi. Shadowserver conta circa 300 istanze SEG esposte su Internet, senza distinguere tra sistemi reali, honeypot e dispositivi già aggiornati. È un numero basso in assoluto, ma questi apparati non sono pensati per essere esposti con la loro interfaccia: la superficie reale è quella della porta SMTP, aperta per definizione.

Perché preoccupa più del solito

Un gateway di posta compromesso non è un server qualunque. Vede tutto il traffico email in ingresso e in uscita, dialoga con Active Directory o LDAP per validare i destinatari, e spesso conserva code e quarantene con messaggi interi. Con i privilegi di root l'attaccante può leggere, modificare o deviare la posta, rubare le credenziali di servizio e usare l'appliance come testa di ponte verso la rete interna.

Come già per la falla di settembre, vale un avvertimento di Cisco: un aggressore con root può cancellare le proprie tracce. Il controllo di compromissione previsto da Cisco (la ricerca del messaggio System Security nei log di sistema) può quindi restituire "nessun indicatore trovato" anche su un dispositivo violato. Un esito negativo riduce il sospetto, non lo elimina.

Cosa significa per le aziende italiane

Secure Email Gateway, già IronPort ESA, è diffuso in Italia soprattutto in banche, assicurazioni, sanità, pubblica amministrazione e grandi gruppi industriali: organizzazioni che lo hanno installato anni fa e lo gestiscono come infrastruttura "stabile", spesso tramite un fornitore esterno e con cicli di aggiornamento lenti. Sono esattamente le condizioni in cui una falla attiva da settimane passa inosservata.

Ci sono tre ragionamenti pratici da fare.

Primo: la condizione di esposizione è configurabile, quindi verificabile. Non è una falla "per tutti": chi non usa File Reputation non è vulnerabile a questa CVE. Ma File Reputation è una funzione di sicurezza che molte organizzazioni attivano proprio perché richiesta da policy interne o da audit. Il paradosso è che chi ha applicato una buona pratica è quello più esposto. Il controllo richiede cinque minuti e va fatto oggi.

Secondo: l'aggiornamento di settembre potrebbe non bastare. Chi ha installato in fretta la patch per la CVE-2026-76461 sul ramo 16.0 potrebbe credersi coperto e non lo è. Il rischio concreto è una falsa sicurezza in organizzazioni che hanno chiuso il ticket di settembre.

Terzo: la compromissione è un incidente di sicurezza dei dati. Se un gateway che tratta posta con dati personali risulta compromesso, scatta la valutazione di una violazione ai sensi dell'art. 33 del GDPR: notifica al Garante entro 72 ore dalla scoperta se il rischio per gli interessati non è trascurabile. Per i soggetti NIS2 (con scadenze di adeguamento in arrivo il 31 ottobre) un incidente significativo su un sistema di posta comporta gli obblighi di notifica verso lo CSIRT Italia presso ACN, con preallarme entro 24 ore. Prepararsi prima, sapendo chi decide e chi notifica, vale più di qualsiasi patch tardiva.

Cosa fare subito

  • Verificare se File Reputation è attivo: Mail Policies > Incoming/Outgoing Mail Policies > Advanced Malware Protection.
  • Controllare la versione dei Content Scanner Tools con il comando contentscannerstatus da CLI. Se è inferiore alla 25.3.0.5525, aggiornare con contentscannerupdate oppure abilitare gli aggiornamenti automatici.
  • Pianificare la migrazione di AsyncOS a 15.5.5-014 o 16.5.0-780; chi è sul ramo 16.0 non può fermarsi alla 16.0.4-302.
  • Eseguire il controllo di compromissione su ogni membro del cluster (grep "System Security" system_logs) e agire in base all'esito.
  • Cercare nei log del firewall e della rete upload o download anomali da e verso IP esterni, perché i log del dispositivo possono essere stati ripuliti.
  • Se c'è sospetto di compromissione: preservare prima le evidenze forensi (l'upgrade distrugge log e tracce), ricostruire le appliance virtuali da zero su una release corretta senza importare vecchie configurazioni, ruotare credenziali e materiale crittografico, e trattare tutti i membri del cluster come potenzialmente compromessi perché le chiavi SSH di uno possono aprire gli altri.
  • Documentare date, versioni e verifiche: serviranno per GDPR e NIS2.

Valutazione

Due zero-day sfruttate sullo stesso prodotto in un mese indicano che qualcuno sta investendo ricerca su questa famiglia di appliance. Il vero rischio non è la singola CVE, ma l'abitudine di considerare il gateway di posta un apparato "da dimenticare". Va trattato come un sistema esposto su Internet, con inventario, finestre di patching definite e monitoraggio dall'esterno.