El tercer fallo de Ivanti Connect Secure ya tiene parche y fila en KEV

CISA incorporó el viernes 30 de octubre de 2026 a su catálogo KEV los dos CVE que faltaban de la cadena de Ivanti Connect Secure, CVE-2026-111357 y CVE-2026-118527, y dio a las agencias federales hasta el 2 de noviembre para cerrar el primero. Ivanti había revisado su aviso el día anterior con las versiones 25.1.1.3 y 22.8R2.6, las primeras que corrigen la escalada a root que UTA0576 encadenaba desde el 3 de octubre en appliances con todos los parches instalados.

Dos CVE nuevos en el aviso que Ivanti revisó el 29 de octubre

El aviso de Ivanti para CVE-2026-104935 conserva su título y su fecha de creación, el 13 de octubre de 2026, pero su última modificación es del 29 de octubre. Esa revisión añade dos filas a la tabla de vulnerabilidades. CVE-2026-111357 es una falta de autenticación en una función del sistema que permite a un atacante local autenticado escalar privilegios, con CVSS 8,8 y las debilidades CWE-306, CWE-862 y CWE-345. CVE-2026-118527 es un uso de nombres de fichero predecibles que permite a un atacante remoto autenticado subir contenido propio a una ruta conocida del disco, con CVSS 4,3 y CWE-340.

Las dos se corrigen en 25.1.1.3 para quien esté en 25.1.1.2 o anterior y en 22.8R2.6 para quien esté en 22.8R2.5 o anterior. Quien ya hubiera saltado a 25.1.3.0, publicada en julio, o a 25.1.3.1 no tiene que hacer nada por estos dos CVE, porque esas compilaciones ya no contienen los fallos. Cuando publicamos la cadena de tres zero-days de Ivanti Connect Secure el 13 de octubre, la escalada de privilegios no tenía CVE ni parche. Esta noticia cierra ese hilo.

La captura reproduce la tabla del aviso tal como estaba el 1 de noviembre, con las tres puntuaciones y sus vectores. El vector de CVE-2026-104935 sigue en CVSS 3.0 y el de la escalada está en CVSS 3.1, un detalle que importa cuando se comparan con lo que dice NVD, como se ve más abajo.

Volexity, que descubrió la cadena en el appliance de un cliente, anunció el parche en infosec.exchange a las 17:32 UTC del 29 de octubre y pidió aplicarlo sin esperar: «Affected devices should be patched ASAP» (los dispositivos afectados deben parchearse cuanto antes).

El informe de Volexity lleva desde ese día una nota de actualización que remite al aviso de Ivanti para CVE-2026-111357 y aclara que el resto del texto no ha cambiado.

De welcome.cgi a dsinvoked, dónde encaja cada CVE en la cadena de UTA0576

Con los tres identificadores sobre la mesa, la cadena del informe de Volexity se puede leer CVE por CVE. CVE-2026-104935 cubre los dos primeros pasos, la petición sin autenticar a welcome.cgi con una cabecera X-DSCGI-PATH que apunta a un CGI protegido y la ejecución de código a través del manejador de subida wu.cgi. CVE-2026-118527 es la pieza que hacía posible el segundo paso, porque wu.cgi escribía el fichero del atacante en /home/runtime/tmp con un nombre calculado a partir del MD5 del nombre original, y esa ruta predecible es lo que permitía volver a llamarlo antes de que el sistema lo borrase. CVE-2026-111357 es la escalada, el servicio privilegiado dsinvoked que confiaba en los datos de configuración de DSCache y acababa ejecutando un script de Perl como root.

Volexity resumió el hallazgo en X el 13 de octubre con la frase que hoy sigue valiendo para los tres CVE: UTA0576 «chained three vulnerabilities to gain unauthenticated root-level code execution» (encadenó tres vulnerabilidades para conseguir ejecución de código sin autenticar con privilegios de root). El actor no dejó web shell ni malware, volvía a explotar el appliance para cada comando y devolvía los resultados en las respuestas HTTPS.

Las puntuaciones de la escalada no coinciden. Ivanti le da 8,8 con un vector que asume acceso local, baja complejidad y cambio de ámbito. El registro que MITRE publicó para CVE-2026-111357, y que es el que muestra su ficha en NVD desde el 15 de octubre, le da 7,0 con complejidad alta y sin cambio de ámbito, lo clasifica como CWE-829 en lugar de las tres debilidades de Ivanti y solo lista como afectada la 22.8R2.4, la versión del appliance que analizó Volexity. NVD presenta esa métrica como secundaria y no había publicado una propia a 1 de noviembre. Para CVE-2026-118527 no hay registro en NVD ni en CVE.org a esa misma fecha, de modo que la puntuación 4,3 y el vector son los del fabricante y el validador del blog lo marca como pendiente de resolver.

