Cisco Talos ha pubblicato il 10 settembre un aggiornamento sullo sfruttamento attivo di due vulnerabilità del Secure Firewall Management Center (FMC), la console da cui le organizzazioni configurano e governano i propri firewall Cisco. Sono stati individuati tre distinti gruppi di attività post-compromissione, riconducibili sia ad attori statali sia alla criminalità informatica. Uno di essi è arrivato a distribuire il ransomware Qilin.

Il dettaglio che merita attenzione non è il punteggio della falla più grave. È da quale delle due sono entrati gli attaccanti che hanno cifrato i sistemi.

Le due vulnerabilità

CVE-2026-20079 ha punteggio CVSS 10.0, il massimo. È un bypass dell'autenticazione nell'interfaccia web di FMC che consente a un attaccante remoto e non autenticato di eseguire file di script sul dispositivo e ottenere accesso root al sistema operativo sottostante. La CISA l'ha inserita nel proprio catalogo KEV il 9 settembre, fissando al 12 settembre il termine per le agenzie federali statunitensi.

CVE-2026-20316 ha punteggio CVSS 5.3, cioè gravità media. Consente a un attaccante remoto non autenticato di accedere al dispositivo con un account a bassi privilegi e leggere dati sensibili, e può essere concatenata con altre vulnerabilità di FMC per elevare i privilegi. Era già finita nel catalogo KEV a fine luglio, e ne avevamo scritto allora.

Entrambe sono corrette dagli hotfix già rilasciati da Cisco, che ha annunciato per la settimana prossima una release più ampia di irrobustimento.

I tre gruppi osservati

UAT-12197 ha sfruttato CVE-2026-20079 per installare web shell in JSP e un esecutore di comandi basato su archivio JAR, usandoli per interrogare i database interni di FMC ed estrarre dati di autenticazione e credenziali.

UAT-11823 ha sfruttato entrambe le falle. Ha installato una reverse shell basata su netcat e due script bash il cui scopo era raccogliere le configurazioni dei dispositivi gestiti, oltre a una variante di Cyclops Blink, impianto ELF modulare già attribuito in passato al gruppo statale russo Sandworm.

UAT-11988 è, con alta confidenza secondo Talos, un operatore ransomware. È entrato tramite CVE-2026-20316, quella da 5.3. Da lì ha condotto una ricognizione estesa dell'ambiente della vittima usando gli strumenti nativi di FMC, in modalità living off the land: ha installato strumenti di tunneling per mantenere l'accesso, raccolto credenziali, costruito la lista degli endpoint da cifrare, disattivato gli strumenti di sicurezza e infine distribuito Qilin su sistemi selezionati.

Il punto che il CVSS non misura

Qui ci sono due lezioni che vale la pena separare dai fatti.

La prima riguarda cosa si perde davvero. FMC non è un firewall: è la console che governa i firewall. Chi la compromette non ottiene soltanto root su un server — ottiene la topologia della rete. Le regole di un parco firewall sono la mappa più accurata che esista di dove stanno i dati importanti, quali segmenti esistono, chi può parlare con chi e quali eccezioni sono state concesse nel tempo e mai revocate. Non a caso UAT-11823 ha scritto script specifici per esportare le configurazioni dei dispositivi gestiti: non è esfiltrazione di dati, è ricognizione perfetta, consegnata in formato già strutturato.

Da lì, per un operatore ransomware, la fase più lenta e rumorosa di un attacco — capire dove sono i sistemi che contano — diventa una lettura di file di configurazione.

La seconda riguarda come si assegnano le priorità. Il cluster che ha portato il ransomware è entrato da una vulnerabilità di gravità media. Nella maggior parte dei processi di gestione delle patch che si incontrano nelle aziende italiane esistono livelli di servizio legati alla criticità: le critiche entro sette giorni, le alte entro trenta, le medie entro novanta, le basse quando capita una finestra. Con quello schema, una 5.3 su un sistema di gestione può restare aperta per un trimestre.

Il CVSS misura l'impatto tecnico della falla considerata isolatamente. Non sa dove si trova il sistema che la ospita. Su un piano di gestione della sicurezza, qualsiasi accesso autenticato è per definizione un accesso privilegiato, perché quel sistema esiste proprio per amministrare gli altri. Una falla «media» che consente di autenticarsi su FMC non è equiparabile a una falla media su un server applicativo interno, e trattarle con lo stesso livello di servizio è un errore di categoria, non di severità.

