Cisco Catalyst SD-WAN Manager CVE-2026-76504: una richiesta codificata e sei admin

Il 30 settembre Cisco ha pubblicato l'advisory cisco-sa-sdwan-webauth-xr8beuuU per CVE-2026-76504, un bypass di autenticazione con CVSS 9.8 in Cisco Catalyst SD-WAN Manager — la piattaforma che un tempo si chiamava vManage, la console unica che distribuisce policy, configurazioni e immagini software a ogni router edge di una fabric SD-WAN. Lo stesso advisory conferma la parte che trasforma una nota di patch in un'emergenza: "Nel settembre 2026 il Cisco PSIRT è venuto a conoscenza dello sfruttamento attivo di questa vulnerabilità". CISA l'ha inserita nel catalogo delle Known Exploited Vulnerabilities lo stesso giorno, con scadenza federale a tre giorni. Non esiste workaround. Un attaccante non autenticato che raggiunge l'interfaccia web invia una singola richiesta con un carattere codificato in esadecimale nel path e ottiene accesso API con privilegi di amministratore alla macchina che governa l'intera rete geografica.

In breve

CVE	CVE-2026-76504
Prodotto / versioni colpite	Cisco Catalyst SD-WAN Manager (ex vManage); release precedenti alle build corrette qui sotto · le versioni precedenti alla 20.9 vanno migrate
Corretta in	20.9.10.1 · 20.12.8.2 · 20.15.6.1 · 20.18.4.1 · 26.1.2.1 · 26.2.1 (Cloud 20.15.605); advisory cisco-sa-sdwan-webauth-xr8beuuU, 30-09-2026
CVSS	9.8 Critica · CVSS 3.1 · assegnato da Cisco · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Sfruttata attivamente	Sì — Cisco PSIRT a conoscenza dello sfruttamento attivo a settembre 2026
CISA KEV	Aggiunta 2026-09-30; scadenza federale 2026-10-03 (BOD 26-04, triage forense richiesto)
Advisory ufficiale	cisco-sa-sdwan-webauth-xr8beuuU

Cosa rompe davvero CVE-2026-76504

Il difetto è classificato CWE-177, gestione impropria dell'encoding. SD-WAN Manager applica una regola di autenticazione davanti alla propria web application: le richieste verso i path protetti dovrebbero essere intercettate prima di raggiungere il servlet che elabora un login. Il problema è che il componente che decide se una richiesta richiede autenticazione e quello che poi la gestisce non concordano su cosa dica l'URL. Si codifica in percent-encoding un carattere su cui la regola effettua il match — %6a al posto di una j letterale, per esempio — e la richiesta scivola oltre la regola come qualcosa che quest'ultima non riconosce, per poi essere ri-decodificata nel path reale dal livello sottostante. Il controllo di autenticazione non scatta mai. La richiesta arriva all'endpoint j_security_check già trattata come sessione privilegiata.

Secondo l'analisi di Rapid7 e gli indicatori di Cisco, lo sfruttamento lascia una traccia riconoscibile in due log:

• Richieste POST a j_security_check con caratteri URL-encoded come %6a, da indirizzi IP non riconosciuti.
• Attività legata ad account di servizio interni il cui nome inizia con viptela-reserved- — identità riservate con cui un operatore normale non effettua mai il login.

Entrambe compaiono in serviceproxy-access.log e vmanage-server.log. Le metriche sono lo scenario peggiore: vettore di rete, bassa complessità, nessun privilegio, nessuna interazione utente, impatto pieno su riservatezza, integrità e disponibilità — da qui il 9.8. Il punteggio è stato assegnato da Cisco; il record NVD riporta lo stesso vettore, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Perché un SD-WAN Manager compromesso è peggio dell'ennesima CVE sul perimetro

La tentazione è archiviarla con gli altri bollettini della settimana sugli apparati di perimetro e andare oltre. Significa fraintendere cosa sia SD-WAN Manager. Un concentratore VPN o un load balancer compromesso è un punto d'appoggio davanti al patrimonio IT. SD-WAN Manager è ciò che programma quel patrimonio. Custodisce i certificati che arruolano i router edge, distribuisce template di dispositivo e policy, e può preparare e distribuire immagini software a ogni nodo gestito. Admin sul manager non è una poltrona sul perimetro: è il sistema di distribuzione dell'intera fabric.

"La trattiamo come le altre CVE sugli apparati — isolo la macchina, applico la patch, vado avanti." "Le altre macchine trasportano traffico. Questa configura le macchine che trasportano il traffico. Se un attaccante ha avuto admin qui, dai per scontato che su ogni edge gestito sia stata distribuita la configurazione che volevano."

