Cisco FMC: credenziali hardcoded sfruttate

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sicurezza applicativa per team negli Stati Uniti e nell'UE

La risposta in breve

Cosa ha divulgato Cisco

Cisco ha pubblicato un advisory per CVE-2026-20316 che descrive credenziali statiche, hardcoded, per un account a bassi privilegi all'interno del Secure Firewall Management Center (FMC) Software — la console centralizzata usata per configurare e monitorare i deployment di firewall Cisco. Poiché le credenziali sono integrate, un attaccante remoto non autenticato che riesce a raggiungere l'interfaccia web del FMC può semplicemente accedere come quell'account e leggere i dati a esso disponibili. Cisco ha assegnato un punteggio base CVSS di 5.3 ma ha segnalato il problema come di gravità Alta nella pratica, perché può essere concatenato con altre debolezze del FMC per elevare i privilegi. La falla è stata segnalata da Jimi Sebree di Horizon3.ai.

Non è stata una divulgazione teorica. Il team di sicurezza prodotto di Cisco ha dichiarato di essere venuto a conoscenza di uno sfruttamento attivo a luglio 2026, rendendola uno zero-day nel momento in cui sono arrivate le patch, e la CISA ha aggiunto la CVE al proprio catalogo delle vulnerabilità sfruttate note con scadenza di rimedio al 1º agosto 2026 per le agenzie federali statunitensi. Cisco ha rilasciato hot fix per le release FMC 7.0, 7.2, 7.4, 7.6, 7.7 e 10.0, ha detto che non ci sono soluzioni alternative e ha raccomandato di ruotare tutte le credenziali, chiavi e certificati sui dispositivi interessati — un consiglio sensato, dato che l'account integrato potrebbe essere già stato usato. Se il vostro team gestisce firewall Cisco, il compito immediato è un esercizio di patch-e-rotazione; il compito più ampio, che i nostri ingegneri di audit di sicurezza affrontano come standard, è confermare che nessun altro apparato del parco nasconda un account predefinito simile.

Perché una credenziale hardcoded in un firewall è peggio di quanto sembri

Un CVSS di 5.3 non rende giustizia. Il FMC non è un apparato di frontiera — è il piano di gestione di un'intera flotta di firewall: il luogo dove si definiscono regole, politiche e segmentazione di rete. Un attaccante che ne legge la configurazione scopre esattamente com'è disposta la difesa, dove sono i varchi e quali segmenti valgono un pivot. È proprio questa informazione a rendere efficiente un'intrusione multi-fase, ed è il motivo per cui gli attaccanti puntano sempre più agli strumenti di sicurezza stessi anziché agli asset che stanno dietro.

Due proprietà rendono una credenziale integrata particolarmente insidiosa. Primo, i clienti non possono ruotarla via — fa parte del software rilasciato, per cui fino a una patch ogni deployment porta la stessa chiave. Secondo, l'account qui è a bassi privilegi per progettazione, ma Cisco ha esplicitamente osservato che può essere concatenato con altre falle del FMC per salire più in alto; un punto d'appoggio silenzioso oggi diventa controllo amministrativo domani. Per gli operatori regolati nella FinTech e nella sanità, un accesso non autorizzato alla politica del firewall non è solo un rischio di disservizio: è un fallimento di controllo da notificare, che revisori e regolatori prendono sul serio.

Continua a succedere — ed è evitabile

Le credenziali hardcoded sono tra le voci più antiche del catalogo delle debolezze — CWE-259, «Use of Hard-coded Password» — eppure continuano a riaffiorare in infrastrutture aziendali serie. Il motivo non è quasi mai che gli ingegneri non lo sappiano; è che un account di comodo aggiunto per provisioning, licenze o chiamate interne service-to-service sopravvive silenziosamente fino a una release, perché nulla nella pipeline fa fallire la build quando un segreto viene compilato.

È questa la parte risolvibile. I segreti vanno in uno store gestito — un sistema come HashiCorp Vault o il secret manager di un provider cloud —, iniettati a runtime, mai committati nel codice né impressi in un'immagine. Un gate di secret scanning nella CI intercetta quelli che sfuggono. E gli account di servizio interni, così spesso i colpevoli, dovrebbero autenticarsi con credenziali a vita breve, rotabili e legate a un'identità, non con una stringa fissa che vive per sempre. Nulla di tutto ciò è una novità; è igiene cloud e DevOps di base, che trasforma «un segreto rilasciato nel binario» da incidente plausibile a incidente impossibile.

