Cisco SD-WAN Manager: falla critica già sfruttata

Una falla critica in Cisco Catalyst SD-WAN Manager è stata inserita il 1° ottobre 2026 nell’elenco KEV di CISA, cioè la lista delle vulnerabilità note e già sfruttate dagli attaccanti. Per le aziende che usano questa piattaforma il messaggio è semplice: non si tratta di un rischio teorico, ma di un problema con exploit attivi che può dare accesso amministrativo remoto senza autenticazione.

Se la tua organizzazione gestisce sedi, firewall, router o connettività tramite Cisco SD-WAN, questa notizia ti riguarda direttamente perché il bersaglio non è un singolo PC, ma la “cabina di regia” della rete aziendale.

Cosa è successo

CISA, l’agenzia statunitense per la cybersicurezza, ha aggiunto alla propria lista Known Exploited Vulnerabilities la vulnerabilità CVE-2026-76504, che interessa Cisco Catalyst SD-WAN Manager. Il punteggio CVSS indicato è 9.8, quindi nella fascia di massima gravità pratica.

Il motivo dell’inserimento nel KEV è particolarmente importante: secondo le informazioni pubblicate, la vulnerabilità è già sfruttata attivamente. In altre parole, non siamo davanti a una correzione preventiva o a un difetto scoperto in laboratorio, ma a un problema che gli attaccanti stanno già utilizzando nel mondo reale.

Cisco aveva già dichiarato di essere a conoscenza di attività di sfruttamento nel settembre 2026. CISA, dopo questa conferma, ha chiesto alle agenzie federali civili statunitensi di applicare le correzioni entro il 3 ottobre 2026. Anche se questa scadenza riguarda il settore pubblico americano, è un indicatore forte dell’urgenza anche per le aziende private.

Perché questa vulnerabilità è così pericolosa

La falla consente a un attaccante remoto non autenticato di ottenere accesso al sistema con i privilegi dell’utente admin. È l’aspetto più critico della vicenda: non serve un account valido, non serve una password rubata e non serve una presenza già interna alla rete.

Secondo quanto riportato, il problema deriva da una gestione impropria della codifica URI in una richiesta HTTP. Con una richiesta API costruita appositamente, l’attaccante può aggirare l’autenticazione e presentarsi al sistema come amministratore.

Tradotto in termini aziendali: chi controlla il manager SD-WAN può potenzialmente vedere, modificare o usare il piano di gestione della rete. E quando il punto colpito è il pannello centralizzato che governa più sedi e apparati, il rischio operativo cresce molto più rapidamente rispetto a una vulnerabilità su un singolo endpoint.

Perché gli attaccanti puntano proprio a SD-WAN Manager

Le piattaforme di orchestrazione SD-WAN sono bersagli molto appetibili perché concentrano in un solo punto visibilità e controllo. Servono per configurare, monitorare e amministrare reti distribuite, filiali, collegamenti e politiche di traffico.

Questo significa che, se compromesse, possono offrire vantaggi enormi a un attaccante:

• accesso a informazioni sensibili sull’architettura di rete;
• possibilità di modificare configurazioni o instradamenti;
• opportunità di muoversi verso altre parti dell’infrastruttura;
• capacità di compromettere più sedi da un unico sistema centrale.

Non sorprende quindi che le piattaforme di gestione di rete siano sempre più presenti nelle campagne offensive. Quando una console è il “single pane of glass” dell’infrastruttura, diventa anche uno dei suoi punti di massimo valore per chi attacca.

Cosa ha pubblicato Cisco per verificare eventuali compromissioni

Cisco ha reso disponibili anche alcuni indicatori utili per le verifiche iniziali. In particolare, invita a controllare i log per individuare richieste sospette legate a j_security_check provenienti da IP sconosciuti o non autorizzati.

I percorsi indicati sono:

• /var/log/nms/containers/service-proxy/serviceproxy-access.log
• /var/log/nms/vmanage-server.log

Cisco suggerisce di cercare eventi relativi a j_security_check e, in particolare, riferimenti a utenti con nomi che iniziano con viptela-reserved-. Inoltre, tra i controlli consigliati c’è la ricerca di richieste POST verso varianti URL-encoded di /j_security_check.

È un dettaglio tecnico, ma con un significato gestionale chiaro: l’aggiornamento da solo è fondamentale, però non basta se il sistema è già stato toccato. Occorre anche verificare se ci siano state tracce di sfruttamento precedente.

Cosa ancora non sappiamo

Al momento, nelle informazioni disponibili non sono stati diffusi dettagli su:

• chi siano gli attori dietro gli attacchi;
• quante organizzazioni siano state compromesse;
• quando sia avvenuto il primo sfruttamento della vulnerabilità.

