Cisco Secure Email Gateway CVE-2026-76461: una email prende root

Il dispositivo che ispeziona ogni email in ingresso della tua organizzazione può essere preso in mano da una email in ingresso. È tutto qui CVE-2026-76461: una SQL injection nella logica di parsing della posta di Cisco AsyncOS — il software dietro il Cisco Secure Email Gateway — che un attaccante remoto e non autenticato innesca inviando un singolo messaggio costruito ad arte. Nessun login. Nessun utente che clicca alcunché. Nessun allegato da aprire. Il gateway analizza il messaggio come ne analizza milioni di altri e, così facendo, esegue l'SQL dell'attaccante, che scala fino a comandi di sistema operativo arbitrari come root. Cisco lo valuta CVSS 9.8 e ha confermato lo sfruttamento attivo; CISA lo ha inserito nel catalogo Known Exploited Vulnerabilities il 14 settembre 2026, con scadenza di remediation federale al 17 settembre ai sensi della BOD 26-04.

Il motivo per cui questa non si liquida con "applica la patch e vai avanti" è architetturale. Un email gateway non è un server qualunque. È un chokepoint fidato, in linea, esposto su internet, che vede già la posta in chiaro, parla già verso l'esterno come parte del suo lavoro ed è già esente da buona parte del sospetto sull'egress che applichi alle postazioni di lavoro. Root su quella scatola non è "un host compromesso". È un'intercettazione sulla corrispondenza dell'organizzazione più una rampa di lancio pre-autorizzata dentro la rete — e, come vedremo, è una scatola che può riscrivere i propri log.

Come CVE-2026-76461 trasforma una email in root

La falla è una SQL injection da manuale (CWE-89) nel posto sbagliato. Quando AsyncOS acquisisce un messaggio, parte della pipeline di parsing costruisce query verso il database a partire da campi contenuti nella posta. Poiché quei campi non sono validati a sufficienza, un attaccante che piazza sintassi SQL nel punto giusto vede le proprie istruzioni eseguite contro il database dell'appliance invece che trattate come dato.

La SQL injection di per sé legge e scrive tabelle. Passare da lì a root sul sistema operativo è ciò che rende questo un 9.8 e non un bug di sola divulgazione dati, ed è un percorso ben noto sui backend in stile PostgreSQL: il costrutto COPY ... TO PROGRAM consente a una sessione SQL con privilegi sufficienti di passare una stringa alla shell dell'host ed eseguirla. Una volta che la query iniettata raggiunge quella primitiva, l'attaccante non manipola più righe — esegue comandi come il processo del database, che su queste appliance corrisponde all'esecuzione di comandi OS a livello root.

Tre proprietà aggravano la gravità:

• Non autenticata e senza interazione. La superficie d'attacco è "poter inviare email al tuo record MX". Che è, per definizione, l'intera internet.
• Pre-auth significa nessun evento di autenticazione. Non c'è login fallito, né sessione, né contesto utente da correlare. L'unica prova di primo ordine è il messaggio stesso che attraversa la pipeline.
• Colpisce l'appliance indipendentemente dalla configurazione. L'advisory Cisco la circoscrive alle appliance Secure Email Gateway fisiche e virtuali su tutte le release line interessate — non è un flag di funzionalità di nicchia.

Perché un email gateway è il posto peggiore dove perdere contro una SQL injection

Ordina le scatole della tua rete per quanto danno root su ciascuna garantisce a un attaccante, e l'email gateway si colloca vicino alla cima per ragioni che quasi nessun inventario asset cattura.

Proprietà dell'appliance	Cosa ti dà root su di essa
Vede tutta la posta in entrata e in uscita	Un'intercettazione passiva su corrispondenza di direzione, legale, HR e finanza
Autorizzata a fare connessioni in uscita	C2 ed esfiltrazione che si mimetizzano nel "mail server che fa cose da mail server"
Detiene credenziali di relay SMTP, bind LDAP/AD, chiavi API	Materiale di pivot verso l'identità e lo store di posta interno
Termina il TLS della posta in ingresso	Accesso in chiaro a contenuti cifrati ovunque altrove
È un controllo di sicurezza di cui gli auditor si fidano	Una posizione fidata da cui inviare phishing interno convincente

