Il 30 settembre 2026, alle 4 del pomeriggio ora di Riad, Cisco ha pubblicato un bollettino di sicurezza per la CVE-2026-76504 in Cisco Catalyst SD-WAN Manager, il sistema che le aziende con più filiali usano per gestire l'intera rete di filiali da un'unica schermata. Il punteggio di gravità è 9.8 su 10, lo sfruttamento non richiede né account né password, Cisco afferma di essere venuta a conoscenza di uno sfruttamento attivo nel corso di settembre e non esiste un workaround. Lo stesso giorno l'Autorità Nazionale per la Cybersicurezza dell'Arabia Saudita (NCA) ha emesso l'avviso 2026-7889 con gravità Critica, chiedendo alle organizzazioni di esaminare il bollettino e applicare l'aggiornamento.

La domanda chiave non è tecnica: chi applica la patch?

Due settimane fa abbiamo scritto di una vulnerabilità sfruttata in un'altra appliance Cisco, quella che governa identità e accessi, e lì abbiamo trattato le basi della gestione delle vulnerabilità. Questa volta la domanda più importante non è tecnica. Potreste non gestire affatto la vostra rete di filiali: un operatore di telecomunicazioni o un'azienda IT potrebbe gestirla per voi con un contratto di servizio gestito. In tal caso, chi aggiorna il sistema stanotte, chi verifica se qualcuno è entrato prima dell'aggiornamento e cosa dice il vostro contratto se nessuna delle due cose avviene?

Cosa ha pubblicato davvero Cisco

La notizia ha poche ore, quindi questi fatti provengono direttamente dal bollettino di Cisco e dall'avviso della NCA, non da articoli di stampa:

  • Prodotto: Cisco Catalyst SD-WAN Manager, in passato noto come vManage. Il bollettino afferma che è interessato indipendentemente da come è configurato.
  • Causa: una gestione impropria della codifica URI nelle richieste HTTP consente a una richiesta appositamente costruita di aggirare una regola di autenticazione pensata per proteggere uno specifico endpoint dell'API, così l'attaccante raggiunge l'API con i privilegi dell'utente admin.
  • Prerequisito: nessuno. Un attaccante remoto, non autenticato, e un punteggio base CVSS di 9.8.
  • Stato: sfruttata attivamente. Cisco PSIRT afferma di essere venuta a conoscenza dello sfruttamento a settembre 2026 e che la vulnerabilità è stata individuata durante la risoluzione di un caso di assistenza del Cisco Technical Assistance Center.
  • Workaround: nessuno. La soluzione è l'aggiornamento a una versione corretta.
  • Avviso locale: avviso NCA 2026-7889, datato 30 settembre 2026. Elenca 14 settori interessati, in pratica tutti, da commercio e investimenti, finanza ed economia e sanità fino a istruzione, trasporti e manifattura.

Le versioni corrette, secondo il bollettino:

Ramo di release attualePrima versione corretta
Precedente alla 20.9Migrare a una versione corretta
20.920.9.10.1
20.1220.12.8.2
20.1520.15.6.1
20.1820.18.4.1
26.126.1.2.1
26.226.2.1

Notate la prima riga. Chi è su una versione precedente alla 20.9 non ha davanti un piccolo aggiornamento, ma il passaggio a un altro ramo di release. Richiede pianificazione, e non può aspettare.

Perché proprio questo sistema

Una rete SD-WAN collega filiali, magazzini e sede centrale attraverso qualunque connessione disponibile, e tutto viene gestito da un unico sistema centrale. È lì che si scrivono le policy: quale traffico passa su quale collegamento, quale filiale può raggiungere quale sistema e quali impostazioni vengono inviate al router di ogni sede. Una modifica al centro raggiunge ogni filiale. È proprio questo lo scopo.

La stessa caratteristica è il pericolo. Chi raggiunge l'API di questo sistema con privilegi di admin non ha davanti un singolo dispositivo, ma la console che gestisce la configurazione dell'intera rete. Il punto vendita di una filiale, il collegamento con il magazzino e l'accesso al sistema contabile fuori dalla sede possono passare tutti su una rete controllata da questo sistema. Va messo in cima all'elenco degli asset critici, per quanto possa sembrare lontano dalla gestione quotidiana.

Cloud di Cisco o vostro data center? Questo decide chi deve muoversi

