SICUREZZA

Cisco Secure Email Gateway CVE-2026-76461: patch e verifica della compromissione

CVE-2026-76461 è sfruttata attivamente: versioni coinvolte, aggiornamenti corretti e checklist per distinguere patching e incident response.

Gateway email aziendale durante la remediation della CVE-2026-76461
Indice dell'articolo

Rischio e azione: se gestite un Cisco Secure Email Gateway fisico o virtuale, verificate subito la release di AsyncOS, conservate i log e pianificate l’aggiornamento. La vulnerabilità CVE-2026-76461 è sfruttata attivamente e può consentire a un attaccante remoto non autenticato di eseguire comandi con privilegi root. Non esistono workaround.

Perché il rischio è immediato

Il problema è nella logica con cui AsyncOS analizza le email. Un messaggio preparato con istruzioni SQL malevole può attraversare il normale percorso di elaborazione del gateway; non è quindi necessario esporre su Internet la console amministrativa perché il difetto sia raggiungibile. Cisco assegna alla falla gravità critica e conferma che riguarda gli appliance Secure Email Gateway fisici e virtuali, indipendentemente dalla configurazione. Secure Email and Web Manager e Secure Web Appliance non risultano coinvolti.

Il 14 settembre 2026 anche CISA ha inserito la CVE nel catalogo KEV sulla base di evidenze di sfruttamento. Per un MSP questo cambia la priorità: non è una correzione da inserire nel prossimo ciclo ordinario, ma un’attività urgente da associare a una ricerca degli indicatori di compromissione.

Versioni interessate e aggiornamenti

La verifica deve partire dalla release installata e dal modello di erogazione:

  • AsyncOS 15.5 e precedenti: prima release corretta 15.5.5-014;
  • AsyncOS 16.0: prima release corretta 16.0.4-302;
  • AsyncOS 16.5: prima release corretta 16.5.0-780;
  • Cisco raccomanda la migrazione alla 16.5.0-780;
  • gli appliance Cisco Secure Email Cloud sono già stati aggiornati dal fornitore.

L’upgrade può essere eseguito dall’interfaccia web in System Administration → System Upgrade oppure dalla CLI con il comando upgrade. Al termine l’appliance si riavvia: prima della finestra controllate capacità, compatibilità della configurazione, ridondanza del cluster e continuità del flusso di posta.

Patching e incident response non sono la stessa attività

L’installazione della release corretta chiude l’esposizione futura, ma non dimostra che il sistema non sia già stato compromesso. Cisco suggerisce di cercare nei mail_logs istruzioni SQL sospette, compreso il pattern COPY.*TO PROGRAM, su ogni nodo del cluster. Il controllo deve includere anche firewall, proxy e sistemi di logging esterni, cercando upload inattesi dall’appliance o download da indirizzi malevoli.

Un risultato locale pulito non basta: l’accesso root può permettere all’attaccante di cancellare o nascondere le tracce. In presenza di indicatori, preservate prima le evidenze. Per un appliance virtuale Cisco raccomanda, quando possibile, di distribuire una nuova VM con release corretta, ricostruire la configurazione e rinnovare credenziali e materiale crittografico. Per un appliance fisico va coinvolto Cisco TAC.

Checklist operativa verificabile

  1. Inventariare tutti i Secure Email Gateway, inclusi nodi secondari e ambienti virtuali.
  2. Registrare versione AsyncOS, modello, ruolo nel cluster e ultima configurazione esportata.
  3. Salvare i log localmente e su una destinazione esterna prima di aggiornare.
  4. Cercare SQL sospetto nei mail_logs di ogni nodo e correlare traffico anomalo in uscita.
  5. Se non emergono indicatori, applicare la prima release corretta compatibile e documentare il riavvio.
  6. Se emergono indicatori, aprire l’incidente, isolare con cautela, preservare le prove e seguire il percorso di ricostruzione indicato da Cisco.
  7. Dopo il cambio, verificare ricezione e consegna della posta, code, TLS, antispam, quarantene e replica del cluster.
  8. Separare le interfacce di posta e gestione, limitare i servizi amministrativi a host fidati e mantenere log esterni.

Limiti della verifica

Il pattern fornito da Cisco è un indicatore non esaustivo e non sostituisce l’analisi forense. Anche la sola presenza di una release vulnerabile non prova un’intrusione. La decisione fra semplice aggiornamento e ricostruzione deve dipendere dalle evidenze raccolte, dalla criticità del gateway e dalla capacità di mantenere la posta operativa durante l’intervento.

Serve supporto per inventario, aggiornamento e verifica post-intervento? Richiedi una valutazione tecnica a MSP In Cloud.

Fonti primarie