Un firewall che si riavvia da solo, a comando di un attaccante qualsiasi su Internet, non regala accesso alla rete interna, ma può fare altrettanto male: se l'appliance è anche il concentratore VPN, ogni riavvio significa dipendenti remoti scollegati, sedi isolate e un perimetro che per qualche minuto non filtra nulla. È lo scenario della CVE-2026-76418, una vulnerabilità di Cisco Secure Firewall ASA e FTD che Cisco ha confermato essere sfruttata attivamente.

Cosa è successo

Il 28 ottobre 2026 Cisco ha pubblicato l'avviso cisco-sa-asaftd-tunnel-dos-s6mgkb75 per una falla nel servizio Remote Access SSL VPN di ASA e FTD. Si tratta di errori logici nella gestione delle richieste quando su un tunnel group è configurata l'autenticazione secondaria. Un attaccante remoto e non autenticato, senza nemmeno bisogno di un login VPN riuscito, può far riavviare il dispositivo, provocando un denial of service.

Cisco ha dichiarato di essere venuta a conoscenza di tentativi di sfruttamento nell'ottobre 2026, senza fornire dettagli su autori, bersagli o frequenza. Secondo la sintesi di Rescana, la CISA ha inserito la vulnerabilità nel catalogo KEV il 29 ottobre; ad oggi non risultano indicatori di compromissione né firme di rilevamento pubblicate.

Non è la prima volta, quest'anno, che il servizio VPN di questi apparati finisce nel mirino per un problema di disponibilità. In un avviso di agosto, rilanciato da WaterISAC, Cisco segnalava un altro DoS sfruttato sullo stesso tipo di servizio (CVE-2026-20349, CVSS 8,6) con hotfix dedicati. Sono due falle distinte, con condizioni di esposizione diverse: chi ha applicato gli hotfix di agosto non è automaticamente coperto da quelli di ottobre.

I dati essenziali

  • Vulnerabilità: CVE-2026-76418, Cisco Secure Firewall ASA Software e FTD Software, servizio Remote Access SSL VPN.
  • Gravità: CVSS 8,6 (alta); impatto solo sulla disponibilità, nessuna esecuzione di codice né accesso ai dati.
  • Sfruttamento: attivo, secondo Cisco; inserita nel KEV della CISA (29 ottobre).
  • Quando si è vulnerabili: servono tre condizioni insieme: versione vulnerabile, login SSL VPN raggiungibile, autenticazione secondaria configurata su un tunnel group. Se è attivo tunnel-group-list enable vanno controllati tutti i tunnel group, incluso DefaultWEBVPNGroup; se non lo è, basta verificare quest'ultimo.
  • Non interessati: Cloud-delivered Firewall, Cloud-delivered FMC, Secure Access e Secure FMC.
  • Release corrette ASA: 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 oppure 9.24.10.1 (secondo il ramo in uso).
  • Release corrette FTD: 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.1.
  • Mitigazione temporanea: se DefaultWEBVPNGroup non usa l'autenticazione secondaria, no tunnel-group-list enable; altrimenti rimuovere l'autenticazione secondaria (no secondary-authentication-server-group), con un indebolimento della postura di sicurezza della VPN. Cisco raccomanda comunque l'aggiornamento.

Cosa significa per le aziende italiane

I firewall ASA e FTD sono tra gli apparati perimetrali più diffusi nelle aziende italiane di medie dimensioni, negli studi professionali strutturati, negli enti locali e nelle strutture sanitarie, spesso gestiti da un integratore esterno. L'autenticazione secondaria sulla VPN (tipicamente RADIUS o un secondo fattore) è inoltre una configurazione molto comune proprio perché è ciò che consulenti e auditor raccomandano. Il paradosso è evidente: la misura introdotta per rafforzare l'accesso remoto è la condizione che rende raggiungibile il difetto.

Il rischio concreto non è il furto di dati, ma la continuità operativa. Un attacco ripetuto di riavvii può rendere inutilizzabile il lavoro da remoto, interrompere i collegamenti site-to-site e, nelle realtà che usano lo stesso firewall per segmentare reti OT o sanitarie, creare effetti a catena. Per un soggetto NIS2 (D.Lgs. 138/2024) un'interruzione significativa di un servizio può configurare un incidente significativo, con pre-notifica al CSIRT Italia entro 24 ore e notifica entro 72 ore dal momento in cui se ne ha conoscenza; per i soggetti finanziari il quadro è analogo con DORA. Vale la pena ricordare che l'obbligo scatta per l'impatto sul servizio, non per la sofisticazione dell'attacco: un DoS "banale" può essere comunque notificabile.

C'è poi un aspetto organizzativo. Quando il firewall è gestito da un fornitore, la domanda da fare oggi è semplice: avete verificato se l'autenticazione secondaria è attiva e quale release gira? Contrattualmente, la gestione delle vulnerabilità del fornitore rientra tra gli obblighi di sicurezza della catena di approvvigionamento che la NIS2 richiede di governare; ottenere una risposta scritta è già una evidenza utile.

Cosa fare subito

  • Individuare tutti gli ASA e gli FTD con accesso remoto SSL VPN esposto e verificare se è configurata l'autenticazione secondaria su uno o più tunnel group (compreso DefaultWEBVPNGroup).
  • Aggiornare alla release corretta per il proprio ramo (elenco sopra) e confermare la versione dopo il riavvio; per FTD controllare la policy RAVPN distribuita in FMC o FDM.
  • Se non si può aggiornare subito, applicare la mitigazione temporanea indicata da Cisco dopo averla testata, valutandone l'impatto sulla sicurezza degli accessi.
  • Non dare per risolta la questione se si sono già applicati gli hotfix di agosto: sono vulnerabilità diverse.
  • Monitorare riavvii anomali e crash dell'appliance, e correlarli ai log delle connessioni VPN in ingresso, anche in assenza di indicatori pubblici.
  • Valutare la pubblicazione dell'interfaccia VPN solo verso geografie e reti necessarie e predisporre un accesso alternativo per le emergenze.
  • Annotare le decisioni nel registro degli incidenti e delle vulnerabilità, utile in sede di verifica NIS2.