Il dispositivo che filtra la posta in ingresso è, per definizione, il primo componente dell'infrastruttura a toccare contenuto ostile. È il suo mestiere. Il problema nasce quando quel contenuto ostile non viene analizzato, ma eseguito.

È esattamente quello che consente CVE-2026-76461, la vulnerabilità che Cisco ha reso pubblica lunedì 14 settembre 2026 confermando contestualmente che è già sfruttata in attacchi reali. CVSS 9.8. Nessuna autenticazione richiesta. Nessuna interazione dell'utente richiesta. L'attaccante invia una email a un destinatario servito dall'appliance e ottiene esecuzione di comandi arbitrari con privilegi di root sul sistema operativo sottostante.

Come funziona

Il difetto risiede nella logica di parsing delle email del software AsyncOS, il sistema operativo delle appliance Cisco Secure Email Gateway (l'ex IronPort ESA). La validazione insufficiente dell'input permette di inserire nel messaggio istruzioni SQL che l'appliance processa come tali contro il proprio database interno. Da lì si arriva all'esecuzione di comandi sul sistema operativo, con i privilegi massimi.

Vale la pena fermarsi un attimo sulla catena, perché spiega la gravità: un'iniezione SQL su un componente di sicurezza perimetrale che si trasforma in remote code execution come root. Non è un'escalation ipotetica, è quella che Cisco stessa descrive nel proprio advisory.

Il perimetro di esposizione è ampio nel modo peggiore possibile: sono interessate sia le versioni fisiche sia quelle virtuali dell'appliance, in qualunque configurazione. Non esiste un'impostazione difensiva che metta al riparo: se l'appliance riceve posta — e la riceve, è ciò per cui esiste — è raggiungibile. Non risultano invece impattati Secure Email and Web Manager e Secure Web Appliance.

Cisco ha rilasciato le versioni correttive: AsyncOS 15.5.5-014 per i sistemi in 15.5 o precedenti, 16.0.4-302 per il ramo 16.0 e 16.5.0-780 per il ramo 16.5.

Il dettaglio che cambia il piano di risposta

Cisco ha pubblicato indicatori di compromissione, ma li accompagna con un'avvertenza che va letta con attenzione: poiché l'attaccante ottiene root, può rimuovere o nascondere gli IoC per coprire le proprie tracce.

Questa frase, tradotta in pratica operativa, significa una cosa precisa: l'assenza di indicatori non è una prova di non compromissione. Chi verifica l'appliance, non trova nulla e archivia il caso sta usando un metodo che la vulnerabilità stessa rende inaffidabile. Su un sistema dove l'attaccante è amministratore, la fonte di verità non può essere il sistema stesso.

Il PSIRT di Cisco ha dichiarato di essere venuto a conoscenza dello sfruttamento nel settembre 2026, senza fornire dettagli sugli attacchi né attribuzione. CISA ha inserito la CVE nel catalogo Known Exploited Vulnerabilities il 14 settembre, con scadenza di rimedio per le agenzie federali statunitensi al 17 settembre: tre giorni, una delle finestre più strette assegnate quest'anno, indice di quanto l'agenzia consideri concreto il rischio.

Un ultimo elemento di contesto: questa è solo la seconda vulnerabilità di Secure Email Gateway a finire nel KEV, dopo CVE-2025-20393 sfruttata da attori legati alla Cina a fine 2025. Il prodotto non è storicamente un bersaglio di massa. Il fatto che lo diventi ora, e con una zero-day root, indica che qualcuno ci ha investito ricerca.

Cosa significa per le aziende italiane

Cisco Secure Email Gateway è un prodotto da fascia medio-alta: in Italia lo si trova soprattutto in banche, assicurazioni, sanità privata, utility, pubbliche amministrazioni centrali e grandi manifatturiere, spesso installato anni fa e da allora gestito come infrastruttura stabile. È precisamente la categoria di apparato che nessuno guarda finché non smette di funzionare.

Qui il rischio ha tre dimensioni che meritano di essere distinte.

La prima è la posizione in rete. Il gateway di posta sta al confine, ma quasi mai è isolato: deve parlare con LDAP o Active Directory per la validazione dei destinatari, con i server di posta interni, spesso con SIEM e sistemi di archiviazione. Un attaccante con root sull'ESA non ha solo compromesso un filtro antispam: si trova in un punto privilegiato, già autorizzato a comunicare con l'identity provider e con il mail server. La segmentazione, in molte reti italiane, si ferma prima di questo apparato proprio perché è considerato "un dispositivo di sicurezza".

La seconda è il contenuto. Attraverso il gateway passa tutta la posta aziendale in transito, comprese quarantene e code di messaggi. Significa fatture, contratti, comunicazioni legali, credenziali inviate via mail nonostante ogni policy dica di non farlo. Un accesso root persistente è, di fatto, un'intercettazione della corrispondenza aziendale.

La terza è la verificabilità. L'avvertenza di Cisco sugli IoC cancellabili ha una conseguenza sgradevole per chi deve decidere se notificare: in assenza di log esterni all'appliance, dimostrare che non c'è stata compromissione è difficile quanto dimostrare che c'è stata. Chi ha già oggi i log dell'ESA replicati su un SIEM esterno è in una posizione molto diversa da chi li ha solo in locale.

Il contesto normativo

Per i soggetti essenziali e importanti ai sensi del D.lgs. 138/2024 (NIS2 in Italia), un'appliance perimetrale compromessa rientra senza ambiguità tra gli incidenti significativi: il compromesso di un gateway di posta con accesso root è capace di produrre un impatto operativo rilevante e riguarda dati di terzi. Ricordo i termini, perché sono stretti e vengono ancora sottovalutati: pre-notifica al CSIRT Italia entro 24 ore, notifica con valutazione iniziale entro 72 ore, relazione finale entro un mese.

Per banche, assicurazioni e intermediari finanziari il riferimento è DORA, che impone la classificazione dell'incidente e la segnalazione all'autorità competente su tempistiche analoghe, con l'aggravante che il gateway di posta è quasi sempre censito tra le funzioni essenziali o importanti.

Sul fronte GDPR: se emergono evidenze di accesso al contenuto dei messaggi o alle code di quarantena, si è di fronte a una violazione di dati personali potenzialmente su larga scala, con obbligo di valutazione ex art. 33 entro 72 ore. Vale la pena notare che, data la natura del sistema, i dati esposti includono con alta probabilità categorie particolari (comunicazioni con medici del lavoro, dati sindacali, procedimenti disciplinari transitano tutti via email): questo alza in modo sensibile la probabilità che scatti anche l'obbligo di comunicazione agli interessati ex art. 34.

Cosa fare subito

  • Aggiornare AsyncOS oggi, senza attendere la finestra di manutenzione ordinaria: 15.5.5-014, 16.0.4-302 o 16.5.0-780 secondo il ramo in uso. Verificare la versione effettivamente in esecuzione, non quella riportata nell'inventario.
  • Applicare gli indicatori di compromissione pubblicati da Cisco, consapevoli del limite: usarli per confermare una compromissione, mai per escluderla.
  • Cercare le tracce fuori dall'appliance, che è il punto chiave. Analizzare sul SIEM e sui firewall il traffico in uscita originato dall'IP del gateway verso destinazioni non abituali, le autenticazioni anomale dell'account di servizio dell'ESA verso LDAP/AD, eventuali connessioni dell'appliance verso segmenti interni che non dovrebbe raggiungere.
  • Rivedere le credenziali configurate sull'appliance: bind account LDAP, account SMTP relay, credenziali di integrazione con sistemi di archiviazione. Se c'è il sospetto di compromissione vanno considerate esposte e ruotate.
  • Verificare la configurazione dell'accesso amministrativo: interfaccia di gestione esposta solo su rete di management, MFA sugli account amministrativi, nessun account locale condiviso.
  • Controllare utenze e configurazioni create o modificate sull'appliance nelle ultime settimane, confrontandole con una baseline nota.
  • Se l'appliance è gestita da un fornitore o MSP, chiedere formalmente conferma scritta della versione installata e della data di applicazione della patch. Sotto NIS2 e DORA la responsabilità della catena di fornitura resta in capo al soggetto vigilato.
  • Se emergono evidenze di compromissione, non limitarsi ad aggiornare: su un sistema dove l'attaccante ha avuto root, la reinstallazione da immagine pulita con successiva riconfigurazione è l'unica strada che offre garanzie ragionevoli.

Una nota sul contesto Cisco

CVE-2026-76461 arriva a pochi giorni di distanza dagli avvisi su CVE-2026-20079 e CVE-2026-20316 in Secure Firewall Management Center, sfruttate — secondo Cisco — sia da gruppi statuali russi sia da criminali a scopo di lucro, di cui abbiamo scritto l'11 settembre. Due prodotti di sicurezza dello stesso vendore sotto attacco attivo nella stessa settimana non è una coincidenza statistica da ignorare: gli apparati di sicurezza sono target di prima scelta perché sono esposti per progetto, raramente aggiornati con la stessa disciplina degli endpoint e godono di una fiducia implicita nelle architetture di rete che non sempre si sono meritati.

La domanda pratica da portarsi a casa non è "ho aggiornato l'ESA?". È: quanti apparati di sicurezza ho in rete che non rientrano in nessun ciclo di patching documentato?