Attacchi in corso contro i server VeloCloud Orchestrator con autenticazione tramite certificato

Il 22 settembre 2026 Arista ha reso noto che gli attaccanti stanno sfruttando una vulnerabilità critica nelle implementazioni on-premises di VeloCloud Orchestrator. La piattaforma di gestione controlla i dispositivi VeloCloud SD-WAN Edge, quindi un orchestrator compromesso può diventare un potenziale punto d’accesso alla rete gestita nel suo complesso.

La vulnerabilità, identificata come CVE-2026-93952, ha ottenuto un punteggio CVSS 3.1 pari a 10,0. Consente a un attaccante remoto non autenticato di accedere a funzionalità interne con privilegi elevati e di compromettere potenzialmente l’host VCO.

Lo sfruttamento non è possibile in tutte le configurazioni VCO. Il percorso d’attacco segnalato richiede l’autenticazione basata su certificato tra i dispositivi Edge e l’orchestrator, l’accesso di rete all’interfaccia web del VCO e la componente pubblica di un certificato di autenticazione Edge.

L’esposizione dipende dalla configurazione dell’autenticazione Edge

I dispositivi VeloCloud Edge possono autenticarsi al VCO tramite tre modalità:

• Certificate Deactivated, che si basa su una chiave precondivisa.
• Certificate Acquire, che utilizza un certificato emesso dall’orchestrator.
• Certificate Required, che utilizza anch’essa un certificato emesso dall’orchestrator.

Arista ha indicato l’autenticazione Edge basata su certificato come condizione di esposizione. Non è stato chiarito se CVE-2026-93952 interessi Certificate Acquire, Certificate Required o entrambe le modalità.

L’attaccante deve inoltre poter raggiungere l’interfaccia web del VCO e disporre della parte pubblica di un certificato di autenticazione Edge. Una volta soddisfatte queste condizioni, non è richiesta alcuna autenticazione dell’attaccante.

Il vettore CVSS della vulnerabilità è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Il punteggio riflette un problema accessibile dalla rete, con bassa complessità d’attacco, che non richiede privilegi né interazione dell’utente e può avere conseguenze gravi su riservatezza, integrità e disponibilità.

Il difetto software preciso che rende possibile l’attacco non è stato descritto pubblicamente. Non è disponibile alcuna classificazione CWE e Arista non ha fornito dettagli sulle richieste, sul componente interno o sull’errore di elaborazione coinvolto. L’azienda ha dichiarato che la vulnerabilità è stata scoperta esternamente ed è già oggetto di sfruttamento, senza però specificare quando siano iniziati gli attacchi né quanti sistemi o organizzazioni siano stati compromessi.

Le istanze VCO Hosted e Dedicated sono state corrette prima della divulgazione pubblica. L’esposizione residua riguarda quindi soprattutto le installazioni on-premises gestite dai clienti.

Gli aggiornamenti correttivi sono disponibili solo per due rami

Le versioni interessate e quelle corrette comunicate il 22 settembre sono:

Ramo di release	Versioni interessate	Release correttiva
5.2	5.2.3.15 e precedenti	5.2.3.16 e successive
6.1	6.1.3.7 e precedenti	Nessuna correzione disponibile
6.4	6.4.2.7 e precedenti	6.4.2.8 e successive
7.0	7.0.0.2 e precedenti	Nessuna correzione disponibile

Le organizzazioni che utilizzano il ramo 5.2 dovrebbero aggiornare alla versione 5.2.3.16 o a una release successiva. Chi utilizza il ramo 6.4 dovrebbe installare la versione 6.4.2.8 o una successiva.

Al momento della segnalazione non era stata rilasciata alcuna versione corretta per i rami interessati 6.1 e 7.0. Arista ha dichiarato che aggiungerà al proprio advisory gli aggiornamenti per i rami interessati ancora supportati non appena saranno disponibili.

I clienti che utilizzano un ramo di release non più supportato dovrebbero contattare il Technical Assistance Center di Arista per valutare un percorso di aggiornamento. Gli operatori di sistemi 6.1 e 7.0 dovrebbero inoltre seguire le indicazioni del fornitore, senza presumere che le sole modifiche alla configurazione siano sufficienti a eliminare il rischio.

La compromissione dell’orchestrator può estendersi ai dispositivi Edge gestiti

VCO è il server di gestione dell’infrastruttura VeloCloud SD-WAN Edge. Uno sfruttamento riuscito può quindi avere conseguenze che vanno oltre l’host su cui viene eseguito l’orchestrator.

Le conseguenze immediate includono l’accesso non autorizzato a funzionalità interne con privilegi elevati e la possibile compromissione della riservatezza, dell’integrità e della disponibilità del VCO e dei dati gestiti. Poiché il server amministra i dispositivi Edge, un attaccante che controlli il VCO potrebbe inoltre ottenere un punto d’accesso per modificare o altrimenti compromettere l’ambiente Edge gestito.

Tra le possibili attività successive alla compromissione rientrano modifiche amministrative non autorizzate, distribuzione di webshell, installazione di daemon persistenti e comunicazioni in uscita inattese dal server VCO. Gli attaccanti potrebbero anche manipolare le configurazioni Edge attraverso il livello di gestione compromesso.