Cosa significa per le aziende italiane

Il Secure Firewall Management Center è diffuso nelle aziende medio-grandi e nelle pubbliche amministrazioni italiane, spesso installato e gestito da un integratore esterno. Da qui derivano due esposizioni tipiche.

La prima è l'accessibilità dall'esterno. Le console di gestione vengono frequentemente rese raggiungibili da Internet per comodità operativa: il fornitore che deve intervenire fuori orario, il team distribuito su più sedi, il contratto di manutenzione che prevede accesso remoto. È una scelta che in condizioni normali non produce conseguenze e che, davanti a un bypass di autenticazione non autenticato, trasforma un sistema interno in un bersaglio pubblico.

La seconda è la catena di responsabilità. Se FMC lo gestisce un fornitore, l'azienda spesso non sa quale versione sia in esercizio né riceve i bollettini Cisco. La verifica va richiesta esplicitamente e per iscritto, perché è l'unica evidenza che resta se qualcosa va storto.

Sul piano normativo, per i soggetti che rientrano nel perimetro NIS2 (recepita in Italia con il D.Lgs. 138/2024) la gestione delle vulnerabilità e la sicurezza della catena di fornitura sono fra le misure minime richieste, e in caso di incidente significativo valgono gli obblighi di notifica al CSIRT Italia: pre-allerta entro 24 ore dalla conoscenza, notifica entro 72 ore. Se dalla compromissione derivasse un accesso a dati personali, si aggiungerebbe la notifica al Garante ai sensi dell'art. 33 GDPR, con lo stesso termine di 72 ore.

Qilin, va ricordato, non è un nome astratto per chi lavora in Italia: è lo stesso gruppo responsabile dell'attacco a Retelit, con le conseguenze che ha avuto sulla catena di fornitura della pubblica amministrazione.

Cosa fare subito

  • Applicare gli hotfix già disponibili per entrambe le CVE, senza attendere la release di irrobustimento annunciata da Cisco per la settimana prossima. La 20316 va trattata con la stessa urgenza della 20079, perché è quella da cui è entrato il ransomware.
  • Verificare che l'interfaccia web di FMC non sia raggiungibile da Internet. Se lo è, limitarne l'accesso a una VPN o a un elenco ristretto di indirizzi di origine, come misura immediata e indipendente dalla patch.
  • Cercare indicatori di compromissione: file JSP non previsti nelle directory web di FMC, archivi JAR estranei alla distribuzione, processi netcat, script bash non riconducibili al fornitore, strumenti di tunneling, connessioni in uscita anomale dal server di gestione.
  • Considerare compromesse tutte le credenziali presenti su FMC o utilizzabili da esso e ruotarle: account amministrativi della console, credenziali dei dispositivi gestiti, chiavi API, account di servizio e di integrazione con altri sistemi.
  • Esportare le configurazioni dei dispositivi gestiti e confrontarle con una baseline nota, cercando regole aggiunte, eccezioni nuove o oggetti di rete non riconosciuti.
  • Controllare i log di accesso di FMC nel periodo precedente all'aggiornamento. Se risultano ruotati, troncati o mancanti, trattare l'assenza come un segnale e non come un caso.
  • Rivedere i livelli di servizio di patching per i sistemi del piano di gestione — console di firewall, EDR, backup, gestione identità, RMM — svincolandoli dal solo punteggio CVSS: su questi sistemi qualsiasi falla che consenta autenticazione o lettura di configurazioni va trattata come critica.
  • Se l'organizzazione rientra nel perimetro NIS2 e vi sono evidenze di compromissione, attivare la procedura di notifica al CSIRT Italia rispettando il termine di pre-allerta di 24 ore, e valutare in parallelo l'obbligo di notifica al Garante.

Il filo che lega i tre gruppi osservati da Talos è che nessuno di loro ha dovuto portarsi dietro molto: uno strumento di gestione compromesso fornisce già le credenziali, la mappa e i comandi per usarle. È il motivo per cui, sul piano di gestione, la domanda giusta non è quanto è grave la vulnerabilità, ma cosa può fare chi entra.