Questa mancanza di dettagli non riduce la gravità del problema. Al contrario, per le aziende è un promemoria utile: spesso le organizzazioni devono decidere e intervenire anche quando il quadro d’intelligence non è completo. Aspettare conferme ulteriori, in casi come questo, può significare arrivare tardi.

Cosa significa per la tua azienda

Se usi Cisco Catalyst SD-WAN Manager, la priorità è trattare questa vulnerabilità come un’emergenza operativa.

Ecco cosa fare in pratica.

1. Verifica subito se il prodotto è presente nel tuo ambiente
Sembra banale, ma in molte aziende il problema iniziale è l’inventario: sedi diverse, apparati gestiti da partner esterni, piattaforme ereditate da progetti precedenti. Devi sapere con certezza se Catalyst SD-WAN Manager è in uso, dove si trova e chi lo amministra.

2. Applica la release corretta senza rinvii
CISA ha inserito la vulnerabilità nel KEV proprio perché ci sono exploit attivi. Questo sposta la valutazione da “patch importante” a “intervento urgente”. Se il tuo team interno non riesce a gestire rapidamente la verifica e l’aggiornamento, conviene coinvolgere subito il fornitore o il partner IT.

3. Controlla i log indicati da Cisco
L’aggiornamento serve a chiudere la falla, ma i log servono a capire se qualcuno è già entrato. Cerca richieste anomale verso j_security_check, IP non riconosciuti e riferimenti a utenti viptela-reserved-. Se trovi elementi sospetti, non limitarti alla patch: tratta l’evento come un potenziale incidente di sicurezza.

4. Valuta l’esposizione verso Internet
Una console di gestione rete esposta più del necessario aumenta il rischio. Anche senza cambiare architettura in poche ore, è il momento giusto per verificare segmentazione, accessi consentiti, restrizioni IP, MFA dove applicabile e percorsi di amministrazione.

5. Prepara un piano di risposta se emergono segnali di compromissione
Se dai log risultano accessi sospetti, è prudente verificare configurazioni, account amministrativi, modifiche recenti, integrazioni e credenziali eventualmente collegate. In casi del genere, la differenza la fa la velocità con cui si isola il problema e si ricostruisce ciò che è accaduto.

6. Usa questo episodio per rafforzare la governance degli apparati critici
Le console di rete, i firewall manager, gli orchestratori e i sistemi di accesso remoto non possono essere gestiti come sistemi “secondari”. Devono rientrare tra gli asset da monitorare con priorità, insieme a patching, backup di configurazione e controllo degli accessi. Se vuoi strutturare meglio prevenzione e monitoraggio, ha senso rivedere le misure di sicurezza informatica e la copertura dei servizi gestiti, ad esempio con contratti di assistenza informatica.

7. Non trascurare il backup delle configurazioni
Se una piattaforma di orchestrazione viene alterata o compromessa, poter ripristinare rapidamente configurazioni affidabili è essenziale per ridurre fermo e errori. Anche per questo un piano di remote backup ben impostato resta una misura pratica, non solo “di compliance”.

La lezione più ampia: i sistemi di gestione sono un bersaglio strategico

Questa vicenda conferma una tendenza che molte PMI sottovalutano: gli attaccanti non cercano soltanto i computer degli utenti o i server più visibili. Puntano sempre più spesso ai sistemi centrali di amministrazione, perché permettono di scalare l’attacco con meno sforzo.

Per un’impresa questo significa cambiare mentalità. Non basta chiedersi se un apparato “funziona bene” o se “non ha mai dato problemi”. Bisogna chiedersi anche:

• chi lo aggiorna e con quale frequenza;
• chi controlla gli avvisi del produttore;
• dove finiscono i log e chi li guarda;
• quali sistemi sono davvero critici se un attaccante ottiene privilegi amministrativi.

La sicurezza non è solo protezione del dato finale, ma anche del punto da cui si governa l’infrastruttura.

Domande frequenti

Questa vulnerabilità riguarda tutte le aziende?

No. Riguarda in modo diretto chi utilizza Cisco Catalyst SD-WAN Manager. Però il principio vale per tutti: le console di gestione centralizzata sono asset critici e vanno trattate come tali.

Se aggiorno il sistema, sono automaticamente al sicuro?

Non del tutto. L’aggiornamento chiude la vulnerabilità, ma non dice se il sistema sia già stato sfruttato. Per questo è fondamentale controllare i log e cercare indicatori di compromissione.

Una PMI deve preoccuparsi anche se non è un grande gruppo?

Sì. Le PMI con più sedi, VPN, apparati gestiti centralmente o dipendenza forte dalla rete possono subire impatti operativi molto seri anche da un singolo accesso amministrativo non autorizzato.