Arista EOS CVE-2026-7473: la falla sfruttata che non avrà una patch

Esiste una categoria di advisory che manda in crisi i presupposti su cui è costruito ogni programma di vulnerability management. CVE-2026-7473 è una di queste. È nel catalogo CISA Known Exploited Vulnerabilities, aggiunta il 9 giugno 2026 con scadenza di remediation federale al 23 giugno. È sfruttata in the wild contro infrastruttura di rete in produzione. E Arista ha dichiarato, nel Security Advisory 0137, che non è previsto alcun percorso di upgrade software per correggerla. La voce KEV dice "rimediare entro il 23 giugno". Il vendor dice "non c'è niente da installare". Sono vere entrambe nello stesso momento, e questa contraddizione è tutta la storia.

Cosa fa davvero CVE-2026-7473

Arista EOS è il sistema operativo di rete sulle piattaforme di switching Arista — il fabric spine-and-leaf dentro una quota rilevante dei data center hyperscale ed enterprise. La falla vive nel modo in cui EOS gestisce la decapsulation dei tunnel. Quando uno switch è configurato come tunnel endpoint — VXLAN, un'interfaccia GRE, o un decap-group con un IP di decapsulation — dovrebbe accettare e scartare l'header di uno specifico protocollo di tunneling che arriva a quell'IP. CVE-2026-7473 è la scoperta che lo switch non verifica quale protocollo ha ricevuto.

Secondo il record NVD, lo switch "decapsula e inoltra in modo errato altri pacchetti tunnelizzati inattesi con un IP di destinazione che corrisponde all'IP di decapsulation configurato", perché non verifica mai il tipo di protocollo del tunnel. La classificazione è CWE-1023, Incomplete Comparison with Missing Factors: il dispositivo confronta l'IP di destinazione e inoltra in caso di match, ma il tipo di protocollo — il fattore che avrebbe dovuto vincolare l'operazione — è semplicemente assente dal confronto.

La meccanica è banale. La conseguenza no. Qualsiasi attaccante remoto e non autenticato in grado di instradare un pacchetto verso l'IP di decapsulation può costruire un pacchetto tunnelizzato di qualunque protocollo, far rimuovere allo switch l'header esterno e iniettare il payload interno sul forwarding path interno. L'hardware interessato comprende le serie 7020R, 7280R/R2 e 7500R/R2, con alcuni scenari che toccano le linee 7280R3, 7500R3 e 7800R3, attraverso EOS 4.30 e versioni precedenti e i tronchi 4.31–4.36. I punteggi CVSS sono volutamente contenuti — 5.8 su CVSS v3.1, 6.8 su v4.0 — e quella moderazione è esattamente la trappola, perché l'impatto non si misura nel punteggio. Si misura in ciò che il pacchetto iniettato raggiunge.

Perché il vero punto di Arista EOS è il "niente patch"

La parte nuova di questo advisory non è la confusione di protocollo. È la risoluzione. Come riportato da SecurityWeek, la posizione di Arista è che "non è previsto alcun percorso di upgrade software per affrontare il problema, a causa del rischio di rompere configurazioni esistenti negli ambienti". Imporre una validazione stretta del tipo di protocollo in fase di decapsulation, su un numero significativo di fabric in produzione, scarterebbe traffico da cui quei fabric oggi dipendono. Così la correzione che esiste in linea di principio non viene rilasciata come upgrade. La remediation è configurazione, non codice:

• Applicare ACL di ingresso sul control-plane e sul data-plane che permettano solo il protocollo di tunnel atteso verso l'IP di decapsulation e scartino tutto il resto.
• Restringere la raggiungibilità dell'IP di terminazione del tunnel ai soli peer router noti, tramite ACL infrastrutturali o uRPF dove la piattaforma lo supporta.

Ecco com'è fatta una vulnerabilità non patchabile nel 2026. Non uno zero-day in attesa del vendor, ma una falla nota, presente nel KEV, sfruttata attivamente, la cui unica risoluzione è una mitigation costruita a mano che ogni operatore deve progettare, applicare e — punto cruciale — rendere corretta sul proprio fabric. Non esiste un numero di versione che colora di verde la dashboard. Lo stato di remediation non è "patchato / non patchato". È "l'ACL che hai scritto ha davvero scartato il protocollo che non ti aspettavi, su ogni IP di decapsulation, su ogni dispositivo?"

Il punto cieco: perché scanner e dashboard di patching falliscono entrambi

Si segua come uno stack convenzionale di vulnerability management affronta CVE-2026-7473, e si scopre che fallisce due volte.

Uno scanner basato sulle versioni — Tenable, Qualys, Rapid7, il motore dentro la maggior parte dei programmi VM — risponde a una sola domanda: la versione installata è inferiore alla versione corretta? Per questa CVE non esiste una versione corretta. Arista non la rilascia. Quindi lo scanner non ha nulla con cui confrontare e nulla da segnalare. L'asset risulta pulito.

Un workflow di patch management fallisce per lo stesso motivo dall'altra direzione: non c'è patch da preparare, testare e distribuire. Il ticket di remediation, se mai viene aperto, non ha alcun artefatto da allegare. Si chiude come "mitigation applicata" — e "mitigation applicata" è un'asserzione, non una misura.

