Cisco FMC CVE-2026-20316: il CVSS 5.3 che CISA ha messo in KEV

Il 29 luglio 2026 Cisco ha pubblicato l'advisory cisco-sa-fmc-static-cred-BET3Cjh. Descrive CVE-2026-20316, una credenziale statica integrata in Cisco Secure Firewall Management Center, con punteggio base CVSS v3.1 pari a 5.3. Lo stesso giorno CISA lo ha inserito nel catalogo Known Exploited Vulnerabilities. La dichiarazione del PSIRT Cisco è lunga una frase: "In July 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability." Non esiste workaround. Il punteggio dice ordinaria amministrazione, lo stato di sfruttamento dice adesso. Questo articolo spiega perché i due segnali si contraddicono e cosa farne nella coda di patching reale.

Cos'è davvero CVE-2026-20316

La vulnerabilità sono credenziali statiche di un account a basso privilegio compilate dentro il software Secure FMC. Un attaccante remoto non autenticato le usa per accedere e leggere i dati visibili a quell'account. Nessuna corruzione di memoria, nessun payload, nessun crash: un nome utente e una password validi che arrivano insieme al prodotto.

I rami interessati sono 7.0, 7.2, 7.4, 7.6, 7.7 e 10.0. L'advisory Cisco è esplicito: "there are no workarounds that address this vulnerability" — l'unica rimediazione è l'hotfix. La segnalazione è di Jimi Sebree di Horizon3.ai e, secondo BleepingComputer, Cisco non ha reso noti attore, cronologia o vittime.

FMC non è un firewall. È la console on-premise che possiede l'intero parco firewall: policy di accesso, NAT, configurazione VPN, registrazione dei device e il flusso di eventi di ogni sensore Secure Firewall / FTD registrato.

Perché la credenziale statica di Cisco FMC vale solo 5.3

Leggiamo il vettore pubblicato da Cisco:

Metrica	Valore	Cosa afferma
AV:N	Network	Raggiungibile via rete
AC:L	Low	Nessuna condizione particolare
PR:N	None	Nessun privilegio richiesto
UI:N	None	Nessuna interazione utente
S:U	Unchanged	L'impatto resta nel componente vulnerabile
C:L	Low	Perdita parziale di riservatezza
I:N / A:N	None	Nessun impatto su integrità o disponibilità

Tutto il lato accesso è al massimo della gravità — rete, nessuna autenticazione, nessuna interazione — e il punteggio resta 5.3, perché il lato impatto è un solo C:L. Il punteggio base CVSS misura una vulnerabilità isolata ed esclude deliberatamente ciò che l'attaccante ottiene combinandola con una seconda. È una scelta di progetto documentata, non un difetto dello standard. Il problema è a valle: il punteggio base è il numero che finisce nel ticketing, e quasi tutti gli SLA di patching aziendali sono agganciati a quello.

• Critical / 9.0+ — change d'emergenza, giorni.
• High / 7.0–8.9 — prossima finestra, settimane.
• Medium / 4.0–6.9 — ciclo trimestrale, fino a 90 giorni.
• Low — best effort, sulle appliance spesso mai.

CVE-2026-20316 finisce nella terza riga. Il Security Impact Rating assegnato da Cisco è invece High, proprio perché — parole di Cisco — quell'accesso può essere combinato con altre vulnerabilità FMC per elevare i privilegi. Quella correzione sta nella prosa dell'advisory, non nel numero, e la prosa non sopravvive all'export CSV verso la piattaforma di vulnerability management.

Comitato change: È un 5.3, sola lettura, e per gran parte del parco la macchina non è nemmeno esposta. Perché dovrebbe essere un change fuori ciclo? Security: Perché l'indicatore di compromissione che il vendor pubblica per questa CVE è un file che viene eseguito come root.

La catena era pubblica quattro mesi prima della CVE

A marzo 2026 Cisco ha corretto due falle critiche su FMC: CVE-2026-20079 (CVSS 10.0, bypass di autenticazione fino a root) e CVE-2026-20131. VulnCheck ne ha pubblicato l'analisi tecnica il 26 marzo. La catena documentata ha quattro passi:

Passo	Meccanismo
1	FMC crea al boot una sessione csm_processes con session ID statico invece di un UUID; resta nel database
2	La sessione viene elevata autenticandosi con credenziali macchina hardcoded (report:snortrules), ottenendo un token CSRF valido
3	L'endpoint validateLicense scrive uno script shell Makeself in /var/tmp/license.tmp
4	upgradeReadinessCall elabora quel file e lo esegue come root

Ora leggiamo la guida di rilevamento pubblicata da Cisco a luglio per il bug "5.3, sola lettura". Dall'advisory: eseguire cat /var/log/messages | grep license in expert mode; lo sfruttamento è indicato se l'output contiene /var/tmp/license.tmp.

