Arista Networks ha pubblicato il 22 settembre 2026 un avviso di sicurezza per una falla critica in VeloCloud Orchestrator (VCO), il pannello di controllo della sua piattaforma SD-WAN ereditata dall’acquisizione del business VeloCloud da Broadcom. La vulnerabilità, identificata come CVE-2026-93952, ha ottenuto il punteggio massimo possibile secondo lo standard CVSS 3.1: 10.0 su 10. Arista stessa conferma che il bug era già sfruttato attivamente prima della divulgazione pubblica, il che lo colloca nella categoria delle vulnerabilità zero-day. Per i team di sicurezza di rete europei, la falla riporta alla ribalta un problema che si ripete con frequenza crescente nel 2026: l’eredità tecnica delle acquisizioni nel settore del networking enterprise può trasformarsi in un varco aperto per gli attaccanti.
Il caso è particolarmente delicato perché VeloCloud Orchestrator non è un prodotto periferico: gestisce la configurazione e l’instradamento del traffico per migliaia di filiali aziendali collegate tramite dispositivi VeloCloud Edge. Un attaccante che compromette l’orchestratore ottiene, in teoria, una porta d’accesso verso l’intera rete SD-WAN che quell’istanza amministra. Di seguito ricostruiamo cosa è successo, chi è coinvolto, come rispondere e cosa aspettarsi nelle prossime settimane.
Cos’è CVE-2026-93952 e perché preoccupa i team di rete
Secondo l’avviso ufficiale Arista Security Advisory 0183, la falla riguarda esclusivamente le installazioni on-premise di VeloCloud Orchestrator, il prodotto noto in precedenza come “VeloCloud Orchestrator by Broadcom”. Il problema consente a un attaccante remoto di accedere a funzionalità interne privilegiate del sistema, con impatto diretto sull’host VCO. Arista descrive lo scenario peggiore in modo netto: uno sfruttamento riuscito può compromettere la riservatezza, l’integrità e la disponibilità dell’orchestratore e dei dati che gestisce, inclusi inventario dei dispositivi, configurazioni di rete, certificati e materiale crittografico.
Un dettaglio tecnico che aggrava il quadro riguarda la scoperta del bug: Arista specifica che il problema è stato scoperto esternamente ed è noto per essere sfruttato attivamente, una formula che nel linguaggio degli advisory di sicurezza indica quasi sempre che l’azienda è stata avvisata da un cliente o da un ricercatore dopo aver osservato attività di compromissione reale, non da un test interno o da una divulgazione responsabile pianificata. Le versioni ospitate e dedicate di VCO, gestite direttamente da Arista in cloud, risultano già corrette: il rischio ricade quindi per intero sulle organizzazioni che gestiscono l’orchestratore sui propri server.
Il punteggio CVSS 10.0 e la classificazione CWE-20
Il vettore CVSS 3.1 pubblicato da Arista è AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, che tradotto in linguaggio corrente significa: attacco eseguibile da remoto via rete, complessità di attacco bassa, nessun privilegio richiesto, nessuna interazione dell’utente necessaria, un impatto che attraversa il confine di sicurezza del componente e conseguenze massime su riservatezza, integrità e disponibilità. È la combinazione che giustifica il punteggio pieno di 10.0.
Arista ha pubblicato anche il punteggio secondo lo standard più recente, CVSS 4.0, che risulta leggermente più basso: 9.5, con vettore CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. La differenza tra i due punteggi non è un errore: CVSS 4.0 valuta la complessità di attacco come alta anziché bassa, perché il framework aggiornato considera anche il prerequisito tecnico dello sfruttamento, ovvero il possesso della parte pubblica del certificato di autenticazione del dispositivo VeloCloud Edge. È un promemoria utile per chi lavora con la sicurezza: i due standard non sono intercambiabili e leggere solo il numero senza il vettore può portare a conclusioni sbagliate sulla reale gravità pratica.
Dal punto di vista della classificazione, Arista attribuisce la falla alla categoria CWE-20, Improper Input Validation, ovvero convalida impropria dei dati in ingresso. È una delle categorie di debolezza più comuni nel software di rete enterprise e ricorre spesso nei bollettini di sicurezza di apparati VPN e SD-WAN pubblicati nel corso del 2026, come vedremo più avanti nel confronto con altri casi recenti.
Versioni interessate e stato delle patch
L’avviso elenca quattro filoni di rilascio (release train) coinvolti, con le rispettive versioni massime vulnerabili. Al momento della pubblicazione, Arista ha reso disponibili correzioni solo per due dei quattro filoni: la 5.2.3 e la 6.4.2. Le release 6.1.x e 7.0.x restano scoperte, con Arista che promette aggiornamenti “nel tempo” man mano che le patch vengono completate. Per chi gestisce un filone non più supportato, l’unica strada indicata dall’azienda è contattare direttamente il supporto tecnico (TAC) per discutere un percorso di aggiornamento.
| Filone di rilascio | Versioni vulnerabili | Versione corretta | Stato patch al 24/09/2026 |
|---|---|---|---|
| 5.2.x | fino a 5.2.3.15 | 5.2.3.16 e successive | Disponibile |
| 6.1.x | fino a 6.1.3.7 | non ancora pubblicata | In sviluppo |
| 6.4.x | fino a 6.4.2.7 | 6.4.2.8 e successive | Disponibile |
| 7.0.x | fino a 7.0.0.2 | non ancora pubblicata | In sviluppo |
| VCO Hosted / Dedicated | tutte (gestite da Arista) | già aggiornate | Completata |
Arista precisa inoltre che i prodotti basati su EOS, il sistema operativo che fa da spina dorsale agli switch e router del marchio, non sono coinvolti in alcun modo: la lista delle piattaforme non affette copre decine di famiglie di switch, dai modelli 7010 fino ai sistemi 7800R4 di fascia alta. È un elemento importante per evitare inutili allarmismi: chi utilizza Arista solo per lo switching di data center non deve intervenire su questo fronte, il problema riguarda in modo specifico e isolato l’orchestratore SD-WAN.
Come avviene lo sfruttamento: la catena d’attacco
L’avviso descrive con precisione insolita le condizioni necessarie perché un sistema sia realmente esposto, un dettaglio che aiuta i team difensivi a capire in fretta se devono intervenire con urgenza massima o possono programmare la patch con calma relativa. VCO risulta esposto quando è configurata l’autenticazione basata su certificato tra il dispositivo VeloCloud Edge e l’orchestratore, una configurazione diffusa ma non universale negli ambienti SD-WAN enterprise.
A quel punto, per portare a termine l’attacco servono due soli elementi aggiuntivi: l’accesso alla parte pubblica del certificato di autenticazione del dispositivo Edge (che, essendo pubblica per definizione, non è un segreto particolarmente difficile da ottenere per chi ha già una minima visibilità sulla rete o sul traffico) e l’accesso di rete all’interfaccia web di VCO. Non sono richieste credenziali di alcun tipo, né a livello di tenant né a livello di operatore. È esattamente questa combinazione, nessuna autenticazione più superficie web raggiungibile, a spiegare perché Arista classifica la falla come critica e perché la raccomandazione principale, in assenza di patch immediata, sia restringere l’accesso all’interfaccia di VCO alle sole reti amministrative fidate.
Va detto con chiarezza che, secondo la ricerca disponibile al momento della pubblicazione di questo articolo, non risultano ancora attribuzioni pubbliche a un gruppo di minaccia specifico, né stime verificate del numero di istanze VCO esposte su internet. Chi scrive analisi di sicurezza dovrebbe evitare di inventare cifre in assenza di scansioni verificabili: quello che è certo, perché lo dichiara Arista stessa, è che lo sfruttamento attivo è già avvenuto prima della divulgazione.
Gli indicatori di compromissione pubblicati da Arista
Un aspetto che distingue questo avviso da molti bollettini generici è il livello di dettaglio forense fornito. Arista ha pubblicato indicatori di compromissione (IoC) specifici raccolti durante le indagini sugli incidenti già osservati, invitando gli operatori a verificarli immediatamente sui propri sistemi VCO on-premise.
File sospetti da cercare sull'host VCO:
/usr/local/sbin/.vcnode.js
/usr/local/sbin/vc-sysmond
/etc/systemd/system/vc-sysmon.service
Hash MD5 noto malevolo:
dc78e206eaeadec59fc5801fe4556bd0
Header HTTP anomalo nei log nginx:
x-vc-opt
Indirizzi IP associati ad attivita malevola:
142.93.149.77
104.248.126.159Arista raccomanda di esaminare i log di accesso web di VCO alla ricerca di percorsi URL insoliti, caratteri codificati, riferimenti a servizi interni o locali e picchi anomali di richieste, incrociando i tempi con i log applicativi e di sistema del backend. Tra i segnali da non ignorare figurano richieste in ingresso da IP noti come malevoli, traffico HTTP o HTTPS in uscita non atteso dall’host VCO, modifiche di configurazione sensibili non riconducibili ad attività amministrativa documentata ed esecuzione di comandi, creazione di file o esportazioni di database non pianificate. Se anche uno solo di questi indicatori viene trovato, l’azienda chiede esplicitamente di preservare lo stato del sistema prima di qualunque intervento e di contattare il supporto tecnico o il proprio account team.
La risposta di Arista: patch parziali e mitigazioni temporanee
La strategia di risposta comunicata da Arista segue uno schema classico per le vulnerabilità critiche divulgate mentre alcune correzioni sono ancora in lavorazione: aggiornare subito dove la patch esiste, applicare controlli compensativi dove non esiste ancora. Per i filoni 5.2 e 6.4, la raccomandazione è semplice, aggiornare a 5.2.3.16 o 6.4.2.8 il prima possibile. Per i filoni 6.1 e 7.0, ancora scoperti al momento della pubblicazione di questo articolo, Arista elenca una serie di controlli di difesa in profondità: limitare l’accesso all’interfaccia web di VCO alle reti amministrative fidate, monitorare gli accessi da indirizzi IP malevoli noti, sorvegliare il traffico in uscita non atteso, valutare il blocco delle porte in uscita non necessarie e cercare attivamente demoni backdoor o webshell.
Per chi sospetta o conferma una compromissione, la guida post-remediation di Arista è altrettanto concreta: rotazione delle credenziali, revisione dell’attività amministrativa recente, verifica dello stato dei dispositivi gestiti e, dove necessario, ricostruzione o sostituzione delle istanze compromesse a partire da fonti attendibili. L’azienda sottolinea un punto che spesso viene sottovalutato nella gestione degli incidenti SD-WAN: una compromissione dell’orchestratore può consentire agli attaccanti di raggiungere anche i dispositivi VeloCloud Edge collegati, trasformando quello che sembra un incidente contenuto su un singolo server di gestione in un problema esteso a tutta la rete di filiali che quell’orchestratore amministra.
Il contesto: l’eredità VeloCloud da VMware a Broadcom fino ad Arista
Per capire perché questa falla colpisce proprio Arista, un’azienda storicamente associata allo switching di data center e non al SD-WAN, serve ripercorrere brevemente la storia del prodotto. VeloCloud nasce come startup indipendente e viene acquisita da VMware nel 2017 per rafforzare la propria offerta di rete definita da software. Quando Broadcom completa l’acquisizione di VMware, il portafoglio VeloCloud passa sotto il controllo del gigante dei semiconduttori insieme al resto del catalogo software VMware.
Il passaggio ad Arista arriva più tardi: l’azienda ha acquisito il business unit SD-WAN VeloCloud da Broadcom con efficacia dal 30 giugno 2025, con l’annuncio pubblico diffuso il 1° luglio 2025. Si è trattato di un’operazione strutturata come acquisizione di asset e personale piuttosto che di una società intera: secondo le analisi di settore, Arista ha rilevato la proprietà intellettuale del portafoglio VeloCloud insieme a circa la metà dei circa mille dipendenti originari, concentrati soprattutto su ingegneria e supporto tecnico. Il prezzo dell’operazione non è mai stato reso pubblico né da Arista né da Broadcom, e le cifre circolate nella stampa di settore all’epoca, inferiori al miliardo di dollari, non hanno mai ricevuto conferma ufficiale e vanno quindi trattate come stime non verificate.
Questo tipo di operazione, un carve-out di prodotto che passa attraverso tre proprietari diversi in meno di un decennio (VMware, Broadcom, Arista), comporta quasi sempre un rischio tecnico che i team di sicurezza acquirenti faticano a eliminare in tempi brevi: codice sviluppato sotto una cultura ingegneristica, integrato in un’altra, e infine ereditato da una terza organizzazione che deve armonizzarlo con i propri processi di sicurezza. Non è un caso isolato nel settore del networking: acquisizioni e cessioni di rami SD-WAN si sono susseguite negli ultimi anni tra i principali vendor, e ogni passaggio di proprietà introduce potenziali discontinuità nei processi di revisione del codice, nei cicli di patching e nella conoscenza approfondita delle basi di codice ereditate.
Una settimana pesante per il networking enterprise: il confronto con altre falle critiche del 2026
CVE-2026-93952 non arriva in un momento isolato. Le analisi settimanali sulle vulnerabilità sfruttate attivamente indicano che, nella settimana conclusasi il 24 settembre 2026, sono state segnalate undici vulnerabilità critiche distribuite su otto vendor differenti, tra cui figurano proprio Arista insieme a Check Point, F5 e Zyxel. È un ritmo che conferma una tendenza osservata per tutto l’anno: gli apparati di perimetro di rete, VPN, gateway SD-WAN, controller di orchestrazione, restano il bersaglio preferito per chi cerca un punto d’appoggio iniziale dentro reti aziendali altrimenti ben difese, perché un solo dispositivo compromesso può dare visibilità e controllo su decine o centinaia di siti collegati.
Mettere questa falla a confronto con altri casi critici emersi nel corso dell’anno aiuta a inquadrarne la gravità relativa, non solo in astratto ma rispetto a un pattern che i team di sicurezza italiani ed europei hanno dovuto affrontare più volte nel 2026.
| Vulnerabilità | Prodotto | CVSS | Tipo di impatto |
|---|---|---|---|
| CVE-2026-93952 | Arista VeloCloud Orchestrator | 10.0 | Accesso privilegiato non autenticato, RCE potenziale |
| CVE-2026-85706 | GitLab | 10.0 | Path traversal |
| CVE-2026-5430 | WSO2 | 10.0 | Bypass autenticazione JWT |
| CVE-2026-44756 | SAP OVERPASS | 10.0 | Falla nel kernel applicativo |
| CVE-2026-49869 | Kestra | 10.0 | RCE con privilegi root |
| CVE-2026-85102 | Check Point Quantum VPN | 9,8 | Bypass autenticazione VPN |
| CVE-2026-94127 | F5 BIG-IP | 9,8 | Zero-day sfruttato attivamente |
Il quadro che emerge è netto: nel 2026 il punteggio 10.0 non è più un’eccezione rara riservata a scenari da manuale, ma un risultato che ricorre con regolarità sorprendente su prodotti di infrastruttura critica per le aziende, dai gateway VPN agli orchestratori SD-WAN fino alle piattaforme di automazione e ai moduli kernel applicativi. Per chi gestisce la sicurezza di una rete enterprise, la lezione pratica è che il numero di superfici da monitorare con priorità massima continua ad allargarsi, non a restringersi.
Impatto sul mercato SD-WAN e sulla fiducia dei clienti enterprise
Non esistono al momento stime di mercato aggiornate e verificate sul valore complessivo del segmento SD-WAN per il 2026, quindi qualunque cifra circolata in rete su questo fronte va considerata con cautela finché non compare in un report ufficiale di una società di analisi riconosciuta. Quello che si può valutare con maggiore concretezza è l’impatto reputazionale immediato: per Arista, che ha costruito la propria identità di mercato sull’affidabilità dello switching e del routing di data center per operatori cloud e finanziari di grandi dimensioni, una falla critica sfruttata attivamente nel primo anno pieno di integrazione del portafoglio VeloCloud rappresenta un banco di prova non da poco per la fiducia dei clienti enterprise che hanno scelto la piattaforma proprio nel periodo post-acquisizione.
I clienti che valutano oggi un fornitore SD-WAN, sia esso Arista, Cisco, Fortinet, Palo Alto Networks o Versa Networks, tendono sempre più spesso a includere nelle proprie valutazioni di procurement non solo le funzionalità del prodotto ma anche la cronologia delle vulnerabilità critiche e la rapidità di risposta del vendor. In questo senso, la trasparenza dell’avviso Arista, con indicatori di compromissione dettagliati e una cronologia chiara delle revisioni, gioca a favore dell’azienda anche in un momento difficile: comunicare male un incidente grave danneggia la reputazione più dell’incidente stesso, e la scelta di pubblicare hash, IP e nomi di file sospetti va nella direzione opposta rispetto alla reticenza che si osserva in molti altri casi di divulgazione tardiva o incompleta.
Il problema del debito di sicurezza nelle acquisizioni tecnologiche
Il caso Arista-VeloCloud si inserisce in un tema più ampio che i responsabili della sicurezza informatica europea stanno seguendo con crescente attenzione: il debito di sicurezza generato dalle acquisizioni tecnologiche. Quando un’azienda rileva un prodotto o un intero ramo d’azienda da un altro vendor, eredita anche tutto ciò che non si vede a un primo controllo, pratiche di sviluppo, dipendenze software datate, processi di test di sicurezza magari meno maturi degli standard interni dell’acquirente e, in alcuni casi, vulnerabilità già presenti ma non ancora scoperte.
Nel caso specifico di VeloCloud Orchestrator, il prodotto ha attraversato tre organizzazioni diverse in meno di dieci anni. Ogni transizione comporta tipicamente una fase di riallineamento dei processi di sicurezza che può durare mesi o anni, durante la quale il nuovo proprietario lavora per integrare il codice ereditato nei propri standard di revisione, nei propri strumenti di analisi statica e nei propri cicli di patch management. La classificazione CWE-20, convalida impropria dei dati in ingresso, è esattamente il tipo di debolezza che un audit di sicurezza approfondito dovrebbe intercettare durante una due diligence tecnica pre-acquisizione, ma che spesso sfugge quando la priorità dell’operazione è la velocità di chiusura del deal piuttosto che la profondità della revisione del codice.
Cosa devono fare subito i team IT: checklist operativa
Per i responsabili di rete che gestiscono un’installazione VeloCloud Orchestrator on-premise, la priorità immediata è verificare la versione in esecuzione e confrontarla con l’elenco delle release vulnerabili pubblicato da Arista. Ecco i passaggi essenziali da seguire nell’ordine corretto.
- Verificare immediatamente la versione di VCO in esecuzione confrontandola con i filoni 5.2.x, 6.1.x, 6.4.x e 7.0.x elencati nell’avviso Arista.
- Se si utilizza il filone 5.2 o 6.4, applicare subito l’aggiornamento alla versione corretta (5.2.3.16 o 6.4.2.8).
- Se si utilizza il filone 6.1 o 7.0, applicare tutte le mitigazioni compensative indicate finché la patch non è disponibile, in particolare restringere l’accesso all’interfaccia web di VCO alle reti amministrative fidate.
- Ricercare negli host VCO i file e i servizi elencati come indicatori di compromissione, inclusi i percorsi sospetti e l’hash MD5 pubblicato da Arista.
- Esaminare i log nginx alla ricerca dell’header HTTP anomalo x-vc-opt e di connessioni dagli indirizzi IP segnalati come malevoli.
- In caso di sospetta compromissione, preservare i log prima di qualunque intervento e contattare il supporto tecnico Arista.
- Dopo la remediation, ruotare tutte le credenziali associate all’orchestratore e verificare lo stato dei dispositivi VeloCloud Edge collegati.
Questa sequenza segue lo stesso schema raccomandato per la maggior parte degli incidenti su apparati di rete critici: contenere l’esposizione, verificare se il danno è già avvenuto, correggere alla radice e solo alla fine tornare alla normalità operativa con le dovute verifiche post-incidente.
CVSS 3.1 vs CVSS 4.0: perché i due punteggi raccontano storie leggermente diverse
Il fatto che Arista abbia pubblicato entrambi i punteggi, 10.0 secondo CVSS 3.1 e 9.5 secondo CVSS 4.0, offre un’occasione utile per chiarire un punto spesso frainteso da chi non lavora quotidianamente con la gestione delle vulnerabilità. CVSS 4.0, la versione più recente dello standard mantenuto da FIRST, introduce metriche più granulari per catturare aspetti che la versione 3.1 semplificava, come i prerequisiti d’attacco separati dalla complessità d’attacco vera e propria.
Nel caso di CVE-2026-93952, il vettore CVSS 4.0 classifica la complessità d’attacco come alta proprio perché lo sfruttamento richiede il possesso preventivo della parte pubblica del certificato dell’edge device, un passaggio che il modello più datato della versione 3.1 tendeva a comprimere semplicemente in una complessità bassa. Il punteggio finale resta comunque nella fascia critica in entrambi i casi, ma la differenza tra 10.0 e 9.5 dimostra perché i professionisti della sicurezza dovrebbero sempre leggere il vettore completo, e non limitarsi al numero, prima di stabilire le priorità di intervento tra decine di vulnerabilità aperte in coda.
Previsioni: cosa aspettarsi nelle prossime settimane
Sulla base dello schema seguito da Arista finora e dei precedenti osservati su falle di gravità comparabile in altri vendor di rete nel corso del 2026, si possono delineare alcuni scenari plausibili per le settimane a venire.
- Le patch per i filoni 6.1.x e 7.0.x, ancora scoperti alla data di pubblicazione di questo articolo, dovrebbero arrivare entro le prossime due o quattro settimane, in linea con i tempi tipici osservati per correzioni analoghe su prodotti di rete critici.
- È probabile un aumento dell’attività di scansione automatizzata contro le interfacce web di VCO esposte su internet, sia da parte di ricercatori di sicurezza che mappano l’esposizione globale, sia da parte di attori malevoli che cercano istanze non ancora aggiornate.
- Non è da escludere che emergano ulteriori dettagli tecnici sulla catena di exploit, inclusa un’eventuale attribuzione a un gruppo di minaccia specifico, man mano che più organizzazioni colpite condividono informazioni forensi con la comunità di sicurezza.
- È ragionevole attendersi che altri vendor con portafogli SD-WAN ereditati da acquisizioni recenti rafforzino le proprie revisioni di sicurezza interne, per evitare di trovarsi nella stessa situazione mediatica di Arista.
- I team di procurement enterprise che stanno valutando piattaforme SD-WAN probabilmente inizieranno a chiedere in modo più esplicito ai vendor la cronologia delle vulnerabilità critiche e i tempi medi di risposta, come parte integrante del processo di selezione.
Va sottolineato che queste restano proiezioni basate su pattern osservati, non fatti confermati: la situazione potrà evolvere rapidamente man mano che Arista completa le patch mancanti e che eventuali ulteriori vittime rendono pubbliche le proprie analisi. Per approfondimenti tecnici aggiornati, la copertura di The Hacker News e di SecurityWeek resta un riferimento utile per seguire gli sviluppi, insieme al monitoraggio diretto della scheda della vulnerabilità sul National Vulnerability Database.
Domande frequenti su CVE-2026-93952
Cos’è VeloCloud Orchestrator e a cosa serve?
VeloCloud Orchestrator (VCO) è il pannello di gestione centralizzato della piattaforma SD-WAN VeloCloud, oggi parte del portafoglio Arista Networks. Consente agli amministratori di configurare, monitorare e orchestrare il traffico di rete tra le sedi aziendali collegate tramite dispositivi VeloCloud Edge.
La mia azienda usa Arista solo per gli switch: sono a rischio?
No. Arista conferma esplicitamente che i prodotti basati sul sistema operativo EOS, incluse tutte le famiglie di switch e router di data center, non sono interessati da questa vulnerabilità. Il problema riguarda in modo specifico VeloCloud Orchestrator on-premise.
Serve un account VCO per essere attaccati?
No, ed è proprio questo il punto più critico della falla. Secondo l’avviso Arista, non sono richieste credenziali di tenant né di operatore per sfruttare la vulnerabilità: bastano l’accesso alla parte pubblica del certificato dell’edge device e la raggiungibilità di rete verso l’interfaccia web di VCO.
Come faccio a sapere se sono già stato compromesso?
Arista ha pubblicato indicatori di compromissione specifici: alcuni percorsi di file sospetti, un hash MD5 noto, un header HTTP anomalo nei log nginx e due indirizzi IP associati ad attività malevola osservata. Verificarli sui propri sistemi VCO è il primo passo consigliato.
Cosa devo fare se il mio filone di rilascio non ha ancora una patch?
Per i filoni 6.1.x e 7.0.x, ancora privi di correzione al momento della pubblicazione, Arista raccomanda di applicare controlli compensativi: limitare l’accesso all’interfaccia web di VCO alle reti amministrative fidate, monitorare gli accessi sospetti e cercare attivamente segnali di compromissione fino al rilascio della patch definitiva.
Perché il punteggio CVSS 4.0 è più basso di quello CVSS 3.1?
Perché lo standard più recente valuta separatamente i prerequisiti necessari per lo sfruttamento, come il possesso del certificato pubblico dell’edge device, classificando la complessità d’attacco come alta anziché bassa. Il punteggio resta comunque nella fascia critica in entrambi i sistemi di valutazione.
Un attaccante che compromette VCO può raggiungere anche i dispositivi Edge collegati?
Sì. Arista avverte esplicitamente che una compromissione dell’orchestratore può consentire agli attaccanti di raggiungere anche i dispositivi VeloCloud Edge amministrati da quell’istanza, estendendo potenzialmente l’impatto a tutta la rete di filiali collegate.
