w5m1n9/cisco-unified-communications-manager-server-side-forgery-request-vulnerability-cve-2026-20230Analizza CVE-2026-20230 SSRF per scrittura arbitraria di file e RCE in Cisco Unified Communications Manager, fornendo derivazione PoC, logica di rilevamento e guida difensiva.
Ambito di applicazione: solo per laboratori locali, ambienti autorizzati di riproduzione, verifica di vulnerabilità e analisi di regole di protezione. Non utilizzare su obiettivi non autorizzati. Questo articolo analizza principalmente la catena di sfruttamento di CVE-2026-20230, fenomeni verificabili, logica di giudizio e idee di difesa, senza fornire payload di attacco, contenuti di WebShell o comandi eseguibili direttamente copiabili.
CVE-2026-20230 è una vulnerabilità di server-side request forgery in Cisco Unified Communications Manager (Unified CM / CUCM) e Cisco Unified Communications Manager Session Management Edition (Unified CM SME). La vulnerabilità deriva da una verifica insufficiente degli input nel flusso di elaborazione di specifiche richieste HTTP. Un attaccante può costruire richieste non autenticate per far sì che il dispositivo interessato acceda a interfacce interne o risorse locali per conto dell'attaccante.
L'impatto di questa vulnerabilità non si limita alla normale scansione SSRF. Le analisi tecniche pubbliche mostrano che, in determinate versioni e condizioni di servizio abilitato, la SSRF può essere concatenata per ottenere la capacità di scrittura arbitraria di file. L'attaccante può scrivere contenuti controllabili nel percorso del sistema operativo sottostante e quindi, utilizzando il meccanismo di caricamento dei componenti lato server o delle directory accessibili dal container Web, trasformare la scrittura di file in esecuzione di codice.
Cisco ha assegnato a questa vulnerabilità un punteggio CVSS v3.1 di 8.6 con vettore:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
Sebbene il punteggio CVSS sia Alto (High), Cisco ha classificato il Security Impact Rating come Critico (Critical). Il motivo è che, una volta sfruttata con successo, è possibile scrivere file nel sistema operativo sottostante e potenzialmente elevare i privilegi a root.
Una nota importante: la condizione preliminare chiave per questa vulnerabilità è che il servizio WebDialer sia abilitato. WebDialer è disabilitato per impostazione predefinita, quindi non si può giudicare la vulnerabilità solo osservando un asset CUCM. La reale valutazione del rischio richiede di confermare contemporaneamente la versione del prodotto, lo stato delle patch, lo stato del servizio WebDialer e se le relative interfacce sono accessibili.
Questa vulnerabilità non è una normale vulnerabilità Web in cui "l'accesso a un URL fisso che restituisce 200 indica la presenza". La sua catena di sfruttamento include almeno tre livelli:
Pertanto, l'accesso isolato a una certa interfaccia ottenendo HTTP 200, 302, 401, 404 o 500 non può dimostrare direttamente l'esistenza o l'assenza della vulnerabilità.
Ad esempio, l'accessibilità dell'interfaccia WSDL di WebDialer indica solo che il target espone funzionalità correlate a WebDialer, ma non può dimostrare che la successiva SSRF possa superare i filtri. Allo stesso modo, l'accessibilità dell'interfaccia installClusterStatusExecute indica solo l'esistenza di un punto di ingresso correlato, ma non può dimostrare da sola che la scrittura arbitraria di file sia già possibile. Al contrario, se un certo passo restituisce un'anomalia, potrebbe essere dovuto alla versione del target, alle patch, alla risoluzione del nome host, ai permessi del percorso, ai dispositivi proxy o allo stato del servizio, e non rappresenta necessariamente l'intera assenza della catena.
Un giudizio più solido dovrebbe utilizzare una combinazione di prove a più stadi:
Solo quando "WebDialer abilitato + versione interessata + comportamento SSRF confermato + scrittura controllata di file confermata" si verificano contemporaneamente, si dovrebbe giudicare la vulnerabilità come altamente affidabile e sfruttabile.
Il nucleo della catena di sfruttamento attualmente pubblica non è la semplice SSRF, ma una combinazione di SSRF con il meccanismo dei servizi Axis/Java Web, la scrittura di log o la logica di elaborazione dei file di descrizione del deployment.
L'idea complessiva può essere riassunta come:
Recupero informazioni da WebDialer
↓
Ottenere il nome host reale del target
↓
Attivare SSRF tramite interfacce correlate a cmplatform
↓
Accedere a percorsi interni di WebDialer / Axis management
↓
Scrivere o distribuire contenuti controllabili di descrizione del servizio
↓
Formare una nuova capacità di chiamata di servizio o scrittura di file
↓
Trasformare la capacità di scrittura di file in script accessibili via Web
↓
In ambienti specifici, raggiungere ulteriormente l'esecuzione di comandi
Dalla progettazione della catena, il nome host è un punto chiave. Alcune logiche di filtraggio intercettano indirizzi locali comuni come 127.0.0.1, localhost, ma il nome host reale del target potrebbe essere permesso nel successivo flusso di richieste. Pertanto, il PoC prima estrae il nome host reale dalle informazioni WSDL di WebDialer, quindi lo utilizza come prefisso per l'accesso interno nella catena SSRF.
Il secondo punto chiave è la logica relativa al servizio Axis. Il PoC non carica direttamente file nella directory Web, ma tramite la catena di elaborazione interna del server, fa sì che i componenti lato server scrivano contenuti controllabili dall'attaccante in percorsi specifici. Questo processo è essenzialmente una combinazione di "richiesta interna lato server + comportamento di configurazione/scrittura di log dei componenti + path traversal/controllo del percorso".
Il terzo punto chiave è la scrittura in due fasi. La prima fase viene solitamente utilizzata per creare un punto di ingresso più stabile per la scrittura di file; la seconda fase scrive lo script di esecuzione comandi in una directory accessibile via Web. Il motivo è che scrivere direttamente una logica completa di esecuzione comandi in un unico passo via SSRF potrebbe essere influenzato da codifica, lunghezza, struttura XML, permessi del percorso e comportamento di parsing lato server, mentre l'approccio in due fasi rende più facile separare payload complessi.
Questo articolo non fornisce messaggi di attacco completi o contenuti di WebShell. Per la difesa e la verifica è sufficiente comprendere le seguenti caratteristiche principali:
Punto di ingresso richiesta esterna: interfacce relative allo stato di installazione di cmplatform
Punto di ingresso recupero informazioni: interfacce WSDL/services di WebDialer
Destinazione di inoltro interno: percorsi relativi a WebDialer / Axis / AdminService
Comportamenti chiave: SSRF, richieste interne lato server, scrittura controllata di file, atterraggio di file accessibili via Web
Rischio finale: scrittura arbitraria di file, atterraggio di WebShell, esecuzione comandi, percorso di elevazione a root
Il PoC deve prima ottenere il nome host reale del target, non solo utilizzare l'indirizzo IP o il nome di dominio esterno.
Il motivo è che la logica di filtraggio SSRF non giudica solo la destinazione finale della connessione, ma potrebbe anche verificare il campo hostname, la stringa URL, parole chiave di indirizzi locali, ecc. Indirizzi locali comuni come 127.0.0.1, localhost potrebbero essere bloccati, mentre il nome host reale del dispositivo in alcuni scenari potrebbe essere considerato un nome di nodo legittimo.
Le interfacce utilizzabili per il giudizio ausiliario sono solitamente correlate alle informazioni WSDL di WebDialer. Dopo aver accesso a tale WSDL, la risposta può contenere l'indirizzo del servizio, un campo location o altri identificatori host risolvibili. Il PoC estrae il nome host dall'URL nel testo di risposta e lo utilizza come destinazione dell'accesso interno per la fase successiva di SSRF.
Il criterio di giudizio per questa fase dovrebbe essere:
Se la risoluzione del nome host fallisce, il PoC potrebbe ripiegare sull'IP del target, ma ciò riduce significativamente il tasso di successo. In ambienti reali, le cause comuni del fallimento della risoluzione del nome host includono: WebDialer non abilitato, interfaccia limitata da controlli di accesso, risposta riscritta da proxy inverso, configurazione incompleta del certificato o del servizio.
Il punto di attivazione SSRF si trova nella logica di query sullo stato di installazione correlata a cmplatform. Questa funzionalità era originariamente destinata a interrogare lo stato di installazione dei nodi del cluster; il server assembla una richiesta interna in base all'identificatore del nodo o al nome host fornito dall'utente.
Il problema principale della vulnerabilità è che il parametro hostname controllabile dall'attaccante non viene strettamente limitato a nomi di nodo legittimi o host fidati, consentendo di costruire percorsi di accesso interno più complessi. Il server successivamente effettua una richiesta per conto dell'attaccante verso un'interfaccia interna.
Il punto chiave in questa fase non è "poter accedere a un URL esterno", ma "far sì che il dispositivo CUCM stesso acceda alle interfacce di gestione WebDialer / Axis raggiungibili internamente". Pertanto, il valore della SSRF deriva da due aspetti:
Nella verifica autorizzata, non si può giudicare il successo della SSRF solo in base al codice di stato HTTP. Prove più affidabili includono:
Nella catena pubblica, la SSRF viene ulteriormente utilizzata per accedere a interfacce di servizio Axis e tentare di scrivere contenuti di descrizione del deployment del servizio. L'attaccante costruisce una struttura XML/WSDD speciale in modo che i componenti lato server, durante l'elaborazione, scrivano contenuti controllabili in un percorso specificato.
L'essenza di questa fase non è il tradizionale caricamento di file, ma l'abuso della logica di elaborazione dei componenti lato server:
Parametri controllabili dall'utente
↓
Richiesta interna SSRF
↓
Elaborazione del servizio Axis / Web
↓
Scrittura controllabile della descrizione del deployment o di log
↓
Generazione di file in un percorso specificato
Da un punto di vista dell'analisi della sicurezza, ci sono diversi punti chiave:
Pertanto, il punto ad alto rischio di CVE-2026-20230 non è solo la SSRF, ma la capacità della SSRF di attraversare i confini di fiducia, entrare nella catena di gestione/distribuzione dei servizi interni e infine attivare la scrittura controllabile di file.
Il progetto del PoC adotta generalmente una scrittura in due fasi, invece di completare l'esecuzione del comando in un unico passo.
La prima fase serve a creare una semplice capacità di scrittura di file. L'obiettivo di questa fase è consentire all'attaccante di scrivere contenuti in una posizione specificata sul server attraverso un percorso accessibile via Web.
La seconda fase utilizza la capacità di scrittura della prima fase per scrivere lo script di esecuzione comandi in una directory accessibile via Web. Successivamente, l'attaccante può attivare l'esecuzione di comandi di sistema tramite parametri HTTP.
I vantaggi del progetto in due fasi sono:
Tuttavia, dal punto di vista della difesa, la scrittura in due fasi crea anche superfici di rilevamento più chiare:
Il flusso del PoC attuale può essere riassunto come:
Dal punto di vista del tasso di successo dello sfruttamento, i punti di fallimento più critici sono solitamente concentrati in:
Pertanto, questo PoC ha un'alta sfruttabilità su versioni affette specifiche e con percorsi predefiniti corrispondenti, ma non è stabile e universale su tutti gli asset CUCM.
Il giudizio di successo per CVE-2026-20230 non può basarsi solo sul completamento dell'esecuzione dello script. Un giudizio più ragionevole dovrebbe essere suddiviso in quattro livelli.
Condizioni:
WSDL di WebDialer accessibile
oppure pagina services accessibile
oppure interfacce correlate a cmplatform accessibili
Questo indica solo che il target presenta una superficie di attacco correlata, non che la vulnerabilità sia sfruttabile.
Condizioni:
La versione del target è nell'intervallo interessato
WebDialer è abilitato
Il nome host può essere risolto
Il punto di ingresso SSRF restituisce una risposta anomala ma ragionevole dal server
In questo caso, si dovrebbe continuare con la verifica combinando log del server o ambienti autorizzati.
Condizioni:
Dopo SSRF, nel server appaiono file controllati
oppure nella directory Web appaiono file anomali creati da processi del server
oppure nella pagina services appaiono nuovi servizi anomali
oppure nei log appaiono contenuti controllabili di descrizione del deployment
A questo livello, si può confermare che la catena ha superato la fase SSRF ordinaria, entrando nel rischio di scrittura arbitraria di file.
Condizioni:
Lo script accessibile via Web scritto viene analizzato ed eseguito con successo
e attraverso comandi di test autorizzati si possono osservare i risultati dell'esecuzione sul server
Solo questo livello indica che l'esecuzione remota di comandi è avvenuta. La riuscita della scrittura di file non equivale necessariamente al successo di RCE, ma in ambienti come CUCM con servizi ad alta privilegio, la scrittura di file è già sufficiente a costituire un rischio grave.
Questo articolo non fornisce esempi di esecuzione di exploit utilizzabili direttamente per attacchi.
In ambienti autorizzati, si consiglia di utilizzare modalità di "sola lettura" o "verifica non distruttiva", ad esempio:
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
Gli elementi di controllo suggeriti includono:
Non si consiglia di eseguire la scrittura completa di file o la verifica di esecuzione comandi su sistemi di produzione. Anche in test autorizzati, si dovrebbe dare priorità all'esecuzione in ambienti di laboratorio isolati, ambienti snapshot o secondo il flusso di verifica suggerito dal produttore.
I confini di sicurezza per questo tipo di PoC devono essere chiari.
Primo, non eseguire comandi per impostazione predefinita. La fase di esecuzione comandi è una verifica ad alto rischio, che può facilmente causare modifiche dello stato del sistema, contaminazione dei log, anomalie di servizio o risposte coordinate da dispositivi di sicurezza.
Secondo, non scrivere WebShell per impostazione predefinita. Anche se si scrive un file di test, potrebbe essere giudicato come intrusioni reali da EDR, strumenti di rilevamento WebShell, monitoraggio dell'integrità dei file o sistemi di audit di conformità.
Terzo, non effettuare scansioni batch su target Internet pubblici. Questa vulnerabilità non richiede autenticazione e i target sono spesso infrastrutture di comunicazione aziendali; la scansione e lo sfruttamento non autorizzati comportano rischi estremamente elevati.
Quarto, la modalità di controllo dovrebbe essere separata dalla modalità di sfruttamento. Si consiglia di suddividere il PoC in due script: uno solo per l'identificazione degli asset e la valutazione dello stato del servizio, l'altro per la verifica della scrittura di file solo in laboratori locali o ambienti esplicitamente autorizzati.
Quinto, limitare l'ambito del target. Il PoC può includere meccanismi di protezione come indirizzi locali, subnet private, domini in whitelist, parametri di conferma di autorizzazione, per evitare di colpire erroneamente sistemi di terze parti.
Sesto, disabilitare per impostazione predefinita la fase RCE. Anche se si mantiene il codice di ricerca, si dovrebbe richiedere all'utente di passare esplicitamente un parametro di conferma autorizzazione prima di consentire la scrittura di file o la verifica di esecuzione comandi.
Dal punto di vista del rilevamento del traffico, non si può abbinare solo un nome di file fisso, un nome di servizio fisso o un nome JSP fisso. I nomi di servizio, i nomi di file e i percorsi nel PoC pubblico possono essere modificati, quindi una singola regola di stringa è facile da eludere.
Un'idea di rilevamento più ragionevole è estrarre caratteristiche attorno alle fasi della catena di attacco.
Attenzione a:
/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing
Se in breve tempo un client esterno accede al WSDL e poi alle interfacce di stato di installazione di cmplatform, aumentare il livello di rischio.
Attenzione a:
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
parametro hostname anomalamente lungo
parametro hostname contenente separatori di percorso codificati in URL
parametro hostname contenente caratteristiche di percorsi interni come webdialer, services, AdminService, platformcom, installstages
Il punto chiave di questa fase è che il parametro hostname non assomiglia più a un normale nome host, ma presenta caratteristiche di percorsizzazione, URLizzazione, codifica e XML.
Attenzione a:
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
Quando questi campi appaiono contemporaneamente, sospettare fortemente che l'attaccante stia tentando di scrivere contenuti controllabili attraverso il file di descrizione del deployment del servizio Axis.
Attenzione a:
axis2-web
platform-services
Scrittura di file JSP
Parametri contenenti combinazione di nome file e contenuto file
Path traversal nella directory Web
common/log/taos-log-a
tomcat/webapps
Se nel traffico di attacco appaiono molti ../, path traversal codificati in URL, estensione JSP e percorsi Tomcat WebApp, giudicare come ad alto rischio.
Attenzione a:
Accesso a JSP nuovo
Parametri richiesta contenenti pwd, cmd, command, exec, i e altri parametri di comando
Risposta contenente formato di output di comandi di sistema
Stesso IP di origine completa in breve tempo le azioni consecutive di recupero WSDL, SSRF, scrittura, esecuzione
Dal punto di vista della progettazione delle regole, si consiglia di adottare un rilevamento per fasi:
1. Recupero informazioni WebDialer: allarme a basso o medio rischio.
2. SSRF cmplatform con hostname anomalo: allarme ad alto rischio.
3. Caratteristiche combinate Axis/WSDD/LogHandler: allarme grave.
4. Scrittura di file JSP o parametri di esecuzione comandi: allarme grave.
5. Correlazione multi-fase: elevare direttamente a evento di intrusione.
## 13. Raccomandazioni per indagine e raccolta prove
Durante l'indagine di emergenza, si consiglia di verificare prioritariamente le seguenti posizioni e fenomeni:
1. Nei log di accesso di WebDialer, esistono enumerazioni anomale di WSDL e services?
2. Nei log di accesso di cmplatform, esistono richieste anomale a `installClusterStatusExecute`?
3. Il parametro hostname contiene contenuti come codifica URL, path traversal, Axis, WSDD, LogHandler?
4. Nella directory Web, esistono file JSP anomali?
5. Nella pagina dei servizi Axis o nella configurazione, esistono nomi di servizio anomali?
6. Nei log di Tomcat, nei log dei servizi di piattaforma, esistono descrizioni di deployment anomale, errori di parsing XML o registrazioni di scrittura di percorso?
7. In `/tmp`, directory WebApp, directory dei log, esistono file di test o file sconosciuti?
8. Esistono accessi consecutivi multi-fase dallo stesso IP di origine in un breve periodo di tempo?
9. Esistono tracce anomale di esecuzione di comandi di sistema, record di creazione di processi o comportamenti relativi a shell?
10. Esistono file anomali relativi a privilegi root, attività pianificate, voci di avvio o tracce di persistenza?
Se si sospetta che il sistema sia stato compromesso, isolare prioritariamente l'accesso all'interfaccia di gestione, conservare log e prove del filesystem, quindi procedere con l'aggiornamento delle patch, la pulizia delle WebShell, la pulizia dei servizi anomali e la rotazione di account/credenziali.
## 14. Raccomandazioni per la riparazione e la mitigazione
Il metodo di riparazione fondamentale è aggiornare alla versione di riparazione ufficiale di Cisco o applicare il pacchetto di riparazione temporanea fornito da Cisco.
Raccomandazioni generali per la gestione:
1. Confermare immediatamente la versione di Unified CM / Unified CM SME.
2. Verificare se il servizio WebDialer è abilitato.
3. Se il servizio WebDialer non è necessario per le attività aziendali, disabilitarlo immediatamente.
4. Aggiornare alla versione di riparazione ufficiale di Cisco.
5. Per l'ambiente Release 15, se non è possibile aggiornare temporaneamente, applicare il corrispondente file COP secondo le indicazioni di Cisco.
6. Limitare le origini di accesso all'interfaccia di gestione e ai servizi correlati a WebDialer.
7. Aggiungere rilevamenti per richieste anomale a cmplatform, WebDialer, Axis/WSDD su dispositivi perimetrali, WAF, IDS/IPS.
8. Verificare se sono già comparsi JSP anomali, servizi Axis anomali o file sconosciuti.
9. Effettuare una retrospettiva dei log sui sistemi esposti, coprendo prioritariamente i record di accesso successivi al 3 giugno 2026.
10. Se si trovano prove di scrittura di file o esecuzione comandi, trattare come compromissione dell'host, non solo applicare la patch.
## 15. Conclusione
Il punto chiave di CVE-2026-20230 non è l'esposizione di una singola interfaccia, ma la combinazione tra WebDialer di CUCM, la logica di query sullo stato di installazione di cmplatform, l'elaborazione interna del servizio Axis e la capacità di scrittura di file, che formano un confine di fiducia che può essere concatenato e violato.
Questa catena può essere riassunta come:
```text
Richiesta esterna non autenticata
↓
Conferma superficie di esposizione WebDialer
↓
Recupero nome host reale
↓
cmplatform SSRF
↓
Accesso interno al servizio Axis
↓
Scrittura controllabile della descrizione del servizio o di log
↓
Atterraggio di file accessibili via Web
↓
Rischio di esecuzione comandi ed elevazione a root
L'effettiva sfruttabilità dipende da: se WebDialer è abilitato, se la versione target è interessata, se il filtraggio del nome host può essere aggirato, se il punto di atterraggio del percorso corrisponde, se il container Web esegue il file scritto e se il target ha applicato le patch.
Dal punto di vista della difesa, non si può fare affidamento solo su "esiste un certo file JSP" per giudicare un attacco. Un approccio più sicuro è effettuare un rilevamento correlato basato sulla catena multi-fase: recupero informazioni WSDL, hostname anomalo di cmplatform, caratteristiche Axis/WSDD, scrittura con path traversal, accesso a JSP atterrato e accesso a parametri di comando. Se più fasi appaiono consecutivamente in breve tempo dalla stessa origine, gestire come evento di intrusione ad alto rischio.