w5m1n9/cisco-unified-communications-manager-server-side-forgery-request-vulnerability-cve-2026-20230Analiza CVE-2026-20230 SSRF a escritura arbitraria de archivos y RCE en Cisco Unified Communications Manager, proporcionando derivación de PoC, lógica de detección y orientación defensiva.
Ámbito de aplicación: solo para entornos locales de pruebas, entornos de reproducción autorizados, verificación de vulnerabilidades y análisis de reglas de protección. No utilizar contra objetivos no autorizados. Este artículo analiza principalmente la cadena de explotación de CVE-2026-20230, fenómenos verificables, lógica de juicio e ideas de protección. No proporciona paquetes de ataque, contenido de WebShell o cargas de ejecución de comandos que puedan copiarse y ejecutarse directamente.
CVE-2026-20230 es una vulnerabilidad de Server-Side Request Forgery (SSRF) en Cisco Unified Communications Manager (Unified CM / CUCM) y Cisco Unified Communications Manager Session Management Edition (Unified CM SME). Esta vulnerabilidad se origina por una validación de entrada insuficiente en el flujo de procesamiento de solicitudes HTTP específicas. Un atacante puede construir solicitudes sin autenticación, haciendo que el dispositivo afectado acceda a interfaces internas o recursos locales en nombre del atacante.
El impacto de esta vulnerabilidad no se limita a la simple detección de SSRF. Análisis técnicos públicos muestran que, bajo ciertas versiones y condiciones de servicio habilitado, la SSRF se puede encadenar para lograr la capacidad de escritura arbitraria de archivos. El atacante puede escribir contenido controlable en rutas del sistema operativo subyacente y luego, aprovechando los directorios accesibles del contenedor web o el mecanismo de carga de componentes del servidor, convertir la escritura de archivos en ejecución de código.
Cisco otorgó a esta vulnerabilidad una puntuación CVSS v3.1 de 8.6, con el vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N
Aunque la puntuación CVSS indica Alta (High), Cisco clasificó el Security Impact Rating de esta vulnerabilidad como Crítico (Critical). La razón es que una explotación exitosa permite escribir archivos en el sistema operativo subyacente y podría escalar aún más a privilegios de root.
Es importante tener en cuenta que la condición previa clave para esta vulnerabilidad es que el servicio WebDialer debe estar habilitado. WebDialer está deshabilitado por defecto, por lo que no se puede juzgar la vulnerabilidad solo viendo un activo CUCM. El verdadero juicio de riesgo requiere confirmar simultáneamente la versión del producto, el estado del parche, el estado del servicio WebDialer y si las interfaces relacionadas son accesibles.
Esta vulnerabilidad no es una vulnerabilidad web común del tipo "existe si se accede a una URL fija y devuelve 200". Su cadena de explotación contiene al menos tres niveles:
Por lo tanto, acceder individualmente a una interfaz y obtener HTTP 200, 302, 401, 404 o 500 no puede probar directamente que la vulnerabilidad exista o no.
Por ejemplo, que la interfaz WSDL de WebDialer sea accesible solo indica que el objetivo expone funcionalidades relacionadas con WebDialer, pero no prueba que la SSRF posterior pueda eludir los filtros. Que la interfaz installClusterStatusExecute sea accesible solo indica que existe una entrada relacionada, pero no prueba por sí sola que la escritura arbitraria de archivos sea exitosa. Por el contrario, si un paso devuelve una anomalía, podría deberse a la versión del objetivo, el parche, la resolución del hostname, los permisos de ruta, el dispositivo proxy o el estado del servicio, y no necesariamente implica que toda la cadena de vulnerabilidad no exista.
Un juicio más fiable debería adoptar una combinación de evidencia en múltiples etapas:
Solo cuando "WebDialer habilitado + versión afectada + comportamiento SSRF confirmado + escritura controlada de archivos confirmada" ocurren simultáneamente, se debe juzgar como explotable con alta confianza.
El núcleo de la cadena de explotación pública actual no es la SSRF simple, sino una combinación de SSRF con el mecanismo del servicio Axis/Java Web, la escritura de registros o la lógica de procesamiento de archivos de descripción de despliegue.
La idea general se puede resumir como:
Obtención de información de WebDialer
↓
Obtención del hostname real del objetivo
↓
Activación de SSRF a través de interfaces relacionadas con cmplatform
↓
Acceso a rutas de administración internas de WebDialer / Axis
↓
Escritura o despliegue de contenido controlable de descripción de servicio
↓
Creación de una nueva capacidad de servicio invocable o escritura de archivos
↓
Conversión de la capacidad de escritura de archivos en un script accesible por web
↓
En entornos específicos, lograr ejecución de comandos
Desde el diseño de la cadena, el hostname es un punto clave. Parte de la lógica de filtrado puede interceptar direcciones locales comunes como 127.0.0.1 o localhost, pero el hostname real del objetivo puede permitirse en el flujo de solicitudes posterior. Por lo tanto, el PoC primero extraerá el nombre de host real de la información WSDL de WebDialer y luego lo usará como prefijo de acceso interno en la cadena SSRF.
El segundo punto clave es la lógica relacionada con el servicio Axis. El PoC no sube archivos directamente al directorio web, sino que, a través de la cadena de procesamiento interno del servidor, hace que los componentes del servidor escriban contenido controlable por el atacante en rutas específicas. Este proceso es esencialmente una combinación de "solicitud interna del servidor + comportamiento de escritura de configuración/registro de componentes + path traversal/control de ruta".
El tercer punto clave es la escritura en dos etapas. La primera etapa generalmente se usa para establecer una entrada de escritura de archivos más estable, y la segunda etapa escribe el script de ejecución de comandos en un directorio accesible por web. La razón de esto es que escribir directamente una lógica completa de ejecución de comandos en un solo paso a través de SSRF puede verse afectada por la codificación, la longitud, la estructura XML, los permisos de ruta y el comportamiento de análisis del servidor. El método de dos etapas facilita la división de cargas complejas.
Este artículo no proporciona paquetes de ataque completos ni contenido de WebShell. Para protección y verificación, solo es necesario comprender las siguientes características centrales:
Entrada de solicitud externa: interfaz relacionada con el estado de instalación de cmplatform
Entrada de obtención de información: interfaz relacionada con WebDialer WSDL / services
Objetivo de reenvío interno: rutas relacionadas con WebDialer / Axis / AdminService
Comportamientos clave: SSRF, solicitud interna del servidor, escritura controlada de archivos, archivo accesible por web
Riesgo final: escritura arbitraria de archivos, colocación de WebShell, ejecución de comandos, vía de escalada a privilegios de root
El PoC primero necesita obtener el hostname real del objetivo, no solo usar la dirección IP o el nombre de dominio externo.
La razón es que la lógica de filtrado de SSRF no solo juzga el destino final de la conexión, sino que también puede verificar el campo hostname, la cadena URL, las palabras clave de direcciones locales, etc. Las direcciones locales comunes como 127.0.0.1 o localhost pueden ser bloqueadas, mientras que el hostname real del dispositivo puede considerarse un nombre de nodo legítimo en algunos escenarios.
Las interfaces que se pueden usar para ayudar en el juicio generalmente están relacionadas con la información WSDL de WebDialer. Después de acceder a dicho WSDL, la respuesta puede contener la dirección del servicio, el campo location u otros identificadores de host analizables. El PoC extraerá el hostname de la URL en el texto de respuesta y lo usará como objetivo de acceso interno para la siguiente etapa de SSRF.
Los criterios de juicio en esta etapa deben ser:
Si falla el análisis del hostname, el PoC puede recurrir a la IP del objetivo, pero esto reduce significativamente la tasa de éxito. En entornos reales, las razones comunes del fallo de análisis del hostname incluyen: WebDialer no habilitado, interfaz restringida por control de acceso, respuesta reescrita por un proxy inverso, configuración de certificado o servicio incompleta.
El punto de activación de SSRF se encuentra en la lógica de consulta de estado de instalación relacionada con cmplatform. Esta función está diseñada originalmente para consultar el estado de instalación de los nodos del clúster. El servidor ensambla una solicitud interna basada en el identificador de nodo o hostname proporcionado por el usuario.
El problema central de la vulnerabilidad es que el parámetro hostname controlable por el atacante no está estrictamente limitado a un nombre de nodo legítimo o un host de confianza, lo que permite que este parámetro se construya como una ruta de acceso interna más compleja. Luego, el servidor inicia una solicitud en nombre del atacante hacia una interfaz interna.
Lo clave en esta etapa no es "poder acceder a una URL externa", sino "hacer que el propio dispositivo CUCM acceda a interfaces de administración internas de WebDialer / Axis que solo son accesibles localmente o por componentes internos". Por lo tanto, el valor de la SSRF proviene de dos aspectos:
En la verificación autorizada, no se debe juzgar el éxito de la SSRF solo por el código de estado HTTP. Las pruebas más fiables incluyen:
En la cadena pública, la SSRF se utiliza además para acceder a interfaces de servicio relacionadas con Axis e intentar escribir contenido de descripción de despliegue de servicio. El atacante, al construir una estructura XML/WSDD especial, hace que el componente del servidor durante el procesamiento escriba contenido controlable en una ruta especificada.
La naturaleza de esta etapa no es una subida de archivos tradicional, sino un abuso de la lógica de procesamiento de los componentes del servidor:
Parámetro controlable por el usuario
↓
Solicitud interna SSRF
↓
Procesamiento del servicio Axis / Web
↓
Escritura de descripción de despliegue controlable o registro
↓
Generación de archivos en ruta especificada
Desde una perspectiva de análisis de seguridad, aquí hay varios puntos clave:
Por lo tanto, el punto crítico de CVE-2026-20230 no es solo la SSRF, sino que la SSRF puede cruzar el límite de confianza, entrar en la cadena de administración/despliegue de servicios internos y finalmente desencadenar la escritura controlada de archivos.
En el diseño del PoC, generalmente se adopta una escritura en dos etapas, en lugar de completar la ejecución de comandos en un solo paso.
La primera etapa se utiliza para crear una capacidad simple de escritura de archivos. El objetivo de esta etapa es permitir que el atacante pueda escribir contenido en una ubicación específica del servidor a través de una ruta accesible por web.
La segunda etapa utiliza la capacidad de escritura de la primera etapa para escribir un script de ejecución de comandos en un directorio accesible por web. Luego, el atacante puede desencadenar la ejecución de comandos del sistema a través de parámetros HTTP.
Las ventajas del diseño de dos etapas son:
Pero desde la perspectiva de la defensa, la escritura en dos etapas también trae superficies de detección más claras:
El flujo del PoC actual se puede resumir como:
En términos de tasa de éxito de explotación, los puntos de fallo más críticos suelen concentrarse en:
Por lo tanto, este PoC tiene una alta explotabilidad en versiones afectadas específicas y cuando las rutas predeterminadas coinciden, pero no es estable para todos los activos CUCM.
El juicio de éxito de CVE-2026-20230 no puede basarse solo en si el script se ejecuta hasta el final. Un juicio más razonable debe dividirse en cuatro niveles.
Condiciones:
WSDL de WebDialer accesible
o página de services accesible
o interfaces relacionadas con cmplatform accesibles
Esto solo indica que el objetivo tiene una superficie de ataque relacionada, pero no prueba que la vulnerabilidad sea explotable.
Condiciones:
Versión objetivo dentro del rango afectado
WebDialer habilitado
Hostname puede ser analizado
La entrada SSRF devuelve una respuesta del servidor anómala pero razonable
En este caso, se debe continuar la verificación combinando registros del servidor o entornos de pruebas autorizados.
Condiciones:
Después de SSRF, aparece un archivo controlado en el servidor
o aparece un archivo anómalo creado por el proceso del servidor en el directorio web
o aparece un servicio nuevo y anómalo en la página de services
o aparece contenido controlable de descripción de despliegue en los registros
En este nivel, se puede confirmar que la cadena de vulnerabilidad ha superado la etapa SSRF simple y ha entrado en el riesgo de escritura arbitraria de archivos.
Condiciones:
El script accesible por web escrito es analizado y ejecutado con éxito
y se puede observar el resultado de la ejecución en el servidor a través de un comando de prueba autorizado
Solo en este nivel se puede juzgar que la ejecución remota de comandos es exitosa. La escritura exitosa de archivos no equivale necesariamente a RCE exitoso, pero en entornos de servicio de alta privilegios como CUCM, la escritura de archivos ya constituye un riesgo grave.
Este artículo no proporciona ejemplos de explotación ejecutables que puedan usarse directamente para atacar.
En entornos autorizados, se recomienda priorizar el uso de métodos de "verificación de solo lectura" o "verificación no destructiva", por ejemplo:
python3 CVE-2026-20230-check.py https://127.0.0.1 --check
Los elementos de verificación recomendados incluyen:
No se recomienda realizar una verificación completa de escritura de archivos o ejecución de comandos en sistemas de producción. Incluso en pruebas autorizadas, se debe priorizar la realización en entornos de pruebas aislados, entornos con instantáneas o siguiendo el proceso de verificación recomendado por el fabricante.
Los límites de seguridad de este tipo de PoC deben estar claramente definidos.
Primero, no se debe ejecutar comandos por defecto. La etapa de ejecución de comandos es una verificación de alto riesgo, que puede causar cambios en el estado del sistema, contaminación de registros, anomalías en el servicio o respuestas de dispositivos de seguridad en cadena.
Segundo, no se debe escribir WebShell por defecto. Incluso si se escribe un archivo de prueba, puede ser juzgado como una intrusión real por EDR, software de eliminación de WebShell, monitoreo de integridad de archivos o sistemas de auditoría de cumplimiento.
Tercero, no se debe sondear masivamente objetivos en Internet pública. Esta vulnerabilidad no requiere autenticación, y los objetivos son en su mayoría infraestructuras de comunicación empresarial. El escaneo y la explotación no autorizados conllevan un riesgo extremadamente alto.
Cuarto, el modo de verificación debe separarse del modo de explotación. Se recomienda dividir el PoC en dos scripts: uno solo para la identificación de activos y el juicio del estado del servicio, y otro solo para verificar la escritura de archivos en entornos de pruebas locales o en entornos explícitamente autorizados.
Quinto, se debe limitar el rango de objetivos. El PoC puede incluir direcciones locales, segmentos de red privados, nombres de dominio en lista blanca, parámetros de confirmación de autorización y otros mecanismos de protección para evitar impactar accidentalmente sistemas de terceros.
Sexto, la etapa RCE debe estar deshabilitada por defecto. Incluso si se conserva el código de investigación, se debe exigir al usuario que pase explícitamente un parámetro de confirmación de autorización antes de permitir la escritura de archivos o la verificación de ejecución de comandos.
Desde la perspectiva de la detección de tráfico, no se puede simplemente coincidir con un nombre de archivo fijo, un nombre de servicio fijo o un nombre JSP fijo. Los nombres de servicio, nombres de archivo y rutas en el PoC público pueden modificarse, y las reglas de cadena única son propensas a falsos negativos.
Un enfoque de detección más razonable consiste en extraer características basadas en las etapas de la cadena de ataque.
Enfocarse en:
/webdialer/Version.jws?wsdl
/webdialer/services
WebDialer WSDL
Axis services listing
Si un cliente externo accede al WSDL y luego a la interfaz de estado de instalación de cmplatform en un corto período de tiempo, se debe aumentar el nivel de riesgo.
Enfocarse en:
/cmplatform/installClusterStatusExecute
action=clusterNodeInstallStatus
Crecimiento anómalo del parámetro hostname
Aparición de separadores de ruta codificados en URL en el parámetro hostname
Parámetro hostname contiene características de rutas internas como webdialer, services, AdminService, platformcom, installstages
Lo clave en esta etapa es que el parámetro hostname ya no parece un nombre de host normal, sino que presenta características de ruta, URL, codificación y XML.
Enfocarse en:
deployment
wsdd
java:RPC
requestFlow
LogHandler
allowedMethods
className
fileName
writeToConsole
Cuando estos campos aparecen simultáneamente, se debe sospechar altamente que el atacante está intentando escribir contenido controlable a través de archivos de descripción de despliegue de servicio Axis.
Enfocarse en:
axis2-web
platform-services
Escritura de archivos JSP
Parámetros que contienen combinaciones de nombre de archivo y contenido de archivo
Path traversal en directorios web
common/log/taos-log-a
tomcat/webapps
Si en el tráfico de ataque aparece una gran cantidad de ../, path traversal codificado en URL, extensión JSP y rutas de WebApp de Tomcat, se debe juzgar como alto riesgo.
Enfocarse en:
Acceso a JSP nuevo
Parámetros de solicitud que contienen pwd, cmd, command, exec, i y otros parámetros de comando
Respuesta que contiene formato de salida de comandos del sistema
La misma IP de origen completa acciones consecutivas de obtención de WSDL, SSRF, escritura y ejecución en un corto período de tiempo
Desde la perspectiva del diseño de reglas, se recomienda adoptar detección por etapas:
Durante la respuesta a incidentes, se recomienda verificar las siguientes ubicaciones y fenómenos:
installClusterStatusExecute./tmp, directorios WebApp, directorios de registro.Si se sospecha que ha sido explotado, se debe priorizar aislar el acceso a la interfaz de administración, conservar los registros y la evidencia del sistema de archivos, y luego proceder con la actualización de parches, limpieza de WebShell, limpieza de servicios anómalos y rotación de cuentas/credenciales.
La corrección fundamental es actualizar a la versión de parche oficial de Cisco o aplicar el paquete de reparación temporal proporcionado por Cisco.
Las recomendaciones generales de manejo son las siguientes:
Lo clave de CVE-2026-20230 no es la exposición de una sola interfaz, sino que entre WebDialer de CUCM, la lógica de consulta de estado de instalación de cmplatform, el procesamiento interno del servicio Axis y la capacidad de escritura de archivos se forma una falla de límite de confianza encadenable.
Esta cadena se puede resumir como:
Solicitud externa no autenticada
↓
Confirmación de superficie de exposición de WebDialer
↓
Obtención del hostname real
↓
SSRF de cmplatform
↓
Acceso al servicio interno de Axis
↓
Escritura controlable de descripción de servicio o registro
↓
Archivo accesible por web
↓
Riesgo de ejecución de comandos y escalada a privilegios de root
La explotabilidad real depende de si WebDialer está habilitado, si la versión objetivo está afectada, si el filtro de hostname puede ser eludido, si el punto de aterrizaje de la ruta coincide, si el contenedor web ejecuta el archivo escrito y si el objetivo ha aplicado el parche.
Desde la perspectiva de la defensa, no se puede confiar solo en "si existe un archivo JSP determinado" para juzgar un ataque. Un enfoque más seguro es realizar una detección correlacionada basada en la cadena multietapa: obtención de información WSDL, hostname anómalo de cmplatform, características Axis/WSDD, escritura con path traversal, acceso a JSP colocado y acceso con parámetros de comando. Siempre que múltiples etapas aparezcan consecutivamente desde la misma fuente en un corto período de tiempo, se debe tratar como un evento de intrusión de alto riesgo.