L'indicatore di compromissione di una vulnerabilità classificata come perdita minima di riservatezza è l'artefatto del passo di esecuzione di codice come root descritto pubblicamente quattro mesi prima. Cisco ha riconosciuto l'esistenza di CVE-2026-20079 ma ha rifiutato di spiegare il rapporto fra le due, quindi l'affermazione onesta è quella stretta: la metà credenziale di una catena root FMC nota ha ricevuto una CVE propria a luglio, ha ricevuto un punteggio medio, ed era già in uso in rete al momento della pubblicazione.

La popolazione esposta su Internet è piccola: VulnCheck contava a marzo 2026 circa 300 istanze FMC su Censys e 600-700 su FOFA. Non è un numero da sfruttamento di massa. È una lista di obiettivi. Ognuno di quegli host parla a nome di una flotta.

Il bersaglio è il piano di gestione, non il firewall

Chi controlla FMC non ha bisogno di un exploit sul firewall. Ottiene il canale di push della configurazione — supportato, tracciato, previsto — verso ogni sensore registrato. Dalla console si legge l'intero set di policy (che è una mappa della rete e delle sue relazioni di fiducia), si aggiunge una regola, si cambia una traduzione NAT, si estrae la configurazione VPN, si registra un device. Nulla di tutto ciò è traffico anomalo: è il piano di gestione che fa il suo mestiere.

È la stessa forma degli incidenti già trattati su altri controller di parco: lo zero-day su VeloCloud SD-WAN Orchestrator e Cisco Unified CM CVE-2026-20230. Lo schema è abbastanza stabile da poterci pianificare contro: il controller ha punteggi più bassi, meno monitoraggio e meno patch delle cose che governa, e possiede un percorso autenticato legittimo verso tutte.

Cosa hanno cambiato KEV e la BOD 26-04 nella coda di patching

CISA ha emesso la BOD 26-04, Prioritizing Security Updates Based on Risk, il 10 giugno 2026, sostituendo il termine fisso di 14 giorni della BOD 22-01 con un modello decisionale basato sul rischio. Le scadenze dipendono ora dall'accessibilità pubblica dell'asset e dal valore che la vulnerabilità ha per l'attaccante, con il livello più stringente misurato in giorni. Le policy delle agenzie federali devono supportare il modello entro il 7 agosto 2026, con valutazione e rimediazione secondo le nuove tempistiche a partire dal 7 dicembre 2026 (la FAQ di Tenable è una lettura chiara sul modello a quattro variabili).

CVE-2026-20316 è esattamente il caso per cui la direttiva è stata scritta. Raggiungibile pubblicamente su una parte dei deployment, sfruttamento confermato, nessun workaround, e un punteggio base che uno SLA agganciato al CVSS archivierebbe nel cassetto dei 90 giorni. Se siete fuori dal perimetro federale statunitense, la direttiva resta il modello più pulito a disposizione per l'argomento che dovete portare internamente: lo stato di sfruttamento conta più del punteggio di gravità, e il trigger è l'ingresso in KEV, non la colonna CVSS.

Remediation

1. Sono interessato?

Qualunque Secure FMC / Firepower Management Center on-premise su 7.0, 7.2, 7.4, 7.6, 7.7 o 10.0 privo dell'hotfix di luglio. Il FMC cloud-delivered, gli ASA e i sensori FTD non erano interessati dalla coppia FMC di marzo; verificate il vostro modello di deployment sull'advisory Cisco invece di darlo per scontato.

• Nella UI di FMC: Help → About per versione esatta e hotfix applicati.
• Da CLI: show version, poi conferma della presenza dell'identificativo di hotfix.
• In rete: enumerate le interfacce di gestione HTTPS sulle VLAN delle appliance e fate fingerprinting della pagina di login FMC. Non fidatevi della CMDB: le appliance arrivate insieme a una business unit sono proprio quelle che mancano.

2. Patch — versioni corrette esatte

