Cisco Expressway CVE-2026-76466: RCE non autenticata come root (CVSS 9.8)

L'apparato che molte organizzazioni mettono in DMZ proprio perché il personale remoto raggiunga la collaboration interna senza VPN — Cisco Expressway-E — può essere trasformato in una shell di root da chi non effettua mai il login. Oggi Cisco ha pubblicato CVE-2026-76466, valutata CVSS 9.8 critica: un attaccante remoto e non autenticato che raggiunge il servizio di database del dispositivo può eseguire comandi di sistema arbitrari come root. Non esiste workaround. L'unica correzione è l'aggiornamento.

Notizia in evoluzione — pubblicata alle 19:22 (17:22 UTC) del 21 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-76466
Prodotto / versioni colpite	Cisco Expressway-C ed Expressway-E (virtuale e appliance) configurati in cluster · release X15.5.3 e precedenti · X14 e precedenti
Corretta in	X15.5.20 (corregge X15.5.3 e precedenti) · X14 e precedenti devono migrare a una release corretta; inclusa anche nella October 2026 Expressway Series Security Hardening Release · 2026-10-21
CVSS	9.8 Critica · CVSS 3.1 · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · assegnato da Cisco PSIRT (NVD non ha ancora un punteggio indipendente)
Sfruttata attivamente	No — Cisco PSIRT non è a conoscenza di annunci pubblici o uso malevolo (2026-10-21)
CISA KEV	Non presente (versione catalogo 2026.10.21)
PoC pubblico	Nessuno pubblico al 2026-10-21
Advisory ufficiale	cisco-sa-vcs-static-cred-hr7EWZ8t

Cosa è successo: un cookie statico non è un segreto

Due debolezze si sommano in un unico percorso non autenticato verso root, e l'advisory Cisco le nomina entrambe. Primo, il servizio di database si fida dei cookie persistenti. Cisco classifica il bug come CWE-798 — uso di credenziali hard-coded — perché un cookie persistente e prevedibile non è qualcosa che l'attaccante deve rubare tramite un login: funziona come una credenziale statica. Secondo, quando il TLS Verify Mode è impostato su Enabled per il clustering, il servizio di fatto non convalida il certificato client presentato. Il controllo che dovrebbe dimostrare "sei un peer legittimo del cluster" è, in pratica, spento.

Messi insieme, secondo l'advisory: un attaccante in possesso dei cookie si connette al servizio di database, invoca specifici comandi RPC (remote procedure call) e il dispositivo li esegue come root sul sistema operativo sottostante. Nessuna autenticazione preliminare, nessuna interazione utente, solo accesso di rete — esattamente ciò che PR:N/UI:N codifica nel vettore CVSS. Il difetto è stato segnalato a Cisco da Stefan Aleksic di Jane Street.

Il punto su cui il difensore deve fermarsi è la parola "non autenticata". Quando la credenziale è un artefatto statico incorporato nel modo in cui il prodotto parla con sé stesso, il compito dell'attaccante si riduce a raggiungere la porta e conoscere la forma della richiesta. È molto meno di decifrare una password, ed è il tema ricorrente nelle RCE sugli apparati: il bug pericoloso raramente è un esotismo di memory corruption, è un'assunzione di fiducia mai verificata al confine.

Chi è esposto, e come verificare

L'advisory circoscrive il problema a Cisco Expressway-C ed Expressway-E — sia nella forma virtuale sia come appliance hardware — che eseguono una release vulnerabile e sono configurati in cluster. Cisco Expressway Series qui significa Expressway Core (Expressway-C) ed Expressway Edge (Expressway-E); lo stesso codice è stato storicamente distribuito come TelePresence Video Communication Server (VCS), motivo per cui l'ID dell'advisory porta il tag vcs.

Il motivo per cui questa merita una risposta in giornata è dove vive la scatola. Expressway-E è il nodo di traversal che si colloca deliberatamente al confine internet: è il gateway di Mobile and Remote Access (MRA) senza VPN di Cisco e la porta d'ingresso del video B2B. Root su un Expressway-E esposto a internet non è un nodo foglia — è la cerniera tra la rete pubblica e il patrimonio di Unified Communications interno, incluso il percorso verso Unified CM.

Controllate la release in esecuzione dalla web UI (Status > System information) o via SSH:

xstatus SystemUnit version

Se riporta X15.5.3 o precedenti, o una qualsiasi X14 (o più vecchia), e il deployment è in cluster, consideratelo colpito fino all'applicazione della patch.

Remediation

1. Sono colpito?

Enumerate ogni Expressway-C ed Expressway-E, virtuale e fisico, e annotate il treno software (xstatus SystemUnit version o Status > System information). Segnalate ogni nodo su X15.5.3-o-precedenti o X14-o-precedenti che partecipa a un cluster. I nodi Expressway-E con l'interfaccia esterna raggiungibile da internet sono la coda prioritaria — è lì che un attaccante non autenticato non ha nemmeno bisogno di un punto d'appoggio iniziale.

2. Patch — la versione corretta esatta

Non esiste workaround; Cisco è esplicita nel dire che ogni mitigazione è temporanea e che l'aggiornamento è la correzione.

• X15.5.3 e precedenti → aggiornare a X15.5.20.
• X14 e precedenti → non c'è una release corretta su quel treno; migrare a una release corretta.
• La stessa correzione è inclusa anche nella October 2026 Cisco Expressway Series Security Hardening Release (advisory cisco-sa-exwy-hardening-FhcqBVcs) — se state preparando quel bundle, questo CVE è coperto.

