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

🛡️ Executive Summary

• CVE-2026-76461 consente a un attaccante remoto non autenticato di ottenere esecuzione di comandi root inviando una email appositamente costruita.
• Cisco conferma sfruttamento attivo, nessun workaround e possibili compromissioni anche nel servizio Secure Email Cloud; raccomandata la ricostruzione delle appliance violate.
• AWS corregge CVE-2026-86830 in TEAM: utenti autenticati potevano ottenere privilegi temporanei non previsti sugli account gestiti da IAM Identity Center.

Cisco Secure Email Gateway è sotto sfruttamento attivo attraverso una vulnerabilità critica che può trasformare una normale email in esecuzione di comandi con privilegi root sull’appliance. La falla CVE-2026-76461, valutata CVSS 9,8, risiede nella logica di parsing di AsyncOS e non richiede autenticazione né interazione dell’utente. Cisco affianca alla patch una più ampia release di hardening che corregge altre cinque classi di vulnerabilità fino a CVSS 9,8. Nello stesso ciclo di sicurezza, AWS ha corretto CVE-2026-86830 in Temporary Elevated Access Management, soluzione open source collegata a IAM Identity Center: un problema differente ma accomunato dallo stesso rischio, quello di trasformare un componente deputato al controllo degli accessi in un punto di escalation.

Una email costruita ad hoc può diventare una shell root su Cisco Secure Email Gateway

La vulnerabilità più urgente è descritta nell’advisory ufficiale Cisco dedicato a CVE-2026-76461 e interessa Cisco Secure Email Gateway fisici e virtuali indipendentemente dalla configurazione. Il difetto nasce da una validazione insufficiente nella logica che analizza i messaggi di posta. Un aggressore remoto non autenticato può inviare attraverso l’appliance una email contenente istruzioni SQL opportunamente costruite; l’iniezione consente di eseguire statement arbitrari e, nella condizione peggiore, arrivare all’esecuzione di comandi con privilegi root sul sistema operativo sottostante. È una superficie particolarmente critica perché il gateway email è progettato per ricevere traffico da Internet: il dato rilevante non è quindi soltanto la gravità teorica della SQL injection, ma il fatto che il vettore malevolo coincide con la funzione primaria del dispositivo. Cisco conferma inoltre che nel settembre 2026 il PSIRT è venuto a conoscenza di sfruttamento attivo. La situazione differisce quindi dal precedente ciclo Secure Email del 2 settembre, nel quale Cisco aveva corretto due vulnerabilità S/MIME capaci di esporre il plaintext dei messaggi cifrati senza segnalare attacchi in corso.

Cisco cerca nei mail_logs ma avverte che root può cancellare le prove

Cisco fornisce un indicatore relativamente semplice per iniziare il triage: gli amministratori devono esaminare i mail_logs alla ricerca di istruzioni SQL sospette, compreso il pattern COPY.*TO PROGRAM. Nei cluster il controllo deve essere eseguito su ogni singolo nodo. Ma lo stesso vendor avverte che questo indicatore non può essere considerato sufficiente. Dopo lo sfruttamento, l’attaccante dispone di privilegi root e può quindi cancellare o alterare log e altre evidenze locali. Cisco raccomanda per questo di confrontare i dati dell’appliance con firewall e log di rete conservati esternamente, cercando upload inattesi verso indirizzi esterni o download provenienti da infrastrutture sospette. La distinzione è importante perché il semplice aggiornamento non dimostra che un dispositivo sia tornato affidabile. È lo stesso problema già emerso quando Cisco Secure Firewall Management Center era stato sfruttato da cluster che installavano web shell, Cyclops Blink e strumenti preparatori a ransomware: quando un apparato di sicurezza raggiunto dall’attaccante può essere controllato con privilegi elevati, la remediation deve estendersi allo stato del sistema e non fermarsi alla CVE.

Leggi anche: Cisco FMC violata attraverso credenziali statiche e inserita nel catalogo KEV

Nessun workaround: Cisco raccomanda di ricostruire le appliance virtuali compromesse

Per CVE-2026-76461 non esistono workaround. Le release corrette sono AsyncOS 15.5.5-014 per il ramo 15.5 e precedenti, 16.0.4-302 per il ramo 16.0 e 16.5.0-780 per il ramo 16.5; Cisco raccomanda espressamente la migrazione a quest’ultima. La risposta diventa più drastica se esistono elementi di compromissione. Per le appliance virtuali on-premises il vendor consiglia innanzitutto di preservare le informazioni forensi e successivamente distribuire una nuova VM con software corretto, ricostruire la configurazione, rinnovare credenziali e materiale crittografico e monitorare il sistema. Non viene quindi suggerita una semplice patch in-place come soluzione sufficiente per un host potenzialmente controllato da root. Anche la topologia deve essere rivista: Cisco raccomanda di separare le interfacce dedicate alla posta da quelle di management, limitare l’accesso amministrativo ai soli host fidati e conservare i log su un sistema esterno. Il quadro continua una sequenza di problemi critici nelle appliance di sicurezza Cisco: ad agosto Secure Workload e Crosswork avevano ricevuto hardening release con vulnerabilità fino a CVSS 10, confermando quanto questi sistemi debbano essere trattati come infrastrutture privilegiate e non come semplici componenti perimetrali.

Cisco Secure Email Cloud era già aggiornato ma sono emersi possibili compromessi