Si tratta di possibili conseguenze e obiettivi di rilevamento, non della conferma che ogni sistema compromesso presenti gli stessi artefatti. Arista ha avvertito che nessun singolo indicatore pubblicato dimostra in modo conclusivo lo sfruttamento tramite CVE-2026-93952.

Cercare artefatti sull’host e richieste web anomale

Gli amministratori dovrebbero iniziare esaminando i log degli accessi web del VCO. Tra gli schemi sospetti rientrano percorsi insoliti in stile URL, caratteri codificati, riferimenti a servizi interni o locali e volumi di richieste nettamente diversi dalla normale attività di gestione.

Gli indicatori divulgati sono:

Tipo	Indicatore
File	/usr/local/sbin/.vcnode.js
File	/usr/local/sbin/vc-sysmond
MD5 di vc-sysmond	dc78e206eaeadec59fc5801fe4556bd0
Unità Systemd	/etc/systemd/system/vc-sysmon.service
Intestazione HTTP dei log Nginx	x-vc-opt
Indirizzo IP	142.93.149[.]77
Indirizzo IP	104.248.126[.]159

Il rilevamento non dovrebbe limitarsi a questo elenco. I team di sicurezza dovrebbero verificare la presenza di servizi creati o modificati di recente, file simili a webshell, azioni amministrative prive di spiegazione e traffico in uscita non coerente con il comportamento atteso dell’orchestrator.

Le connessioni che coinvolgono i due indirizzi IP divulgati devono essere analizzate, ma la sola corrispondenza di un indirizzo non dimostra lo sfruttamento. La stessa cautela vale per le richieste anomale e per gli artefatti isolati sul file system.

Se vengono rilevati indicatori o attività sospette, gli amministratori dovrebbero preservare lo stato attuale del sistema prima che le operazioni di remediation modifichino le prove disponibili. Tra gli elementi utili rientrano i log degli accessi web, dell’applicazione backend, di sistema e del database, oltre ai timestamp del file system.

Arista consiglia di contattare il TAC o il proprio account team Arista dopo aver individuato una possibile compromissione.

Applicare le patch, limitare l’accesso e trattare gli host sospetti come compromessi

Installare una release corretta è l’azione prioritaria quando disponibile. Fino al completamento dell’aggiornamento, gli operatori dovrebbero limitare l’accesso all’interfaccia web del VCO, rendendola raggiungibile solo dalle reti amministrative affidabili.

Tra le ulteriori misure difensive rientrano:

1. Monitorare il traffico che coinvolge gli indirizzi IP malevoli divulgati.
2. Analizzare le connessioni in uscita inattese dall’host VCO.
3. Bloccare le porte in uscita non necessarie, quando i requisiti operativi lo consentono.
4. Cercare daemon non autorizzati, servizi alterati e webshell.
5. Esaminare le attività amministrative e le modifiche alla configurazione recenti.
6. Verificare lo stato e la configurazione dei dispositivi Edge gestiti.

Dopo aver aggiornato un sistema potenzialmente esposto, le organizzazioni dovrebbero ruotare le credenziali, analizzare le attività degli amministratori e verificare che i dispositivi Edge gestiti non siano stati alterati. Quando si sospetta una compromissione, ripristinare o sostituire l’orchestrator utilizzando fonti affidabili è più sicuro che considerare l’aggiornamento una remediation sufficiente.

Un host che mostra indicatori, azioni di gestione anomale o attività di rete sospette dovrebbe essere trattato come potenzialmente compromesso, non semplicemente come vulnerabile.

Una seconda vulnerabilità critica di VCO segue un precedente caso KEV

CVE-2026-93952 segue un’altra vulnerabilità critica di VeloCloud Orchestrator, CVE-2026-16812, segnalata a luglio. Anche a quel problema era stato assegnato un punteggio CVSS pari a 10,0 ed era stato classificato come CWE-78.

Il modello di esposizione era diverso. CVE-2026-16812 risultava sfruttabile con la configurazione predefinita e non poteva essere neutralizzata tramite le impostazioni di configurazione, mentre la vulnerabilità appena divulgata dipende dall’autenticazione Edge basata su certificato e dalla raggiungibilità dell’interfaccia web.

Il 27 luglio 2026 CISA ha aggiunto CVE-2026-16812 al catalogo Known Exploited Vulnerabilities, fissando al 30 luglio 2026 la scadenza per la remediation da parte delle agenzie federali statunitensi. L’azione richiesta consisteva nell’applicare le mitigazioni del fornitore, seguendo al contempo le indicazioni di aggiornamento basate sul rischio previste dal BOD 26-04 e i requisiti di triage forense di CISA. Quando le mitigazioni non erano disponibili, le indicazioni applicabili prevedevano la dismissione dell’utilizzo.

Per CVE-2026-93952 non è stata divulgata alcuna voce nel catalogo CISA KEV. Il suo sfruttamento attivo confermato rende comunque priorità immediate l’applicazione delle patch, la riduzione dell’esposizione e la valutazione di eventuali compromissioni per gli operatori di sistemi VCO on-premises con autenticazione tramite certificato.