Quién sigue expuesto, de los 5.500 de Shadowserver al aviso de INCIBE-CERT sin actualizar

Shadowserver contaba más de 5.500 appliances Connect Secure accesibles desde internet cuando Ivanti publicó el primer aviso, según el mapa que publicó BleepingComputer el 13 de octubre y que reproducimos abajo. Es el único recuento público que hemos localizado, porque el panel de Shadowserver no ofrece una cifra agregada sin cargar la consulta en el navegador y no hemos encontrado un recuento de Censys o Shodan posterior al parche del 29 de octubre.

El mapa sitúa 1.208 appliances en Estados Unidos, 571 en China y 445 en Japón. En Europa, los marcadores de Alemania, Francia y Reino Unido rondan los 338, 340 y 206, y el marcador situado sobre la península ibérica marca 363. BleepingComputer advierte de que no se sabe cuántos de esos equipos son honeypots ni cuántos están ya parcheados, así que la cifra sirve para medir el tamaño del parque expuesto y no el número de equipos vulnerables.

En España, el aviso INCIBE-2026-737 de INCIBE-CERT, publicado el 14 de octubre con importancia alta, recoge CVE-2026-104935, las versiones corregidas de entonces y la recomendación de ejecutar la Integrity Checker Tool y revisar los indicadores de Volexity. A 1 de noviembre no mencionaba CVE-2026-111357 ni CVE-2026-118527 ni las versiones 25.1.1.3 y 22.8R2.6. El CCN-CERT publicó por su parte la alerta AL 10/26 sobre la explotación activa en Connect Secure, cuyo contenido no hemos podido consultar porque la web del CCN-CERT bloquea el acceso automatizado.

CISA sí ha movido ficha. Su alerta del 13 de octubre lleva una revisión fechada el 30 de octubre que añade los dos CVE, amplía las versiones afectadas a 25.1.1.2 y anteriores, 25.1.2.2 y anteriores y 22.8R2.5 y anteriores, y repite que la Integrity Checker Tool puede no detectar la explotación porque los comandos del atacante se ejecutan en memoria. Quien quiera saber si le han entrado «will need to conduct network and memory forensics» (tendrá que hacer análisis forense de red y de memoria).

La captura de la alerta muestra también los cuatro pasos de recuperación que CISA toma de Ivanti para un appliance con sospecha de compromiso: copia de la configuración, restablecimiento de fábrica y actualización, restauración de la configuración y cambio de todas las contraseñas, certificados, claves de API y credenciales del servidor de licencias. En el catálogo KEV, la entrada de CVE-2026-111357 y la de CVE-2026-104935 llevan la marca de triaje forense obligatorio de la directiva BOD 26-04, y la de CVE-2026-118527 no. Es la segunda VPN SSL en entrar en KEV en una semana, después del reinicio forzado de Cisco ASA y FTD que CISA catalogó el 28 de octubre.

Hay un detalle del aviso de Ivanti que condiciona el calendario. El fabricante recomienda a quien esté en 22.8 pasar a 25.1.1.3 o posterior y recuerda que «22.8 reaches end of life on January 31, 2027» (22.8 llega al final de su vida el 31 de enero de 2027). Para quien no pueda migrar ya, 22.8R2.6 cierra todo lo divulgado. Y quien quiera ir directamente a 25.1.3.0 necesita hardware ISA4500, ISA6500 o ISA8500, o reconstruir el appliance virtual desde la plantilla de esa versión.

Actualizar a 25.1.1.3 o 22.8R2.6 y revisar el appliance antes de dar el parche por bueno

Antes de la lista de tareas, un filtro que sirve de primera pasada sobre los registros de acceso de un proxy o un WAF situado delante del appliance y que reúne los dos indicadores de la cadena en una sola línea.

grep -iE "welcome\.cgi|/home/runtime/tmp/" access.log | grep -i "X-DSCGI-PATH"

Cualquier coincidencia pide revisar el contexto, porque la señal útil es la discrepancia entre la ruta pedida y el valor de la cabecera. Con eso en marcha, el orden de trabajo es este.

