Il 30 settembre 2026 Cisco ha pubblicato un avviso per CVE-2026-76504, una vulnerabilità di tipo authentication bypass in Cisco Catalyst SD-WAN Manager (l'ex vManage), valutata con CVSS 9.8. La particolarità che deve far alzare l'attenzione è nella frase che Cisco stessa ha messo nero su bianco: il produttore è venuto a conoscenza di sfruttamento attivo a settembre 2026, scoprendolo durante la gestione di un caso di assistenza tecnica. In altre parole, qualcuno aveva già un accesso amministrativo non legittimo prima che esistesse una patch.

Cosa è successo

Il difetto sta nel modo in cui il componente gestisce la codifica degli URI nelle richieste HTTP. Una regola di autenticazione pensata per proteggere un singolo endpoint API può essere aggirata inviando il percorso di login (j_security_check) con caratteri codificati in percentuale, ad esempio %6a al posto della lettera "j". Il risultato, secondo la ricostruzione di Field Effect e dell'avviso Cisco, è l'accesso all'API con privilegi di amministratore, senza credenziali e senza interazione dell'utente.

Le versioni corrette indicate da Cisco, per ciascun ramo, sono:

  • 20.9.10.1 per il ramo 20.9;
  • 20.12.8.2 per il ramo 20.12;
  • 20.15.6.1 per il ramo 20.15;
  • 20.18.4.1 per il ramo 20.18;
  • 26.1.2.1 per il ramo 26.1;
  • 26.2.1 per il ramo 26.2.

Chi usa release precedenti alla 20.9 non ha un aggiornamento "in place": deve migrare a una release corretta. Il servizio gestito da Cisco (SD-WAN Cloud) risulta già aggiornato. Cisco dichiara che non esistono workaround: le misure di contenimento descritte sotto servono solo a ridurre l'esposizione fino al patching. Né Cisco né le fonti consultate attribuiscono gli attacchi a un gruppo specifico, e al momento non sono noti numero e identità delle vittime.

Perché questo bug è diverso da un "normale" bug di autenticazione

Un controller SD-WAN non è un server qualunque. SD-WAN Manager è il piano di gestione che distribuisce configurazioni, policy e certificati a tutti i router e gli edge dell'organizzazione. Chi ottiene un accesso amministrativo al Manager può in teoria modificare le policy di instradamento, creare utenti, spostare traffico o preparare un accesso persistente su ogni sede collegata. È lo stesso motivo per cui abbiamo già trattato in passato altre falle del Manager, come la CVE-2026-20262 di giugno: la differenza di oggi è che l'attacco non richiede nemmeno un account di partenza. Secondo la fonte, si tratta di una delle otto vulnerabilità SD-WAN di Cisco tracciate come sfruttate nel 2026, un dato che dice più di qualsiasi singolo CVSS sulla pressione a cui questa famiglia di prodotti è sottoposta.

Cosa significa per le aziende italiane

SD-WAN è molto diffuso nelle reti con molte sedi: catene retail, studi professionali distribuiti, aziende manifatturiere con stabilimenti e magazzini, enti sanitari, gruppi bancari e assicurativi. In Italia molte PMI non gestiscono il Manager in proprio ma lo ricevono da un system integrator o da un operatore di telecomunicazioni, e proprio questo è il punto critico: chi è responsabile dell'aggiornamento? Se l'istanza è ospitata o amministrata da un fornitore, il cliente deve chiedere per iscritto se la versione è già stata portata a una release corretta e se sono stati controllati i log. Il rischio concreto non è solo tecnico: un accesso amministrativo al controller può tradursi in un incidente significativo ai sensi della NIS2.

Ragionamento da consulente: per un soggetto essenziale o importante, la scoperta di un compromesso attivo sul piano di gestione della rete va trattata come potenziale incidente. L'impianto della NIS2 italiana (D.Lgs. 138/2024) prevede una pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza di un incidente significativo e una notifica entro 72 ore; per chi tratta dati personali, un accesso non autorizzato che coinvolga quei dati può inoltre configurare una violazione da valutare ai fini della notifica al Garante entro 72 ore ai sensi del GDPR. Anche per i soggetti DORA, un controller di rete compromesso tocca la gestione del rischio ICT e la classificazione degli incidenti. Non occorre notificare ogni patch mancata, ma occorre sapere in fretta se l'istanza era esposta e se i log mostrano le tracce descritte più sotto: questa verifica è il discrimine tra un aggiornamento ordinario e un incidente da gestire.

C'è poi una considerazione sulla postura. Il fatto che l'attacco sia stato scoperto da un caso di supporto, e non da un controllo di sicurezza del cliente, suggerisce che in molte organizzazioni il Manager non è nel perimetro del monitoraggio. È una lacuna comune: si monitorano firewall e server, ma il controller SD-WAN resta un'appliance "che funziona" e che nessuno guarda.

Cosa fare subito

  • Inventario: individuare tutte le istanze di Catalyst SD-WAN Manager (on-premises, ospitate da terzi, laboratorio) e la release in uso. Per le istanze gestite da un fornitore, chiedere conferma scritta dello stato.
  • Patch: aggiornare alla release corretta del proprio ramo (elenco sopra); se si è su una versione precedente alla 20.9, pianificare la migrazione con priorità alta.
  • Riduzione dell'esposizione: nessuna interfaccia di gestione (porte 443, 22, 830) deve essere raggiungibile da internet; limitare l'accesso a host noti e mettere i componenti di controllo dietro firewall, come indicato da Cisco.
  • Caccia alle tracce: cercare nei log /var/log/nms/containers/service-proxy/serviceproxy-access.log richieste a j_security_check con varianti codificate (ad esempio %6a) provenienti da IP sconosciuti, e in /var/log/nms/vmanage-server.log attività di autenticazione con utenti che iniziano per viptela-reserved-.
  • Se si trova qualcosa: non spegnere e cancellare. Raccogliere l'output di request admin-tech, aprire un caso con Cisco TAC citando la CVE, ruotare credenziali e certificati gestiti dal Manager e valutare gli obblighi di notifica (CSIRT Italia, Garante) con il responsabile della sicurezza e il DPO.
  • Dopo la patch: verificare utenti, policy e template creati di recente e confrontarli con l'ultima configurazione nota valida, perché la patch chiude la porta ma non rimuove ciò che un attaccante ha già lasciato.

Il punto

La sequenza è nota: un componente di gestione centrale, esposto o raggiungibile, un bug di autenticazione banale nell'idea e devastante nell'effetto, sfruttamento prima della patch. Il contesto di mercato la conferma: gli attacchi ai prodotti di rete e di accesso remoto sono ormai la normalità, non l'eccezione. Per le organizzazioni italiane la domanda utile non è "siamo bersagli interessanti?", ma "chi risponde entro 24 ore se il nostro controller di rete viene compromesso, e con quali log?".