L'ultima riga è quella silenziosa. Un email gateway rootato può originare posta che supera i tuoi stessi controlli SPF, DKIM e DMARC, perché è il mittente autorizzato. Il phishing interno da quella posizione è quasi indistinguibile dalla posta legittima — la rampa di lancio più forte possibile per lo stadio successivo.

Il punto cieco: un'appliance rootata controlla le proprie prove

Ecco il problema operativo che decide se davvero la intercetti. La guida di detection di Cisco, ripresa dai primi write-up del bug, chiede di rivedere i mail_logs in cerca di SQL anomalo — pattern come COPY ... TO PROGRAM — e di controllare ogni nodo di un deployment in cluster. È un consiglio corretto, e ha una dipendenza temporale fatale: i log vivono sulla scatola che l'attaccante ora possiede come root. Un attaccante che ha raggiunto l'esecuzione di comandi OS può troncare, modificare o interrompere la scrittura di quei log prima ancora che tu lanci la query. La stessa nota della guida lo dice — ti dice di incrociare i log esterni di firewall e rete, proprio perché quelli locali non sono più affidabili.

"Tira fuori i mail_logs e cerca l'injection." "I mail_logs dicono che non è successo niente." "Allora o non è successo niente, oppure la cosa che è successa aveva root e ha riscritto i mail_logs. Quale appliance è quella che ha appena iniziato ad aprire sessioni in uscita che non apriva mai?"

Questa è la legge generale della compromissione delle appliance, e gli email gateway la rendono più netta: quando un attaccante ha root sul dispositivo che genera la telemetria, quella telemetria è una dichiarazione dell'avversario, non una prova sul suo conto. L'unica superficie che l'attaccante non può modificare a posteriori è la rete tra l'appliance e tutto il resto. Un gateway che d'improvviso avvia una sessione interattiva verso l'esterno, fa da beacon verso un ASN mai contattato, o inizia a spostare dati verso lo store di posta interno su un protocollo che non ha mai usato, ti sta dicendo la verità sul filo mentre il suo file di log viene ripulito in silenzio. Il comportamento in rete è il testimone onesto; l'autodichiarazione dell'appliance no.

Remediation

Tratta qualsiasi Secure Email Gateway esposto su internet e non patchato dopo il 14 settembre come potenzialmente rootato, non semplicemente vulnerabile. Lavora la lista in ordine.

1. Sono interessato? Verifica la versione AsyncOS in esecuzione dalla CLI (version) o dalla UI web. Le release interessate sono AsyncOS 15.5 e precedenti, 16.0 e 16.5, su appliance sia fisiche sia virtuali, in ogni configurazione. Se il tuo gateway MX-facing è su una di quelle ed era raggiungibile da internet, sei nel perimetro e devi procedere come se la compromissione fosse possibile.

2. Patch — versioni corrette esatte. Aggiorna alla release AsyncOS corretta per la tua linea, verbatim dall'advisory Cisco (cisco-sa-esa-inj):

Linea interessata	Versione corretta
15.5 e precedenti	15.5.5-0141
16.0	16.0.4-3021
16.5	16.5.0-780

Non ci sono workaround — Cisco è esplicita: la patch è l'unica correzione. Patcha ogni nodo di un cluster; un singolo nodo non patchato tiene la porta aperta.

3. Non puoi patchare in quest'ora? Controlli compensativi. Non puoi mettere un firewall davanti alla superficie vulnerabile senza spegnere la posta — l'attacco viaggia sull'SMTP in ingresso. Ciò che puoi fare subito: limitare le interfacce amministrative e di management a una VLAN di gestione, stringere l'egress in modo che l'appliance raggiunga solo le destinazioni che un mail gateway usa legittimamente (i tuoi smarthost di relay, gli endpoint di update/telemetria Cisco, il DNS) e allertare su qualsiasi altra cosa, e mettere il traffico in uscita dell'appliance sotto ispezione più stretta finché non è patchata e verificata. Questi riducono il raggio d'esplosione; non chiudono il buco.

4. Caccia alla compromissione. Assumi che i log locali possano essere inaffidabili e parti dalle prove fuori dalla scatola.

