Analiza 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