Il bollettino distingue due modalità di gestione del sistema, e la differenza è molto concreta:

  • Nel cloud di Cisco: il bollettino afferma che la vulnerabilità colpisce SD-WAN Manager indipendentemente dalla configurazione e descrive due casi cloud. Negli ambienti Cisco Catalyst SD-WAN Cloud Hosted, Cisco ha già applicato la mitigazione tramite restrizione degli accessi, ma una mitigazione non è una correzione, quindi l'aggiornamento a una versione corretta della tabella sopra resta necessario, e dovreste chiedere chi lo esegue. In Cisco SD-WAN Cloud (Cisco Managed) la release 20.15.605 risolve la vulnerabilità, Cisco afferma che non è richiesta alcuna azione da parte dell'utente e la versione si può verificare tramite la funzione Help nell'interfaccia del servizio. Solo in quest'ultimo caso l'aggiornamento spetta al fornitore. Il vostro compito resta ottenere una conferma scritta e chiedere che i log vengano esaminati per il periodo precedente.
  • On-premise, presso di voi o nel data center del vostro fornitore: qui nessuno aggiornerà il sistema al posto vostro, a meno che il contratto non lo preveda. Fino all'aggiornamento, la mitigazione descritta da Cisco consiste nel limitare l'accesso al sistema da reti non sicure come internet e nel proteggere i componenti di controllo SD-WAN dietro un dispositivo di filtraggio come un firewall.

Quindi la prima domanda non è se usate Cisco. È dove gira il vostro sistema di gestione della rete e a chi spetta aggiornarlo. Se solo il fornitore conosce la risposta, questa è la prima lacuna da colmare, e non è tecnica.

Un aggiornamento non vi dice se qualcuno è entrato prima

Cisco è venuta a sapere dello sfruttamento a settembre e ha pubblicato la correzione l'ultimo giorno del mese. In altre parole, la vulnerabilità veniva sfruttata prima che esistesse un aggiornamento da applicare. Aggiornare stanotte chiude la porta. Non vi dice se qualcuno l'ha già attraversata lasciandosi dietro un account o una modifica alla configurazione.

Per questo Cisco ha pubblicato indicatori che il vostro team IT o il vostro fornitore devono cercare in due log specifici del sistema, serviceproxy-access.log e vmanage-server.log:

  • Richieste a j_security_check da indirizzi IP sconosciuti o non autorizzati.
  • Qualsiasi carattere codificato in URI nel percorso della richiesta, come %6a_security_check, dove %6a è la lettera j codificata. È così che l'exploit aggira la regola di autenticazione. Cisco sottolinea che %6a è solo un esempio: può essere usata la codifica di qualsiasi singolo carattere nella richiesta, quindi il team deve cercare ogni variante codificata di j_security_check, non solo %6a.
  • In particolare in vmanage-server.log: richieste a j_security_check da indirizzi sconosciuti per nomi utente che iniziano con viptela-reserved-. Si tratta di account di servizio integrati nel sistema, quindi la presenza del nome nel log non è di per sé un segno di compromissione. Ciò che conta è la provenienza sconosciuta.

Cisco avverte inoltre che questi indicatori possono talvolta comparire durante il normale funzionamento, quindi vanno confrontati con l'attività abituale della rete prima di trarre conclusioni.

La stessa lezione è emersa questa settimana con due vulnerabilità critiche di Citrix NetScaler che l'Agenzia statunitense per la Cybersicurezza e la Sicurezza delle Infrastrutture (CISA) ha aggiunto al proprio catalogo Known Exploited Vulnerabilities il 27 settembre. La CISA ha dichiarato che attori malevoli le stanno sfruttando attivamente in tutto il mondo, ha incoraggiato le organizzazioni a cercare segni di compromissione prima di applicare la patch, ove possibile, e ha affermato che qualsiasi organizzazione che sospetti una compromissione dovrebbe preservare le prove forensi prima di applicare gli aggiornamenti, perché gli aggiornamenti possono cancellare le tracce di quanto accaduto. La regola vale anche qui: verificate, conservate una copia dei log, poi aggiornate, senza lasciare che la verifica diventi un motivo per rimandare l'aggiornamento di giorni.

Se la vostra rete è un servizio gestito: cosa dice il vostro contratto?