È la differenza che conta per il perimetro dell'incidente. Un manager compromesso può riscrivere routing e policy tra le sedi, arruolare un edge fraudolento, disabilitare o deviare l'ispezione, e farlo attraverso il canale di gestione legittimo, così che le modifiche sembrino operazioni ordinarie. In termini MITRE ATT&CK il manager è una superficie T1072 (Software Deployment Tools) — esattamente il tipo di punto di distribuzione fidato che gli avversari prediligono, perché una sola compromissione si propaga a tutto ciò che gestisce. Il piano di gestione SD-WAN di Cisco è anche un bersaglio ricorrente: questo è un bug distinto dalla catena downgrade-and-revert di CVE-2026-20182 di inizio anno, e arriva pochi giorni dopo un bypass di autenticazione quasi identico nell'orchestratore VeloCloud di Arista. Il piano di controllo è dove si concentra l'attenzione.

Una classe ricorrente: regole di auth che leggono l'URL in modo diverso dal backend

Tolta l'etichetta del vendor, CVE-2026-76504 è un caso da manuale di una classe di bug che continua a uscire: una regola di autenticazione o di routing in prima linea e l'handler di back-end normalizzano o decodificano il path in modo diverso, così una codifica artefatta significa un path per il guardiano e un altro per il componente che agisce. Lo schema si ripresenta ovunque un proxy, un middleware o un filtro di autenticazione stiano davanti a un'applicazione:

Prodotto	CVE	Il disallineamento
Apache Solr	CVE-2024-45216	Una finta "terminazione" aggiunta a qualsiasi path API aggirava il plugin di autenticazione PKI
Traefik	CVE-2025-66490	Bypass di normalizzazione del path (CWE-436): le richieste eludevano le regole di router e middleware
Apache Shiro	CVE-2020-13933	Un path di richiesta appositamente costruito aggirava il filtro di autenticazione

La lezione difensiva vale ben oltre Cisco, ed è il motivo per cui questa sezione precede l'elenco delle correzioni: l'autorizzazione deve agire sul path pienamente decodificato e canonicalizzato che l'handler userà davvero, non sulla stringa grezza così come è arrivata. Qualsiasi progetto in cui una regola di auth a match di prefisso e un back-end che decodifica possano vedere due URL diversi è a un trucco di encoding da questo esito. Quando valuti un apparato, tratta "il livello di auth è un componente separato dall'app" come una domanda da verificare, non come una rassicurazione.

Remediation

Cisco non offre workaround e la voce KEV richiede triage forense: considera ogni SD-WAN Manager raggiungibile da internet come presunto bersaglio e lavora i passi in ordine. La raccolta delle evidenze viene prima dell'aggiornamento.

1. Sono esposto?

• Verifica la release del tuo SD-WAN Manager. Ogni build precedente alle versioni corrette qui sotto è vulnerabile; le release precedenti alla 20.9 non ricevono fix e vanno migrate.
• Stabilisci se l'interfaccia web del manager (TCP 443 / 8443) è raggiungibile da dove non deve esserlo strettamente: internet, una VLAN utenti, un segmento guest. Il bug non richiede credenziali né feature attive; la raggiungibilità è l'unica precondizione.
• Inventaria chi raggiunge il manager oggi, non chi lo schema di rete dice che possa raggiungerlo.

2. Patch — release corrette esatte (da cisco-sa-sdwan-webauth-xr8beuuU)

Ramo di release	Prima release corretta
Precedente alla 20.9	Migrare a una release corretta (nessun fix)
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1
In cloud	20.15.605

Non applicare l'aggiornamento prima di aver raccolto le evidenze al punto 4 — il triage forense che la voce KEV impone dipende da log che l'upgrade può sovrascrivere.

3. Non puoi applicare la patch subito? Controlli compensativi

• Togli immediatamente l'interfaccia di gestione da internet — è la guida provvisoria di Cisco stessa — e vincolala a una rete di management dedicata. SD-WAN Manager non avrebbe mai dovuto essere esposto a internet.
• Metti davanti un reverse proxy o un WAF che rifiuti caratteri ambigui o doppiamente codificati nel path e blocchi le richieste a j_security_check da sorgenti non fidate. Trattalo come un rallentatore per quel vettore specifico, non come una correzione — un vero workaround non esiste.
• Applica rate-limit e alert sugli endpoint di autenticazione, così un tentativo di bypass è quantomeno rumoroso.