3. Non potete aggiornare subito? — controlli compensativi

Cisco non offre alcun workaround supportato, quindi questi restringono solo la finestra; non chiudono il bug:

• Limitate chi può raggiungere le porte di clustering / servizio di database sul firewall. Il percorso RPC abusato è un canale interno di cluster — non dovrebbe mai essere raggiungibile dall'internet generale o da VLAN non fidate. Limitatelo ai soli indirizzi noti dei peer di cluster.
• Mantenete l'interfaccia esterna di Expressway-E limitata ai soli servizi di traversal SIP/H.323/HTTPS che deve esporre; nulla di MRA richiede che il servizio di database sia raggiungibile da internet.
• Date priorità agli Expressway-E in cluster ed esposti a internet, prima degli Expressway-C interni.

4. Caccia alla compromissione

Cisco non ha pubblicato indicatori di compromissione e non è stato osservato alcuno sfruttamento, quindi non c'è una lista di IOC da confrontare — cacciate per comportamento, non per firma, e mappate su MITRE ATT&CK:

• T1190 (Exploit Public-Facing Application): connessioni inattese alla porta del servizio di database/clustering da indirizzi che non sono peer di cluster configurati.
• T1059 (Command and Scripting Interpreter): processi generati dal servizio di database che non fanno parte del normale funzionamento di Expressway, in particolare qualsiasi cosa eseguita come root.
• T1210 (Exploitation of Remote Services): connessioni laterali da un Expressway compromesso verso Unified CM o host UC interni che non rientrano nel normale schema MRA/traversal.
• Rivedete gli eventi di autenticazione, modifica di configurazione e creazione di account sul nodo e sui sistemi UC a valle, intorno e dopo la finestra di divulgazione.

Poiché lo sfruttamento riuscito atterra come root, i log del nodo stesso non possono essere ritenuti attendibili per raccontare la verità a posteriori — un attaccante a quel livello può riscriverli.

5. Eradicare e verificare

Se trovate prove di sfruttamento, la sola patch non annulla l'accesso root già avvenuto. Ricostruite il nodo colpito da un'immagine integra alla release corretta invece di aggiornare in place, ripristinate la configurazione da un backup precedente alla sospetta compromissione e ruotate ogni segreto detenuto dal nodo — certificati TLS di cluster, credenziali di servizio e amministrative, e qualsiasi fiducia che il nodo aveva stabilito verso Unified CM. Poi ri-verificate: confermate che sia in esecuzione la versione corretta e che il percorso RPC del servizio di database rifiuti una richiesta non autenticata, invece di fidarvi della sola stringa di versione.

Cosa non si sa ancora

• NVD ha pubblicato il record ma non un punteggio indipendente — il 9.8 è quello di Cisco PSIRT, rispecchiato da NVD, che mostra ancora la voce come Received.
• Non esiste alcun proof-of-concept pubblico al momento in cui scriviamo, e Cisco PSIRT non segnala sfruttamento osservato. Per un apparato di edge con un 9.8, può cambiare rapidamente.
• L'advisory Cisco lega il difetto alla configurazione in cluster. Se esista un percorso raggiungibile anche senza cluster non è specificato; la lettura prudente è applicare la patch a prescindere dallo stato di cluster.
• La natura precisa dei "cookie persistenti" — la loro prevedibilità o il riuso tra dispositivi — non è dettagliata pubblicamente, il che è appropriato a questo stadio.

Aggiorneremo questo articolo man mano che CISA, NVD e Cisco pubblicheranno altro.

Scoprirlo prima di un attaccante

La domanda onesta che un operatore di Expressway-E ha stasera non è "quanto è grave il CVSS" — è "la mia scatola specifica, con la mia specifica configurazione di cluster e firewall, è davvero raggiungibile e sfruttabile da internet in questo momento?" Un punteggio di severità non può rispondere. Un test sì.

È il lavoro per cui Zero Hunt è costruito: un red team autonomo guidato dall'AI che gira on-premise sui propri modelli privati, con un essere umano nel loop per qualsiasi cosa tocchi il dispositivo. Il suo swarm di 10 agenti identifica l'esatto treno Expressway in esecuzione e, invece di riprodurre una voce di catalogo, genera un proof-of-concept per-target contro quella versione e quella esposizione — black-box di default, senza credenziali assunte, che è esattamente il punto di vista dell'attaccante per un difetto non autenticato. Ogni skill che usa è sottoposta a backtest nell'AI Gym prima di toccare un asset in produzione, e ogni risultato è firmato al momento della scrittura (Ed25519, con hash a catena) così che la prova che il vostro edge era — o non era — raggiungibile sia verificabile in seguito, non uno screenshot.

Quando la prova torna indietro, l'AI Remediation Advisor ordina la correzione per sfruttabilità reale — prima CISA KEV, poi ciò che la campagna ha effettivamente dimostrato raggiungibile, poi CVSS ed EPSS — vi consegna l'aggiornamento esatto (qui, X15.5.20) con note di rollout e rollback e il controllo compensativo sul firewall per l'ora in cui non potete aggiornare, e poi ri-verifica la correzione con la stessa prova che aveva dimostrato il buco. Per un percorso più approfondito sul testing continuo e provato dall'exploitation degli apparati di edge, vedi la nostra guida al penetration testing automatizzato. Poiché tutto gira sull'appliance on-prem, nessuna telemetria sul vostro edge di collaboration lascia il vostro patrimonio per scoprirlo.