1. Comprueba la compilación de cada Connect Secure. Si está en 25.1.1.2 o anterior, instala 25.1.1.3. Si está en 22.8R2.5 o anterior, instala 22.8R2.6 o, mejor, 25.1.1.3. Si está en 25.1.3.0 o 25.1.3.1, ya tiene los tres fallos corregidos. Empieza por los equipos con el portal de usuario abierto a internet.
2. Da por hecho que 22.8R2.5 y 25.1.1.2, las versiones que cerraban la entrada sin credenciales desde el 13 de octubre, no cerraban la escalada a root. Un atacante que hubiera entrado entre el 3 y el 13 de octubre pudo dejar credenciales robadas y no rastro en disco, así que la revisión es la misma con o sin parche.
3. Busca en los logs de los proxies inversos, los WAF y el propio appliance peticiones a /dana-na/auth/url_default/welcome.cgi con la cabecera X-DSCGI-PATH, y ficheros con nombres ics-root-run-inband-*.pl o ics-root-result-inband-* en /home/runtime/tmp, que son los que Volexity asocia a la escalada.
4. No te fíes solo de la Integrity Checker Tool. Para confirmar o descartar la intrusión, CISA y Volexity piden forense de red y de memoria, y la propia Ivanti dice en el aviso que no dispone de indicadores fiables.
5. Si hay indicios, aplica los cuatro pasos de recuperación de Ivanti, trata como comprometidas las cuentas de servicio de LDAP y Active Directory configuradas en el appliance y rota las contraseñas LAPS y las claves de recuperación de BitLocker que ese servicio pudiera leer.
6. Reenvía los logs del appliance a un SIEM externo. UTA0576 editó debuglog y audit.log en los equipos que atacó, así que las copias locales no bastan para reconstruir lo que pasó.
7. Si confirmas un compromiso, el canal es INCIBE-CERT para empresas y particulares y el CCN-CERT para la administración pública. Conserva logs, configuración e imagen del sistema antes de restaurar nada.

Los indicadores que Volexity publicó el 13 de octubre siguen siendo los que hay que buscar, porque Ivanti no ha añadido ninguno en la revisión del aviso. Estos son los que apuntan a la cadena completa, con la escalada incluida.

Volexity mantiene la lista completa en su repositorio de GitHub, con las rutas de los scripts de Python que el actor dejó en /tmp y los ficheros JSON con los resultados de sus consultas a Active Directory.

Lo que Ivanti reconoce dieciséis días después

La respuesta más interesante está en el apartado de preguntas del aviso. Ivanti explica que cuando descubrió la explotación ya tenía un parche para CVE-2026-104935 en pruebas, y que al aparecer la escalada de privilegios «we made the decision to not delay getting a fix to customers» (decidimos no retrasar la entrega de un parche a los clientes) que cerrase la vía principal de entrada. También admite que parte de la escalada la había encontrado su propio programa de seguridad de producto y la había corregido en julio en 25.1.3.0, y que estaba portando esa corrección al resto de versiones soportadas cuando empezaron los ataques. La secuencia completa queda así.

Es una decisión defendible y a la vez la explicación de por qué durante dieciséis días hubo clientes convencidos de estar al día con un appliance que seguía admitiendo la escalada a root. Ya vimos algo parecido con el zero-day de PeopleSoft que eran tres fallos, donde un solo identificador tapaba varias correcciones. En este caso el reparto en tres CVE llega tarde, pero llega con parche, con fila en KEV y con un plazo federal que vence el 2 de noviembre.

Desde el blog, nuestra lectura es que el dato que debería guiar la prioridad, por encima de la puntuación de la escalada, es que UTA0576 usaba el appliance como trampolín hacia las credenciales del dominio. Un Connect Secure guarda cuentas de servicio con permisos de lectura sobre el directorio, y lo que vimos en FortiBleed es que esas credenciales acaban vendidas a afiliados de ransomware. Si el appliance estuvo expuesto en octubre sin 25.1.3.x, el trabajo pendiente sigue después de instalar 22.8R2.6 y acaba cuando alguien ha revisado qué consultó esa cuenta de servicio en Active Directory. Nuestra guía de identidad y control de accesos explica cómo acotar lo que una cuenta así puede leer.

Preguntas de lectores sobre Ivanti Connect Secure

¿Qué es Ivanti Connect Secure?

Es el appliance de VPN SSL que Ivanti heredó de Pulse Secure, y el nombre antiguo todavía aparece en los paneles de Shadowserver. Se despliega en hardware ISA o como máquina virtual y en nube, y da acceso remoto a la red interna, por lo que suele guardar cuentas de servicio de LDAP o Active Directory. Las ramas vivas son 22.7, 22.8 y 25.1, y las dos primeras caducan el 31 de enero de 2027.

¿Cómo consultar los logs de Ivanti Connect Secure para buscar este ataque?

Los registros locales del appliance no son fiables en este caso, porque UTA0576 borró entradas de debuglog y de audit.log. La búsqueda útil se hace en los registros de un proxy, un WAF o un SIEM que reciba el syslog del equipo, filtrando por welcome.cgi y por la cabecera X-DSCGI-PATH. Si solo tienes los logs del appliance, la memoria y el tráfico de red son las fuentes que CISA y Volexity consideran válidas.