Domanda a cui risponde il tuo tooling	Cosa ti dice su CVE-2026-7473
La versione EOS è inferiore alla release corretta?	Niente — non esiste una release corretta
C'è una patch da distribuire?	No — la remediation è solo configurazione
È stata committata un'ACL di mitigation nella config?	Forse — ma un'ACL committata non è un'ACL verificata
L'IP di decapsulation inoltra ancora un protocollo inatteso?	È l'unica domanda che conta, e nessuno scanner di versioni la pone

La scadenza CISA del 23 giugno spinge le agenzie federali — e, per gravità, chiunque tratti il KEV come baseline — a "rimediare". Ma qui la remediation è non verificabile con gli strumenti che gran parte delle organizzazioni usa per dimostrarla. Puoi segnare il ticket come chiuso ed essere ancora sfruttabile, perché l'unica prova che la tua mitigation funzioni è un pacchetto che dovrebbe essere scartato e che viene effettivamente scartato.

"Siamo a posto — il change ticket mostra che l'ACL di ingresso è entrata il 16." "Su quali dispositivi?" "Sugli spine del fabric." "Inclusi i due 7280R2 che il team di rete ha ricostruito il trimestre scorso dal vecchio template — quello scritto prima dell'advisory?" "...devo verificare." L'exploit non verifica. Invia il pacchetto.

Cosa fa un attaccante con un bypass di segmentazione

La ragione per cui questo bug a CVSS medio è nel KEV è ciò che il bypass sblocca. La segmentazione di rete è il controllo che dice: il traffico dal segmento A non può raggiungere il segmento B salvo che una policy lo permetta — il muro tra la VLAN corporate e la rete OT, tra i carichi generali e l'ambiente dei dati di pagamento, tra i tenant su un fabric condiviso. CVE-2026-7473 permette a un attaccante di attraversare quel muro tunnelizzando direttamente verso l'IP di decapsulation e lasciando che lo switch consegni il pacchetto interno sul lato fidato.

All'attaccante non servono credenziali, un punto d'appoggio sullo switch o un exploit separato. Serve raggiungibilità verso l'IP di decapsulation e un header di tunnel costruito ad arte. Una volta che il payload interno atterra sul forwarding path, arriva con l'aspetto di legittimo traffico est-ovest — già oltre il confine che il design di segmentazione presumeva solido. Da lì il copione è ordinario: raggiungere un'interfaccia di management "raggiungibile solo dall'interno", pivotare in un segmento PCI o ICS che le attestazioni di conformità descrivono come isolato, esfiltrare dati da un host che doveva essere irraggiungibile. Lo schema di segmentazione nel faldone dell'audit mostra ancora il muro. Il muro ha un tunnel che lo attraversa.

È questo il failure mode che rende pericolosa la formula "niente patch". Le organizzazioni leggeranno "mitigation disponibile", applicheranno qualcosa e sposteranno l'asset a "remediato". Lo schema non cambierà. L'attestazione non cambierà. Cambierà solo il traffico — e solo se qualcuno sta osservando il traffico in cerca di un pacchetto interno arrivato dove la topologia dice che non potrebbe.

La validazione continua è l'unico modo per saperlo

Tutto quanto sopra punta a una verità operativa: per CVE-2026-7473 la domanda "siamo esposti?" non può ricevere risposta da un numero di versione, da un record di patch o da un diff di configurazione. Può riceverla solo inviando il pacchetto descritto nell'advisory e osservando se lo switch lo inoltra. È un test comportamentale del fabric in produzione, eseguito in modo continuo e non come istantanea trimestrale — ed è esattamente la lacuna che Zero Hunt è stata costruita per chiudere.

Lo swarm di 10 agenti AI di Zero Hunt valida il comportamento dell'ambiente, non l'inventario del suo software. Di fronte a questa classe di falla, gli agenti Recon e Pivot mappano ogni IP di terminazione tunnel sul fabric, e l'agente Exploit genera un probe per-target — un pacchetto di decapsulation costruito ad arte e specifico per la tua topologia, scritto localmente e non prelevato da un database statico di firme — per determinare se il payload interno attraversa davvero il confine di segmentazione. La risposta non è "l'ACL è nella config". La risposta è "su questo dispositivo, adesso, un protocollo inatteso raggiunge o non raggiunge il lato fidato". Ogni nuovo asset sul perimetro, o qualsiasi modifica di configurazione a un decap-group, innesca una nuova campagna entro un'ora — così uno switch ricostruito da un template precedente all'advisory viene ritestato nel momento in cui compare, non al prossimo audit. Ogni finding è firmato ECDSA al momento della scrittura, il che trasforma "mitigation applicata" da asserzione in prova verificabile, con catena di custodia, che un auditor o un regolatore può confrontare con la scadenza KEV.

E poiché l'exploit ha successo solo quando il traffico attraversa un confine che non dovrebbe, il livello di AI Traffic Analysis è la seconda rete sotto. Il suo modello di deep learning — quattro teste di inferenza che girano a velocità di linea multi-gigabit sulla GPU dell'appliance, senza alcun callback verso il cloud — è addestrato a segnalare proprio questo: un pacchetto tunnelizzato o interno che compare su un segmento la cui baseline storica dice che quel percorso sorgente-destinazione non è mai esistito. Quando uno scanner di versioni è strutturalmente cieco e una patch non arriverà mai, le uniche difese durature sono testare il comportamento reale prima che lo faccia un attaccante, e osservare il filo nel momento in cui il muro viene violato. CVE-2026-7473 è il caso di studio del perché "patchato" e "non sfruttabile" hanno smesso di essere la stessa frase.