Cosa significa per il mercato italiano e i team di sviluppo

Se gestite firewall Cisco, il percorso di risposta è chiaro: applicate la hot fix per la vostra release di FMC, ruotate ogni credenziale, chiave e certificato del dispositivo e cercate nei log l'indicatore package_info.pl / /var/tmp/license.tmp pubblicato da Cisco. Poi limitate l'interfaccia di gestione del FMC a una rete di amministrazione fidata, così che anche una falla non autenticata non sia raggiungibile da dove si trova un attaccante. Trattate il piano di gestione con la stessa disciplina di rete che applichereste a un database di produzione.

La lezione più ampia vale a prescindere dal fatto che Cisco sia nel vostro stack. Ogni team gestisce piani di gestione propri — sistemi di CI, dashboard di amministrazione, strumenti interni, console di orchestrazione —, e ciascuno è un bersaglio di alto valore che troppo spesso riceve meno attenzione del codice rivolto ai clienti. Inventariateli, verificate che nessuno sia rilasciato con account predefiniti o statici e applicate loro la stessa disciplina dei segreti che pretendete da un vendor. Se costruite voi stessi software enterprise, questo incidente è un caso di studio gratuito su a cosa servono una code review e un gate di secret scanning.

C'è anche un risvolto di procurement. «L'abbiamo valutata 5.3» e «è stata sfruttata come zero-day» descrivono lo stesso bug, e il divario è proprio il punto: i punteggi di gravità sono una posizione di partenza, non una valutazione del rischio per il vostro ambiente. Le rassicurazioni del vendor non sostituiscono la verifica, sui vostri stessi asset, che le interfacce di gestione siano blindate e prive di credenziali integrate — ciò che un penetration test indipendente è progettato appunto per accertare.

Una checklist di hardening del piano di gestione

Applicatela a ogni console di amministrazione e ogni strumento interno che gestite, non solo all'apparato interessato.

1. Applicare patch e ruotare ora. Applicate il fix del vendor, poi ruotate tutte le credenziali, chiavi e certificati su qualunque dispositivo abbia avuto un account integrato — date per scontato che la credenziale statica sia stata usata.
2. Isolare il piano di gestione a livello di rete. Limitate le interfacce di amministrazione a una rete di gestione fidata o a una VPN; non dovrebbero mai essere raggiungibili da internet aperto o dalla LAN aziendale generica.
3. Dare la caccia ad account predefiniti e statici. Inventariate apparati, immagini e strumenti interni alla ricerca di credenziali hardcoded o predefinite; trattate ogni segreto compilato in una build come un riscontro.
4. Spostare i segreti in uno store gestito. Iniettate i segreti a runtime da un vault o secret manager; non committateli mai nel codice e non imprimeteli nelle immagini dei container.
5. Vincolare la CI al secret scanning. Fate fallire la build quando una credenziale viene rilevata nel codice o in un artefatto, così che l'account di comodo non raggiunga mai una release.
6. Usare credenziali di servizio a vita breve. Date alle chiamate interne service-to-service token legati a un'identità e rotabili, invece di una stringa fissa che vive per sempre.
7. Sorvegliare gli indicatori. Allertate sugli IoC pubblicati dal vendor — qui package_info.pl con riferimento a /var/tmp/license.tmp — ed esaminate i log del piano di gestione alla ricerca di accessi anomali.

Cisco ha agito in fretta una volta nota la falla, e patch più rotazione chiude questo buco specifico. Ma ciò che vale uno spazio in redazione non è la singola CVE — è lo schema che vi sta dietro. Un segreto in un binario rilasciato è evitabile con controlli che la maggior parte dei team ha già gli strumenti per eseguire. Le organizzazioni che sfuggono alla prossima versione di questa storia sono quelle che trattano i propri piani di gestione come produzione e i propri segreti come qualcosa che una build dovrebbe rifiutarsi di compilare. Fatelo ora.

Domande frequenti

Fonti

BleepingComputer — Cisco warns of FMC static credential flaw exploited in zero-day attacks, 29 luglio 2026
SecurityWeek — Cisco Secure FMC Zero-Day Exploited in the Wild, luglio 2026
Help Net Security — Cisco FMC static credentials exploited by attackers (CVE-2026-20316), 30 luglio 2026