SICUREZZA

Cisco SD-WAN Manager CVE-2026-76504: patch urgente e controlli di compromissione

CVE-2026-76504 è sfruttata attivamente: release Cisco corrette, log da preservare e checklist operativa per proteggere il piano di controllo SD-WAN.

Piano di controllo Cisco SD-WAN protetto durante la correzione di CVE-2026-76504
Indice dell'articolo

Rischio e azione: Cisco ha corretto una vulnerabilità critica in Catalyst SD-WAN Manager, CVE-2026-76504, che permette a un attaccante remoto non autenticato di aggirare l’autenticazione delle API e ottenere privilegi amministrativi. Cisco conferma lo sfruttamento attivo; CISA ha inserito la falla nel catalogo KEV. Non esistono workaround: inventariate subito i manager, preservate i log e aggiornate a una release corretta.

Perché il piano di controllo è un bersaglio critico

Catalyst SD-WAN Manager governa configurazione, policy e visibilità dell’infrastruttura SD-WAN. Un accesso amministrativo alle API non equivale a una semplice esposizione di dati: può mettere l’attaccante nella posizione di modificare il comportamento della rete gestita. La vulnerabilità nasce dalla gestione della codifica URI nel percorso di autenticazione e riguarda il prodotto indipendentemente dalla configurazione.

La priorità aumenta quando l’interfaccia di gestione è raggiungibile da Internet o da reti ampie e poco segmentate. Limitare l’accesso amministrativo resta una misura di hardening utile, ma non sostituisce l’aggiornamento. Anche un manager non esposto pubblicamente può essere raggiunto da un attaccante che ha già ottenuto un punto d’appoggio interno.

Release corrette

La verifica deve partire dalla versione realmente installata su ogni istanza. Cisco indica questi primi rilasci corretti:

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

Le release precedenti alla 20.9 devono essere migrate a un ramo corretto. Le istanze Cisco-managed SD-WAN Cloud sono state corrette dal fornitore nella release 20.15.605 e non richiedono un intervento software del cliente; resta opportuno confermare modello di erogazione e stato contrattuale, senza assumere che una denominazione “cloud” significhi automaticamente servizio gestito da Cisco.

Patching e incident response sono attività diverse

L’upgrade chiude il percorso noto per gli attacchi successivi, ma non dimostra che il manager fosse integro prima della correzione. Prima di ruotare o cancellare i log, conservate almeno /var/log/nms/containers/service-proxy/serviceproxy-access.log e /var/log/nms/vmanage-server.log, insieme ai log di firewall, reverse proxy e sistemi di identità.

Cisco indica di cercare richieste non autorizzate che coinvolgono varianti codificate di j_security_check, per esempio /%6a_security_check, e attività associata a nomi utente che iniziano con viptela-reserved-. Questi elementi sono punti di partenza, non una firma esaustiva. La loro assenza non esclude una compromissione quando la conservazione dei log è breve o la telemetria è incompleta.

Checklist operativa

  1. Inventariare tutte le istanze Catalyst SD-WAN Manager, incluse appliance secondarie, laboratori e ambienti di disaster recovery.
  2. Registrare versione, modello di erogazione, raggiungibilità, owner e finestra di manutenzione.
  3. Esportare configurazione e backup secondo la procedura Cisco e verificarne leggibilità e data.
  4. Preservare i log locali ed esterni prima dell’upgrade; annotare fuso orario e intervallo disponibile.
  5. Cercare URI codificate anomale, account riservati inattesi, accessi API e modifiche amministrative non autorizzate.
  6. Se non emergono indicatori, installare la prima release corretta compatibile e verificare la versione effettiva dopo il riavvio.
  7. Se emergono indicatori, aprire l’incidente, limitare l’accesso di gestione, preservare le prove e coinvolgere Cisco TAC prima di una bonifica distruttiva.
  8. Dopo l’intervento, testare accesso amministrativo, policy, tunnel, telemetria, allarmi, backup e gestione dei dispositivi.
  9. Restringere stabilmente le interfacce di management a reti e host autorizzati e inviare i log a una destinazione esterna.

Limiti della verifica

Una release vulnerabile dimostra esposizione, non compromissione. Un controllo log negativo dipende da completezza, integrità e retention delle fonti disponibili. La chiusura deve quindi documentare versione iniziale e finale, backup, log preservati, query eseguite, anomalie, test funzionali e decisione esplicita tra semplice patching e gestione dell’incidente.

Devi aggiornare e verificare infrastrutture di rete senza perdere continuità operativa? Richiedi una valutazione tecnica a MSP In Cloud.

Fonti primarie