Gli Essential Cybersecurity Controls della NCA, edizione 2024, sono vincolanti per gli enti governativi e le loro società collegate, e per i soggetti del settore privato che possiedono, gestiscono od ospitano Infrastrutture Nazionali Critiche. La NCA incoraggia vivamente tutte le altre organizzazioni del Regno a utilizzarli. Anche se la vostra azienda non è vincolata, sono il riferimento locale più chiaro su cosa deve contenere il contratto di qualsiasi fornitore che gestisca una parte della vostra tecnologia:

  • Nei contratti con terze parti il cui malfunzionamento potrebbe incidere sui vostri dati o servizi, compresi gli accordi sui livelli di servizio: riservatezza e cancellazione sicura dei vostri dati al termine del servizio, procedure di comunicazione in caso di incidente di cybersicurezza e l'obbligo per la terza parte di applicare i vostri requisiti e le vostre politiche di cybersicurezza (controllo 4-1-2).
  • In particolare nei contratti con fornitori di outsourcing IT e di servizi gestiti: una valutazione dei rischi di cybersicurezza, con controlli di mitigazione confermati, prima della firma, e i centri di servizi gestiti di cybersicurezza per il monitoraggio e le operazioni che usano l'accesso remoto devono trovarsi interamente all'interno del Regno (controllo 4-1-3).
  • Nella gestione delle vulnerabilità: classificare le vulnerabilità per gravità e correggerle secondo tale classificazione, abbonarsi a fonti affidabili per le notizie sulle nuove vulnerabilità e verificare gli aggiornamenti in un ambiente non di produzione prima di applicarli (controllo 2-10-3).

Notate cosa non dicono i controlli sulla gestione delle vulnerabilità: non fissano alcuna scadenza per applicare un aggiornamento critico. Quel numero va scritto nel vostro contratto. Altrimenti il fornitore applica la patch quando può, non quando serve a voi.

Un messaggio da inviare oggi al vostro fornitore

Non serve essere tecnici per porre queste domande, né aspettare una riunione. Chiedete le risposte per iscritto:

  • La nostra rete funziona su Cisco Catalyst SD-WAN Manager? E dove gira: nel cloud di Cisco, presso di noi o nel vostro data center?
  • Su quale versione si trova, e quando sarà aggiornato alla versione corretta, con data e ora?
  • L'interfaccia di gestione è raggiungibile da internet in questo momento? Se sì, avete limitato l'accesso fino all'aggiornamento?
  • Avete controllato i due log indicati da Cisco alla ricerca degli indicatori pubblicati e ne avete conservato una copia prima di aggiornare? Cosa avete trovato?
  • Chi ci ha informato per primo di questo avviso: voi o una notizia che abbiamo letto? E qual è la procedura concordata per avvisarci la prossima volta?

L'ultima domanda è la più importante. Se avete saputo dell'avviso da un articolo e non dal vostro fornitore, il problema è più grande di questa singola vulnerabilità.

Il punto di vista di Origami

Noi sviluppiamo sistemi aziendali. Non vendiamo né gestiamo apparati di rete. Ma ogni sistema che sviluppiamo per un cliente con più filiali gira su una rete che non abbiamo progettato: il punto vendita della filiale invia al server, il magazzino aggiorna le scorte, la fattura elettronica parte verso la piattaforma. E la risposta abituale alla domanda su chi applica le patch alla rete è: il fornitore si occupa di tutto. È una risposta rassicurante, e non è una risposta.

Per un imprenditore saudita, leggiamo questa vulnerabilità come un promemoria: l'outsourcing sposta il lavoro, ma non la responsabilità. Un servizio gestito è la scelta giusta per molte aziende, a patto che il contratto contenga tre elementi misurabili: una scadenza definita per applicare gli aggiornamenti critici, una notifica scritta di ogni avviso che riguarda i vostri sistemi e un rapporto dopo ogni incidente che indichi cosa è stato verificato e cosa è stato trovato. Queste clausole non costano nulla a un buon fornitore, e smascherano un fornitore debole prima che lo faccia una vulnerabilità.

In sintesi

  • Se gestite Cisco Catalyst SD-WAN Manager presso di voi o presso il vostro fornitore, l'aggiornamento alla versione corretta è un intervento urgente, non programmato, e le versioni precedenti alla 20.9 richiedono il passaggio a un ramo corretto.
  • Fino all'aggiornamento: bloccate l'accesso al sistema da internet e mettete i componenti di controllo dietro un firewall, come descritto nel bollettino.
  • Controllate entrambi i log e conservatene una copia prima di aggiornare, perché lo sfruttamento è iniziato prima della pubblicazione della correzione.
  • Se la rete è un servizio gestito, inviate oggi le domande sopra e, al prossimo rinnovo, aggiungete al contratto una scadenza per gli aggiornamenti critici e una procedura di notifica.

Fonti