w5m1n9/cisco-unified-communications-manager-server-side-forgery-request-vulnerability-cve-2026-20230Analyse CVE-2026-20230 SSRF vers écriture de fichier arbitraire et RCE dans Cisco Unified Communications Manager, fournissant une dérivation de PoC, une logique de détection et des conseils défensifs.
Périmètre d'application : Utilisation uniquement sur des environnements de test locaux, des environnements de reproduction autorisés, pour la validation de vulnérabilités et l'analyse de règles de protection. Ne pas utiliser sur des cibles non autorisées. Cet article analyse principalement la chaîne d'exploitation de CVE-2026-20230, les phénomènes vérifiables, la logique de jugement et les approches de protection. Il ne fournit pas de paquets d'attaque, de contenus WebShell ou de charges d'exécution de commandes directement reproductibles.
CVE-2026-20230 est une vulnérabilité de falsification de requête côté serveur (SSRF) dans Cisco Unified Communications Manager (Unified CM / CUCM) et Cisco Unified Communications Manager Session Management Edition (Unified CM SME). Cette vulnérabilité provient d'une validation insuffisante des entrées dans le traitement de certaines requêtes HTTP. Un attaquant peut, sans authentification, construire une requête permettant à l'appareil affecté d'accéder à des interfaces internes ou à des ressources locales pour le compte de l'attaquant.
L'impact de cette vulnérabilité ne se limite pas à une simple détection SSRF. Des analyses techniques publiques montrent que, sous certaines conditions de version et de services activés, la SSRF peut être enchaînée à une capacité d'écriture arbitraire de fichier. L'attaquant peut écrire du contenu contrôlé dans le système d'exploitation sous-jacent, puis, en exploitant des répertoires accessibles par le conteneur Web ou des mécanismes de chargement de composants serveur, transformer cette écriture en exécution de code.
Cisco a attribué à cette vulnérabilité un score CVSS v3.1 de 8,6, avec le vecteur suivant :
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
Bien que le score CVSS soit élevé, Cisco a marqué le Security Impact Rating de cette vulnérabilité comme Critique. La raison est qu'une exploitation réussie permet d'écrire dans les fichiers du système d'exploitation sous-jacent, avec une possibilité d'élévation vers les privilèges root.
Il est important de noter que la condition préalable clé pour cette vulnérabilité est que le service WebDialer doit être activé. WebDialer est désactivé par défaut, donc la simple présence d'un actif CUCM ne permet pas de conclure que la vulnérabilité est exploitable. Le jugement réel du risque nécessite de vérifier simultanément la version du produit, l'état des correctifs, l'état du service WebDialer et l'accessibilité des interfaces associées.
Cette vulnérabilité n'est pas une vulnérabilité Web classique du type "l'accès à une URL fixe renvoyant 200 signifie sa présence". Sa chaîne d'exploitation comprend au moins trois niveaux :
Par conséquent, accéder isolément à une interface et obtenir un code HTTP 200, 302, 401, 404 ou 500 ne prouve ni l'existence ni l'absence de la vulnérabilité.
Par exemple, le fait que l'interface WSDL de WebDialer soit accessible indique uniquement que la cible expose des fonctionnalités liées à WebDialer, sans prouver qu'une SSRF ultérieure pourra contourner les filtres. De même, l'accessibilité de l'interface installClusterStatusExecute ne prouve pas à elle seule l'écriture arbitraire de fichier. Inversement, si une étape renvoie une anomalie, cela peut être dû à la version cible, aux correctifs, à la résolution du nom d'hôte, aux permissions de chemin, à un proxy ou à l'état du service, sans nécessairement impliquer que la chaîne entière n'existe pas.
Une approche plus fiable consiste à utiliser une combinaison de preuves multi-étapes :
Ce n'est que lorsque "WebDialer activé + version affectée + comportement SSRF établi + écriture de fichier contrôlé établie" sont tous présents que l'on doit considérer la vulnérabilité comme hautement fiable et exploitable.
Le cœur de la chaîne d'exploitation publique actuelle n'est pas simplement une SSRF, mais une combinaison de la SSRF avec les mécanismes Axis/Java Web Service, l'écriture de journaux ou le traitement de fichiers de descripteurs de déploiement.
L'approche globale peut être résumée ainsi :
Récupération d'informations via WebDialer
↓
Obtention du nom d'hôte réel de la cible
↓
Déclenchement de la SSRF via une interface liée à cmplatform
↓
Accès aux chemins internes de gestion WebDialer / Axis
↓
Écriture ou déploiement de descriptions de services contrôlés
↓
Création d'une nouvelle capacité de service invocable ou d'écriture de fichier
↓
Transformation de la capacité d'écriture en script accessible via le Web
↓
Atteinte, dans des environnements spécifiques, de l'exécution de commandes
Du point de vue de la conception de la chaîne, le nom d'hôte (hostname) est un élément clé. Certaines logiques de filtrage bloquent les adresses locales courantes comme 127.0.0.1 ou localhost, mais le nom d'hôte réel de la cible peut être autorisé à entrer dans le flux de requêtes suivant. Par conséquent, le PoC commence par extraire le nom d'hôte réel des informations WSDL de WebDialer, puis l'utilise comme préfixe d'accès interne dans la chaîne SSRF.
Le deuxième point clé concerne la logique liée au service Axis. Le PoC ne télécharge pas directement des fichiers dans un répertoire Web, mais utilise la chaîne de traitement interne du serveur pour que les composants serveur écrivent du contenu contrôlé par l'attaquant dans un chemin spécifique. Ce processus est essentiellement une combinaison de "requête interne côté serveur + comportement d'écriture de journal/config de composant + traversée de chemin/contrôle de chemin".
Le troisième point clé est l'écriture en deux phases. La première phase établit généralement un point d'entrée plus stable pour l'écriture de fichier, tandis que la seconde phase écrit le script d'exécution de commandes dans un répertoire accessible via le Web. Cette approche est adoptée car écrire directement la logique complète d'exécution de commandes via une seule étape SSRF peut être affecté par des problèmes d'encodage, de longueur, de structure XML, de permissions de chemin et de comportement de parsing serveur. Une approche en deux phases facilite la fragmentation des charges complexes.
Cet article ne fournit pas de paquets d'exploitation complets ni de contenus WebShell. Pour la protection et la validation, il suffit de comprendre les caractéristiques principales suivantes :
Point d'entrée de requête externe : interface liée à l'état d'installation cmplatform
Point d'entrée de récupération d'informations : interfaces WebDialer WSDL / services
Cible de redirection interne : chemins WebDialer / Axis / AdminService
Comportements clés : SSRF, requêtes internes côté serveur, écriture de fichier contrôlé, atterrissage de fichier accessible via le Web
Risques finaux : écriture arbitraire de fichier, atterrissage de WebShell, exécution de commandes, chemin d'élévation vers les privilèges root
Le PoC doit d'abord obtenir le nom d'hôte réel (hostname) de la cible, et non simplement utiliser l'adresse IP ou le nom de domaine externe.
La raison est que la logique de filtrage SSRF ne se limite pas à vérifier la destination finale de la connexion, mais peut également valider le champ hostname, la chaîne d'URL, les mots-clés d'adresse locale, etc. Les adresses locales courantes comme 127.0.0.1 ou localhost peuvent être bloquées, tandis que le nom d'hôte réel de l'appareil peut, dans certains scénarios, être considéré comme un nom de nœud légitime.
Les interfaces pouvant aider à ce jugement sont généralement liées aux informations WSDL de WebDialer. Après avoir accédé à ce type de WSDL, la réponse peut contenir une adresse de service, un champ location ou d'autres identifiants d'hôte analysables. Le PoC extrait le hostname de l'URL dans le texte de réponse et l'utilise comme cible d'accès interne pour la phase SSRF suivante.
Les critères de jugement à cette étape doivent être :
Si l'extraction du hostname échoue, le PoC peut revenir à l'adresse IP cible, mais cela réduit considérablement le taux de réussite. Dans un environnement réel, les raisons courantes d'échec d'extraction du hostname incluent : WebDialer non activé, interface restreinte par le contrôle d'accès, réponse modifiée par un proxy inverse, certificat ou configuration de service incomplète.
Le point de déclenchement de la SSRF se situe dans la logique d'interrogation de l'état d'installation liée à cmplatform. Cette fonctionnalité est conçue pour interroger l'état d'installation des nœuds du cluster. Le serveur assemble une requête interne en fonction de l'identifiant de nœud ou du hostname soumis par l'utilisateur.
Le problème central de la vulnérabilité est que le paramètre hostname, contrôlable par l'attaquant, n'est pas strictement limité à un nom de nœud légitime ou à un hôte de confiance, ce qui permet de le construire en un chemin d'accès interne plus complexe. Le serveur envoie ensuite une requête à l'interface interne pour le compte de l'attaquant.
À ce stade, l'élément clé n'est pas "pouvoir accéder à une URL externe", mais "pouvoir faire en sorte que l'appareil CUCM lui-même accède à ses interfaces de gestion WebDialer / Axis internes accessibles". Par conséquent, la valeur de la SSRF provient de deux aspects :
Dans une validation autorisée, il ne faut pas se fier uniquement au code de statut HTTP pour juger du succès de la SSRF. Des preuves plus fiables incluent :
Dans la chaîne publique, la SSRF est ensuite utilisée pour accéder aux interfaces de service Axis et tenter d'écrire du contenu de descripteur de déploiement de service. L'attaquant construit une structure XML/WSDD spéciale pour que les composants serveur écrivent du contenu contrôlé dans un chemin spécifié lors du traitement.
Cette étape n'est pas un téléchargement de fichier traditionnel, mais un abus de la logique de traitement des composants serveur :
Paramètres contrôlables par l'utilisateur
↓
Requête interne SSRF
↓
Traitement par le service Axis / Web
↓
Écriture de descripteurs de déploiement contrôlés ou de journaux
↓
Génération de fichier à un chemin spécifié
D'un point de vue d'analyse de sécurité, plusieurs points clés sont à noter :
Par conséquent, le point dangereux de CVE-2026-20230 n'est pas seulement la SSRF, mais le fait que la SSRF puisse franchir la frontière de confiance, entrer dans la chaîne de déploiement interne de gestion/service, et finalement déclencher une écriture de fichier contrôlé.
La conception du PoC adopte généralement une écriture en deux phases plutôt qu'une exécution de commande en une seule étape.
La première phase sert à créer une capacité simple d'écriture de fichier. L'objectif est de permettre à l'attaquant d'écrire du contenu dans un emplacement spécifié du serveur via un chemin accessible par le Web.
La deuxième phase utilise la capacité d'écriture de la première phase pour écrire un script d'exécution de commandes dans un répertoire accessible par le Web. Ensuite, l'attaquant peut déclencher l'exécution de commandes système via des paramètres HTTP.
Les avantages de la conception en deux phases sont :
Mais du point de vue défensif, l'écriture en deux phases offre également une surface de détection plus claire :
Le flux du PoC actuel peut être résumé comme suit :
Du point de vue du taux de succès de l'exploitation, les points de défaillance les plus critiques sont généralement :
Par conséquent, ce PoC a une exploitabilité élevée sur les versions affectées spécifiques avec des chemins par défaut correspondants, mais n'est pas un one-shot stable pour tous les actifs CUCM.
Le jugement du succès de CVE-2026-20230 ne doit pas se limiter à vérifier si le script s'est terminé. Une approche plus raisonnable consiste à le diviser en quatre niveaux.
Conditions :
WSDL de WebDialer accessible
ou page services accessible
ou interface liée à cmplatform accessible
Cela indique seulement que la cible présente une surface d'attaque potentielle, sans prouver que la vulnérabilité est exploitable.
Conditions :
Version cible dans la plage affectée
WebDialer activé
Hostname peut être extrait
Point d'entrée SSRF renvoie une réponse anormale mais raisonnable du serveur
Dans ce cas, il convient de poursuivre la validation avec les journaux serveur ou dans un environnement de test autorisé.
Conditions :
Après SSRF, apparition d'un fichier contrôlé côté serveur
ou apparition, dans le répertoire Web, d'un fichier anormal créé par un processus serveur
ou apparition d'un nouveau service anormal sur la page services
ou présence, dans les journaux, de contenu descriptif de déploiement contrôlé
À ce niveau, on peut confirmer que la chaîne de vulnérabilité a dépassé la phase SSRF ordinaire et est entrée dans le risque d'écriture arbitraire de fichier.
Conditions :
Le script écrit, accessible via le Web, est interprété et exécuté avec succès
et il est possible d'observer le résultat de l'exécution côté serveur via une commande de test autorisée
Seul ce niveau permet de juger qu'une exécution de commande à distance est établie. L'écriture réussie d'un fichier n'entraîne pas nécessairement une RCE, mais dans un environnement de service à haute privilège comme CUCM, l'écriture de fichier constitue déjà un risque sérieux.
Cet article ne fournit pas d'exemple d'exécution d'exploit directement utilisable pour une attaque.
Dans un environnement autorisé, il est recommandé d'utiliser des méthodes de "vérification en lecture seule" ou de "validation non destructive", par exemple :
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
Les éléments de vérification suggérés incluent :
Il n'est pas recommandé d'exécuter une validation complète d'écriture de fichier ou d'exécution de commandes sur des systèmes de production. Même pour des tests autorisés, il est préférable de les réaliser d'abord dans des environnements de test isolés, des environnements avec snapshots ou selon les processus de validation recommandés par le fournisseur.
Les limites de sécurité de ce type de PoC doivent être clairement définies.
Premièrement, l'exécution de commandes ne doit pas être effectuée par défaut. La phase d'exécution de commandes est une validation à haut risque, susceptible de modifier l'état du système, de polluer les journaux, de provoquer des anomalies de service ou de déclencher des réponses en chaîne des dispositifs de sécurité.
Deuxièmement, l'écriture de WebShell ne doit pas être effectuée par défaut. Même s'il s'agit d'un fichier de test, il peut être considéré comme une intrusion réelle par les EDR, les solutions anti-WebShell, la surveillance de l'intégrité des fichiers ou les systèmes d'audit de conformité.
Troisièmement, ne pas effectuer de détection massive sur des cibles Internet publiques. Cette vulnérabilité ne nécessite pas d'authentification, et les cibles sont souvent des infrastructures de communication d'entreprise. L'analyse et l'exploitation non autorisées présentent un risque extrêmement élevé.
Quatrièmement, le mode de vérification doit être séparé du mode d'exploitation. Il est recommandé de diviser le PoC en deux scripts : un pour l'identification de l'actif et l'évaluation de l'état du service, et un autre pour la validation de l'écriture de fichier uniquement dans un environnement de test local ou explicitement autorisé.
Cinquièmement, la portée cible doit être limitée. Le PoC peut inclure des mécanismes de protection tels que les adresses locales, les plages de réseaux privés, les noms de domaine de la liste blanche, les paramètres de confirmation d'autorisation, afin d'éviter d'impacter par erreur des systèmes tiers.
Sixièmement, la phase RCE doit être désactivée par défaut. Même si le code de recherche est conservé, l'utilisateur doit explicitement fournir un paramètre de confirmation d'autorisation avant d'autoriser l'entrée dans la phase d'écriture de fichier ou d'exécution de commandes.
Du point de vue de la détection du trafic, il ne faut pas se contenter de chercher un nom de fichier, un nom de service ou un nom de JSP fixe. Les noms de service, de fichier et les chemins du PoC public peuvent être modifiés, et une règle basée sur une chaîne unique peut facilement passer à côté.
Une approche de détection plus raisonnable consiste à extraire des caractéristiques par étapes de la chaîne d'attaque.
Points d'attention :
/webdialer/Version.jws?wsdl
/webdialer/services
WSDL de WebDialer
Liste des services Axis
Si, en peu de temps, un client externe accède au WSDL puis aux interfaces d'état d'installation de cmplatform, le niveau de risque doit être augmenté.
Points d'attention :
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
Augmentation anormale du paramètre hostname
Présence de séparateurs de chemin encodés en URL dans le paramètre hostname
Présence dans le paramètre hostname de caractéristiques de chemins internes comme webdialer, services, AdminService, platformcom, installstages
À cette étape, le paramètre hostname ne ressemble plus à un nom d'hôte normal, mais présente des caractéristiques de chemin, d'URL, d'encodage et de XML.
Points d'attention :
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
Si ces champs apparaissent simultanément, il faut fortement suspecter une tentative d'écriture de contenu contrôlé via le fichier de descripteur de déploiement du service Axis.
Points d'attention :
axis2-web
platform-services
Écriture de fichiers JSP
Présence dans les paramètres d'une combinaison nom de fichier et contenu
Traversée de chemin vers le répertoire Web
common/log/taos-log-a
tomcat/webapps
Si le trafic d'attaque contient de nombreux ../, des traversées de chemin encodées en URL, des extensions JSP et des chemins Tomcat WebApp, cela doit être considéré comme à haut risque.
Points d'attention :
Nouveau JSP accédé
Présence dans les paramètres de la requête de paramètres de commande comme pwd, cmd, command, exec, i
Présence dans la réponse de formats de sortie de commandes système
Même IP source effectuant successivement en peu de temps les actions : obtention WSDL, SSRF, écriture, exécution
Du point de vue de la conception des règles, il est recommandé d'utiliser une détection par phases :
Lors d'une réponse à incident, il est recommandé de vérifier les emplacements et phénomènes suivants :
installClusterStatusExecute ?/tmp, les répertoires WebApp, les répertoires de journaux ?Si une compromission est suspectée, il faut d'abord isoler l'accès à la surface de gestion, conserver les journaux et les preuves du système de fichiers, puis procéder à la mise à jour des correctifs, au nettoyage des WebShells, à la suppression des services anormaux et à la rotation des comptes/mots de passe.
La solution fondamentale est de passer à la version corrigée officielle de Cisco ou d'appliquer le correctif temporaire fourni par le constructeur.
Les recommandations générales de traitement sont les suivantes :
L'élément clé de CVE-2026-20230 n'est pas l'exposition d'une seule interface, mais la défaillance de la frontière de confiance entre WebDialer de CUCM, la logique d'interrogation de l'état d'installation de cmplatform, le traitement interne du service Axis et la capacité d'écriture de fichier, qui forment une chaîne exploitable.
Cette chaîne peut être résumée comme suit :
Requête externe non authentifiée
↓
Confirmation de la surface d'exposition WebDialer
↓
Obtention du hostname réel
↓
SSRF via cmplatform
↓
Accès au service interne Axis
↓
Écriture de descripteurs de service contrôlés ou de journaux
↓
Atterrissage de fichier accessible via le Web
↓
Risque d'exécution de commandes et d'élévation vers les privilèges root
L'exploitabilité réelle dépend de l'activation de WebDialer, de la version cible affectée, de la possibilité de contourner le filtrage du hostname, de la correspondance du point d'atterrissage du chemin, de l'exécution du fichier écrit par le conteneur Web, et de l'application ou non du correctif sur la cible.
Du point de vue défensif, il ne faut pas se fier uniquement à la "présence d'un fichier JSP" pour juger d'une attaque. Une approche plus fiable consiste à effectuer une détection corrélée sur la chaîne multi-étapes : collecte d'informations WSDL, hostname anormal dans cmplatform, caractéristiques Axis/WSDD, écriture avec traversée de chemin, accès au JSP atterri et accès aux paramètres de commande. Si plusieurs de ces étapes se produisent consécutivement en peu de temps depuis la même source, cela doit être traité comme un événement d'intrusion à haut risque.