Cisco distribuisce la correzione come hotfix per ramo (verbatim dall'advisory):

Ramo	Hotfix
7.0	Cisco_Firepower_Mgmt_Center_Hotfix_GB-7.0.9.1-3.sh.REL.tar
7.2	Cisco_Secure_FW_Mgmt_Center_Hotfix_HL-7.2.11.1-4.sh.REL.tar
7.4	Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar
7.6	Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar
7.7	Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar
10.0	Cisco_Secure_FW_Mgmt_Center_Hotfix_P-10.0.1.1-2.sh.REL.tar

3. Non potete patchare subito? Controlli compensativi

Non esiste workaround del vendor, quindi tutto quello che segue riduce la raggiungibilità, non elimina la credenziale:

• Limitate l'interfaccia di gestione HTTPS di FMC a una VLAN di management con allow-list esplicita; negate per default dai segmenti utenti e server.
• Fate terminare l'accesso amministrativo su un jump host hardened con MFA. Nient'altro deve raggiungere la porta 443 dell'FMC.
• Imponete autenticazione con certificato client (mTLS) davanti alla web interface, dove il reverse proxy lo consente.
• Rimuovete NAT in ingresso e record DNS pubblici che puntano a un FMC. Visti i conteggi Censys/FOFA, è il controllo con il rapporto resa/sforzo migliore della lista.
• Allertate su ogni autenticazione riuscita verso FMC da una sorgente esterna al range del jump host.

4. Caccia alla compromissione

Prima l'indicatore del vendor, poi gli artefatti circostanti:

# IOC pubblicato da Cisco (expert mode). Un hit su /var/tmp/license.tmp indica sfruttamento.
cat /var/log/messages | grep license

# File depositati nel percorso di licensing
ls -la /var/tmp/

# Processi root che non dovrebbero esserci
ps aux | grep -E 'root|csm_processes'

Poi correlate in rete e nei log dell'appliance:

• Voci nell'access log HTTPS verso endpoint di licensing e upgrade da sorgenti fuori dal range di management.
• Eventi di autenticazione degli account di servizio integrati: il senso di una credenziale statica è che il login riesce, quindi l'assenza di fallimenti non è assenza di compromissione.
• Eventi di modifica lato sensore: deployment di policy inattesi, nuove registrazioni di device, modifiche ad ACL o NAT senza change ticket corrispondente.
• Sessioni in uscita dall'FMC verso destinazioni che non siano l'infrastruttura di update Cisco o il collector syslog.

Mappatura MITRE ATT&CK dell'attività:

Tecnica	ID
Exploit Public-Facing Application	T1190
Valid Accounts: Default Accounts	T1078.001
Unsecured Credentials	T1552
Data from Configuration Repository: Network Device Configuration Dump	T1602.002
Data from Local System	T1005

5. Eradicazione e verifica

Se l'IOC dà esito positivo, considerate compromesse le credenziali dell'intero parco gestito, non solo della console. Perimetro di rotazione:

• Account amministrativi locali e remoti di FMC, più eventuali segreti di integrazione SSO.
• Chiavi di registrazione dei device: ri-registrate i sensori se non riuscite a stabilire quando è iniziata la compromissione.
• Pre-shared key VPN e profili di accesso remoto contenuti nella configurazione FMC.
• Segreti condivisi RADIUS / TACACS+ configurati sull'appliance.
• Certificati e trust store usati dal canale FMC-sensore.

Verificate dopo la patch, in quest'ordine: hotfix applicato e appliance riavviata; nuovo grep su license senza ulteriori hit; tentativo con le credenziali precedenti alla rotazione, che deve fallire; diff della policy deployata su ogni sensore rispetto all'ultimo export noto come buono. Una compromissione del piano di gestione si chiude quando il set di policy è stato ri-validato, non quando la console è stata patchata.

Dove si colloca Zero Hunt

Una credenziale statica è invisibile agli strumenti che quasi tutti puntano su questo problema. Uno scanner basato sulle versioni riporta il banner che ha visto; non può dirvi se report:snortrules — o il suo successore sul vostro ramo — si autentica davvero sulla vostra appliance. Una coda di patching agganciata al CVSS archivia il finding a 5.3 e passa oltre. L'unico modo per saperlo è tentare il login e registrare l'esito.

È quello che fa l'agente Credential di Zero Hunt, uno dei dieci agenti coordinati dello swarm di AI generative pentest — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sotto un AI Controller. Recon fa fingerprinting delle interfacce di gestione presenti sulla VLAN delle appliance e assenti dalla CMDB; Credential prova gli account integrati e di default contro il servizio vivo, appoggiandosi al corpus SecLists con oltre 330 coppie di credenziali di default e a 21 fonti di threat intelligence sincronizzate in continuo, fra cui CISA KEV, EPSS, MITRE ATT&CK ed ExploitDB; Post-Exploit e Pivot stabiliscono cosa raggiunge davvero quel punto d'appoggio a basso privilegio — che, su un piano di gestione, è la risposta che conta. Gli exploit sono generati per singolo target da un LLM locale e sottoposti a backtest nell'AI Gym su Vulhub e Vulhub-Bench prima che una skill tocchi la produzione, e ogni esecuzione avviene in un container effimero, così a essere sollecitata è l'appliance sotto test e non la piattaforma. Poiché le campagne sono schedulate e attivate dal cambiamento, una nuova appliance che compare sul perimetro fa partire una campagna completa entro l'ora: è la differenza pratica fra trovare questa cosa in una run di validazione e trovarla nel grep IOC di Cisco.

L'argomento sul punteggio ha anche una metà compliance. Zero Hunt mappa ogni finding su 32 framework — NIS2, DORA compreso l'RTS TLPT, ISO 27001, SOC 2, NIST CSF e gli altri — con scoring pesato sulla severità guidato dall'evidenza di sfruttamento e non dalla colonna CVSS base, e firma ogni finding in ECDSA al momento della scrittura. Quando un auditor chiede perché un 5.3 è stato trattato come change d'emergenza, il bundle del Trust Center contiene l'evidenza KEV, il tentativo di validazione, il timestamp e la firma, in un unico export. È una conversazione molto più semplice che ricostruire tutto dai commenti dei ticket sei mesi dopo. Per vedere come si comporta sul vostro parco, scriveteci.