CVE-2026-20230 Cisco Unified Communications Manager SSRF Écriture Arbitraire de Fichier vers RCE – Processus de Déduction et Réflexions

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.

1. Contexte de la vulnérabilité

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.

2. Pourquoi ne peut-on pas se contenter de vérifier si une interface renvoie 200 ?

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 :

1. Interfaces externes accessibles liées à WebDialer ou cmplatform.
2. Logique d'accès interne pouvant être affectée par la SSRF.
3. Comportements d'écriture de fichier ou de déploiement de service pouvant être déclenchés par des requêtes internes.

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 :

1. Confirmer que la cible est Cisco Unified CM / Unified CM SME.
2. Confirmer que le service WebDialer est activé.
3. Confirmer la possibilité d'obtenir le nom d'hôte réel (hostname) de la cible ou un identifiant de service interne.
4. Confirmer que le point d'entrée SSRF est accessible et qu'il existe des signes de requêtes internes initiées par le serveur.
5. Dans un environnement de test autorisé, confirmer la capacité à produire des preuves d'écriture de fichier contrôlé.
6. Combiner les journaux du serveur, les modifications du système de fichiers, les journaux du conteneur Web et les données d'alerte pour déterminer si un déclenchement a réellement eu lieu.

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.

3. Approche de construction du PoC

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 :