4. Cerca segni di compromissione (fallo prima dell'upgrade)

• Preserva per primo lo stato: serviceproxy-access.log, vmanage-server.log, uno snapshot della configurazione e un technical support bundle. Portali fuori dalla macchina.
• Cerca nei log d'accesso le POST a j_security_check con caratteri percent-encoded (es. %6a) da IP non familiari, e qualsiasi attività sotto account che iniziano con viptela-reserved- (T1190 accesso iniziale via applicazione pubblica, T1078 uso di account validi/riservati senza un login precedente).
• Confronta template di dispositivo, policy ed elenco degli edge arruolati con una baseline nota-buona — l'azione più preziosa di un manager compromesso è distribuire alla fabric (T1072 software deployment tools). Cerca template nuovi o modificati, arruolamenti di edge inattesi e modifiche di configurazione senza alcun ticket.
• Verifica la cancellazione dei log e le connessioni in uscita dal manager verso destinazioni mai viste prima (T1070 rimozione degli indicatori).

5. Bonifica + verifica

• Se trovi un indicatore, dai per compromesso l'intero manager e ricostruiscilo da un'immagine nota-buona, invece di ripulirlo sul posto. Una macchina che distribuisce all'intera fabric non è da trattare con fiducia dopo essere stata violata.
• Ruota tutto ciò che il manager custodisce: i certificati e le chiavi usati per arruolare e autenticare gli edge, le credenziali amministrative e API, e ogni segreto di integrazione. Rivalida la configurazione effettivamente in esecuzione su ciascun edge rispetto alla tua baseline, non rispetto a ciò che il manager ora dichiara.
• Invalida le sessioni attive e forza la ri-autenticazione.
• Dopo la patch, riverifica con un test di sfruttamento indipendente — un pentest manuale o un penetration test automatizzato — che il bypass di encoding non raggiunga più j_security_check sulla tua build, invece di fidarti del fatto che la stringa di versione sia cambiata.

Dove un red team autonomo cambia questo problema specifico

Guarda cosa la stringa di versione corretta non può dirti. Non può dirti se la richiesta codificata di un attaccante abbia già raggiunto l'endpoint di autenticazione sulla tua build e topologia specifiche, se il manager fosse esposto a un segmento a cui non doveva esserlo, o se la patch abbia davvero chiuso l'ambiguità di encoding sulla tua macchina invece di aver solo incrementato il numero. Il CVSS 9.8 misura il bug in astratto; sul tuo manager non dice nulla. E nella finestra di sfruttamento non c'era alcun proof-of-concept pubblico con cui provare — gli attacchi avvenivano proprio perché una tecnica funzionante esisteva solo nelle mani dell'attaccante.

È lì che un red team AI autonomo che gira on-premise sui propri modelli privati guadagna il suo posto. Lo sciame a 10 agenti di Zero Hunt — Recon, Exploit, Web, Pivot e gli altri — scrive una prova per-target con un LLM locale invece di cercare un PoC pubblico che ancora non esiste, la collauda nell'AI Gym prima che tocchi la produzione e, poiché le campagne sono change-triggered, una nuova interfaccia di gestione esposta richiama una campagna completa entro l'ora. Dopo la patch, rilancia la prova per rispondere all'unica domanda che il numero di build non può: la correzione ha tenuto su questo manager, dal segmento da cui un attaccante partirebbe davvero? Ogni evidenza è firmata Ed25519 e concatenata in hash al momento della scrittura, così "abbiamo testato questa release" è un record, non un ricordo.

La metà difensiva discende da ciò che rende pericoloso questo bug: una volta che l'attaccante ha admin sul manager, i log del manager sono un documento scritto dall'avversario, e le configurazioni malevole distribuite alla fabric viaggiano sul canale di gestione legittimo. La macchina che ha registrato l'intrusione è la macchina che l'intruso controlla — quindi il traffico di rete è l'unico testimone onesto. Il modello di AI Traffic Analysis di Zero Hunt, quattro teste di inferenza addestrate su miliardi di sequenze PCAP e in esecuzione sulla GPU dell'apparato senza che alcun dato lasci la sede, legge il beacon post-exploitation verso un ASN mai visto e il traffico di gestione fuori-schema verso gli edge mentre accade, non nel digest SIEM del mattino dopo.

Poiché l'SD-WAN trasporta traffico regolamentato tra le sedi, un manager compromesso è un evento di notifica ai sensi dell'articolo 23 NIS2 e di DORA, con un orologio che parte da quando vieni a conoscenza dell'incidente — e il supervisore metterà alla prova la data di awareness dichiarata confrontandola con i tuoi log. La mappatura continua di ogni scansione, finding e remediation sui 34 framework, con ogni record firmato al momento della scrittura e i report firmati ECDSA, trasforma "dimostra che stavi testando questa interfaccia e avresti visto l'intrusione" in un bundle firmato che precede la domanda. Il pentest annuale non può affermarlo; mappare il dovere di test del NIS2 a una validazione continua e change-triggered sì. Parlaci di come testare il tuo piano di controllo SD-WAN sul calendario dell'attaccante invece che su quello dell'auditor.