L’advisory contiene un dettaglio particolarmente rilevante per il modello SaaS. Cisco dichiara di avere già aggiornato tutti i dispositivi Cisco Secure Email Cloud alla versione 16.5.0-780, ma aggiunge di aver condotto un’indagine di threat intelligence sui sistemi del servizio e di aver contattato direttamente i clienti per i quali sono stati identificati indicatori di possibile compromissione. Il vendor afferma di essere impegnato nelle attività di remediation e recovery e raccomanda ai clienti coinvolti di rinnovare credenziali e materiale crittografico installato sulle appliance. Non è quindi corretto descrivere la vulnerabilità come un problema confinato ai deployment on-premises, anche se nel cloud aggiornamento e gestione dell’infrastruttura rientrano nell’operatività Cisco. Il passaggio evidenzia un limite ricorrente del modello managed: il provider può applicare rapidamente la correzione, ma il cliente deve comunque gestire gli effetti derivanti dall’eventuale compromissione delle proprie identità e dei propri segreti.

La hardening release aggiunge cinque classi di vulnerabilità fino a CVSS 9,8

Parallelamente alla falla già sfruttata, Cisco ha pubblicato una Security Hardening Release dedicata a Secure Email Gateway e Secure Email and Web Manager che raccoglie problemi individuati internamente attraverso i normali processi di testing e frontier AI models. Cisco raggruppa le singole vulnerabilità per classe CWE: CVE-2026-76440 copre path traversal e problemi di risoluzione dei percorsi; CVE-2026-76441 riguarda controlli di accesso insufficienti; CVE-2026-20353 include errori nella gestione del ciclo di vita delle risorse, deserializzazione e inizializzazione; CVE-2026-76443 raccoglie command injection, SQL injection, code/eval injection e XSS; CVE-2026-76442 riguarda input numerici non correttamente limitati che possono portare a consumo eccessivo di risorse. Quattro gruppi raggiungono CVSS 9,8, mentre l’ultimo arriva a 7,5. Il modello riprende quello utilizzato da Cisco nelle recenti release per IOS XE, dove sette categorie di vulnerabilità erano state aggregate per CWE e corrette attraverso un unico ciclo di hardening. Anche qui non sono disponibili workaround: Secure Email Gateway deve essere portato almeno a 15.5.5-014 o 16.5.0-780, mentre Secure Email and Web Manager richiede 15.5.5-006 o 16.5.0-429.

AWS TEAM poteva concedere privilegi temporanei superiori a quelli previsti

Il bollettino AWS riguarda una superficie differente ma ugualmente privilegiata. AWS descrive CVE-2026-86830 come un’assegnazione errata dei privilegi in Temporary Elevated Access Management (TEAM), soluzione sample open source utilizzata insieme ad AWS IAM Identity Center per concedere accessi amministrativi temporanei agli account cloud. Nelle versioni precedenti alla 1.5.1, un utente già autenticato e dotato di accesso a livello applicativo poteva ottenere privilegi temporanei non previsti sugli account AWS gestiti da TEAM. Non si tratta quindi di una compromissione remota senza credenziali né di una falla nel servizio IAM Identity Center in sé: il problema è nel software TEAM e richiede già un’identità valida. L’impatto può però essere significativo perché il prodotto esiste precisamente per governare il momento nel quale un utente passa da privilegi ordinari a privilegi elevati. AWS ha corretto il problema nella versione 1.5.1 e raccomanda esplicitamente di aggiornare anche fork e codice derivato, senza indicare workaround alternativi. La questione si inserisce in un’area già delicata: AWS ha recentemente mostrato come persino l’automazione dei permessi richieda profili iniziali restrittivi per evitare finestre di privilegio eccessivo.

Continua con:

• Vulnerabilità AWS e Cisco sfruttate attivamente mostrano il rischio delle componenti privilegiate
• LiteLLM espone chiavi e credenziali IAM quando un gateway AI viene compromesso

Gateway di sicurezza e sistemi IAM diventano bersagli perché controllano la fiducia

Cisco Secure Email Gateway e AWS TEAM non condividono codice, architettura o modello di sfruttamento, ma hanno una caratteristica comune: occupano una posizione dalla quale possono decidere cosa è affidabile e chi può fare cosa. Il gateway Cisco riceve e analizza la posta prima che raggiunga l’organizzazione; TEAM determina quando un’identità può assumere privilegi elevati negli account AWS. Quando una vulnerabilità colpisce questi livelli, l’impatto supera spesso quello del singolo servizio. Nel caso Cisco il segnale più grave è già presente: sfruttamento attivo e accesso root. Gli amministratori non devono quindi limitarsi a verificare la versione di AsyncOS, ma devono cercare indicatori di compromissione anche nei log esterni e considerare la ricostruzione delle appliance quando il controllo del sistema non può più essere garantito. Nel caso AWS la priorità è differente: identificare tutte le installazioni TEAM inferiori alla 1.5.1, comprese copie e fork che potrebbero non ricevere automaticamente la correzione. Il punto comune è operativo. Una patch corregge il codice, ma non revoca automaticamente una credenziale già sottratta, non elimina una persistence installata con root e non riduce retroattivamente un privilegio già concesso. Per i componenti che gestiscono posta, identità e accessi amministrativi, il patch management deve quindi essere accompagnato dalla verifica dello stato di fiducia dell’intera infrastruttura.