• Sull'appliance (prima che possa essere manomessa, e conservandone una copia off-box): cerca nei mail_logs e nei log CLI/audit frammenti SQL, in particolare COPY, TO PROGRAM, query concatenate e altra sintassi che non ha nulla da fare in un campo di messaggio. Mappa su T1190 (Exploit Public-Facing Application) per l'injection e T1059 (Command and Scripting Interpreter) per l'esecuzione OS via COPY ... TO PROGRAM. Un log locale con buchi o con la coda troncata proprio dove dovrebbe esserci l'injection è di per sé il segnale — T1070 (Indicator Removal), ed è il motivo per cui lo confronti con una copia off-box.
• Fuori dall'appliance: nei record di firewall/NetFlow/NDR cerca il gateway che avvia sessioni in uscita che normalmente non fa — shell interattive, connessioni verso ASN mai visti, burst di DNS-over-HTTPS o DNS-tunnel (T1071, esfiltrazione T1041 su canale C2), o nuovi flussi verso lo store di posta interno e la directory (T1021 movimento laterale).
• Cerca l'appliance che invia posta non originata da una coda legittima — phishing interno dal mittente fidato (T1534 internal spearphishing).
• Controlla ogni nodo del cluster in modo indipendente; la compromissione di uno non resta su uno.

5. Eradica e verifica. Se trovi evidenza di sfruttamento, la patch non è remediation — l'attaccante aveva già root. Ricostruisci o reimmagina l'appliance da una versione nota-buona invece di fidarti di una patch in-place su una scatola che può ospitare un impianto. Ruota ogni credenziale detenuta dal gateway: credenziali di relay/smarthost SMTP, account di bind LDAP/AD, chiavi API, certificati e qualsiasi segreto nella sua configurazione — vanno considerati rubati. Solo dopo patch e rotazione delle credenziali, conferma che l'appliance sia pulita osservando il suo comportamento di rete tornare a una baseline di sola-posta, non rileggendo i log che essa controlla.

Cogliere l'appliance nell'istante in cui smette di comportarsi da appliance

Tutto quanto sopra ruota attorno a una domanda: quando un dispositivo di sicurezza fidato e in linea viene rootato e inizia a riscrivere il proprio resoconto degli eventi, cosa vede ancora la verità? La risposta è la rete, ed è la superficie per cui è stata costruita l'AI Traffic Analysis di Zero Hunt.

Gira un modello di deep learning proprietario — quattro teste di inferenza parallele per traffico sospetto, classificazione malware, identificazione del tipo di attacco e fingerprinting applicativo — addestrato su miliardi di sequenze PCAP, a oltre 2,7 Gbit/s sulla GPU dell'appliance stessa, interamente on-prem. Non chiede all'email gateway cosa è successo. Guarda cosa il gateway fa: la testa di fingerprinting applicativo sa che aspetto ha il traffico AsyncOS normale, quindi una shell interattiva, un beacon verso un ASN mai visto, un burst di DNS-tunnel o un flusso improvviso verso lo store di posta interno risultano anomali nell'istante in cui compaiono — mentre i mail_logs locali dell'appliance vengono ancora riscritti in silenzio da un avversario con root. L'unico posto che l'attaccante non può raggiungere per coprire le proprie tracce sono i pacchetti tra la scatola e tutto il resto, ed è esattamente lì che il modello guarda.

Altre due nostre capacità chiudono il cerchio attorno a un bug come questo. Il pentest generativo a 10 agenti risponde alla domanda precedente — sono davvero raggiungibile? — trattando un gateway appena esposto su internet o appena divulgato come campagna change-triggered: gli agenti Exploit e Web scrivono una catena di SQL injection per-target con un LLM locale (non un PoC pubblico preso da un feed), backtestata nell'AI Gym prima di girare, per provare se il percorso da email costruita ad arte a root esiste sulla tua appliance e versione, con l'intera esecuzione firmata ECDSA per la traccia di audit. E poiché un email gateway trasporta corrispondenza regolamentata, la sua compromissione è un evento NIS2 e GDPR — il motore di compliance mappa quel finding sui suoi 32 framework così che l'incidente e la sua remediation finiscano nel bundle di evidenze che un auditor o un regolatore chiederà. La patch chiude CVE-2026-76461. Vedere la scatola rootata sul filo, e provare la raggiungibilità prima che lo faccia un attaccante, è la parte che la patch non fa al posto tuo.