Vulnerabilidad zero-day CVE-2026-104935 en Ivanti Connect Secure: versiones afectadas, exploit y detección

Ivanti publicó el 13 de octubre de 2026 la corrección de CVE-2026-104935, una vulnerabilidad de Ivanti Connect Secure que permite a un atacante remoto sin autenticar ejecutar comandos en la pasarela VPN. La empresa reconoce que se explotó como zero-day contra «un número limitado de clientes» antes de la publicación. La CISA la añadió ese mismo día a su catálogo de vulnerabilidades explotadas (KEV) con fecha límite del 16 de octubre para las agencias federales de Estados Unidos.

La investigación de Volexity describe una cadena de tres fallos, y el último, que eleva los privilegios a root, sigue sin corrección. El atacante observado no instaló malware, intentó borrar sus rastros de los registros y robó credenciales del directorio activo. El Integrity Checker Tool (ICT) de Ivanti no detecta esa actividad.

¿Qué es la vulnerabilidad CVE-2026-104935 de Ivanti Connect Secure?

CVE-2026-104935 es una omisión de autenticación por suplantación (CWE-290) en Ivanti Connect Secure que permite a un atacante remoto sin autenticar ejecutar comandos arbitrarios, según el aviso de seguridad de Ivanti. El fabricante le asigna una puntuación CVSS de 8,6 (alta), con el vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L. El aviso afecta solo a Connect Secure y no menciona Policy Secure ni las pasarelas ZTA.

Ivanti explica en el mismo aviso que su programa de seguridad de producto descubrió una parte del fallo y lo corrigió en la versión 25.1.3.0, publicada en julio. Estaba trasladando la corrección al resto de ramas cuando empezó la explotación. Según CyberScoop, la empresa lo había detectado en junio y consideró que no justificaba una versión fuera de ciclo.

¿A qué versiones de Ivanti Connect Secure afecta CVE-2026-104935?

Las versiones afectadas son 25.1.1.1 y anteriores, 25.1.2.2 y anteriores y 22.8R2.4 y anteriores, según el aviso de Ivanti. La rama 22.7, hasta la 22.7R2.14 incluida, no contiene el fallo.

Las ramas 22.7 y 22.8 dejan de tener soporte el 31 de enero de 2027, e Ivanti presenta la 22.8 como un puente temporal hacia la 25.1. Pasar a la 25.1.3.0 exige los nuevos dispositivos ISA4500, ISA6500 o ISA8500, y en las instalaciones virtuales y en la nube obliga a reconstruir la máquina a partir de la plantilla de esa versión. Las pasarelas de la rama 25.1.1 se corrigen con la 25.1.1.2 sin cambiar de plataforma.

¿Cómo funciona la cadena de explotación descrita por Volexity?

La cadena que Volexity publicó el 13 de octubre de 2026 combina una omisión de autenticación en welcome.cgi, una ejecución de código en wu.cgi y una elevación de privilegios a root mediante dsinvoked. Volexity la detectó en el dispositivo de un cliente actualizado a la versión 22.8R2.4, con actividad desde el 3 de octubre, según su análisis técnico.

• El primer fallo es la omisión de autenticación. La petición se dirige a la ruta pública /dana-na/auth/url_default/welcome.cgi con una cabecera X-DSCGI-PATH que apunta a un script protegido. El control de acceso evalúa la URL, pero la cabecera decide qué script se ejecuta.
• El segundo es la ejecución de código. El gestor de subidas wu.cgi escribe en disco un script Perl con extensión .zip antes de comprobar que es un ZIP válido, y el atacante lo ejecuta con peticiones en paralelo antes de que se borre. El código se ejecuta como el usuario cgi-server.
• El tercero es la elevación de privilegios. El atacante modifica en memoria la biblioteca libdsplibs.so y redirige una tarea de mantenimiento almacenada en DSCache para que el proceso dsinvoked ejecute su script como root. Después restaura la entrada de DSCache y la biblioteca.

CVE-2026-104935 cubre los dos primeros pasos. Volexity indica que Ivanti trabaja en la corrección de la elevación de privilegios, que llegará «en una versión futura en las próximas semanas». Ese fallo no tiene CVE asignado públicamente.

¿Quién explota la vulnerabilidad y qué hace dentro de la red?

Volexity atribuye la intrusión inicial a UTA0576, un actor que no había observado antes y que usó la pasarela para robar credenciales del directorio activo sin instalar malware. Estima con confianza baja que su motivación es criminal y no de espionaje, y con confianza media que usa modelos de lenguaje para desarrollar el exploit y para la fase posterior. Volexity no lo ha vinculado con los grupos de origen chino asociados a zero-days anteriores de Ivanti.

UTA0576 repetía la cadena completa para cada comando y recibía la salida por el mismo canal HTTPS. Buscaba las credenciales que pasan por el dispositivo:

• Extrajo las credenciales de dominio que la pasarela usa para consultar el LDAP.
• Lanzó una copia renombrada de tcpdump (/data/.icscap/dsstatmond) para capturar tráfico y recoger credenciales LDAP en claro, credenciales HTTP Basic y respuestas NTLM.
• Consultó el directorio activo en busca de contraseñas de LAPS, información de recuperación de BitLocker y los atributos userPassword y unixUserPassword.
• Desplegó una herramienta Kerberos en Python capaz de hacer Kerberoasting, que usó para probar credenciales, y lanzó un ataque de password spraying (rociado de contraseñas).

El atacante editaba además los registros /home/runtime/dlogs/debuglog y /var/log/audit/audit.log para borrar las entradas de su ventana de actividad, y eliminaba sus scripts al terminar. Volexity no describe ninguna puerta trasera ni otro mecanismo de persistencia, y tampoco confirma que los secretos de LAPS o BitLocker se llegaran a usar.

Desde la publicación del aviso, otros atacantes intentan explotar el fallo. A 15 de octubre, la empresa Previdian registraba 109 intentos desde 51 direcciones IP en sus honeypots, y el 14 de octubre se publicó una plantilla de Nuclei para detectar equipos vulnerables. Shadowserver contaba ese día más de 5.600 instancias de Connect Secure expuestas en internet, sin distinguir cuántas siguen sin parchear, según BleepingComputer.

¿Por qué el Integrity Checker Tool no detecta el compromiso?

El Integrity Checker Tool de Ivanti no detecta esta intrusión porque la cadena modifica la biblioteca solo en memoria y restaura los datos de configuración que altera, según Volexity. La alerta de la CISA del 13 de octubre advierte de que la herramienta puede no detectar la explotación porque los comandos se ejecutan en memoria, y pide análisis forense de red y de memoria.

Un resultado limpio del ICT, por tanto, no descarta el compromiso. El CERT-FR recuerda que Ivanti recomienda la versión externa de la herramienta, que exige acceso físico y puede interrumpir el servicio, y en las instalaciones virtuales pide una instantánea del sistema de archivos y de la memoria antes de actuar sobre la pasarela.

¿Cómo se detecta la explotación de CVE-2026-104935?

Las huellas de la explotación hay que buscarlas sobre todo fuera del dispositivo, porque el atacante borra sus entradas de los registros locales, según Volexity. Sus indicadores de compromiso están en su repositorio de GitHub, con una lista en CSV y reglas YARA. Las señales que se pueden buscar son las siguientes:

• Peticiones a /dana-na/auth/url_default/welcome.cgi con una cabecera X-DSCGI-PATH que no coincide con la ruta solicitada, por ejemplo /home/webserver/htdocs/dana/fb/smb/wu.cgi. Solo se ven si hay un proxy inverso, un WAF o un sensor de red que registre cabeceras.
• Volúmenes anómalos de peticiones a welcome.cgi, típicos de la condición de carrera con la que se ejecuta el script en wu.cgi.
• Conexiones con 108.165.147[.]64, la infraestructura del atacante según Volexity.
• Archivos en /data/.icscap/ y scripts Python en /tmp/ del dispositivo, o un proceso llamado dsstatmond.
• Registros de la pasarela enviados al SIEM que falten o no coincidan con los que conserva el dispositivo, porque el atacante edita las copias locales.

En los controladores de dominio, la cuenta de servicio LDAP de la pasarela no debería consultar atributos de LAPS ni de BitLocker, ni pedir tickets de servicio en masa. Un pico de solicitudes de tickets Kerberos con cifrado RC4 (evento 4769) o de fallos de autenticación (eventos 4625 y 4771) con origen en la pasarela apunta a Kerberoasting o a password spraying. Las cuentas señuelo en el directorio activo ayudan a detectar ese reconocimiento.

Esas señales deben revisarse de forma retrospectiva desde finales de septiembre, por ejemplo con un ejercicio de threat hunting, y vigilarse después con un SOC gestionado que reciba los registros de la pasarela.

¿Debe darse por comprometido un Ivanti Connect Secure sin parchear?

Un Ivanti Connect Secure expuesto sin parche desde finales de septiembre debe actualizarse de inmediato y tratarse como posiblemente comprometido. BleepingComputer informó de que la empresa Defused vio los primeros intentos el 1 de octubre, y el investigador de Volexity Sean Koessel dijo a CyberScoop que no le sorprendería que hubiera actividad a finales de septiembre.

Actualizar no expulsa a un atacante que ya tiene credenciales. Si se sospecha un compromiso, las recomendaciones de la CISA y del CERT-FR incluyen estos pasos:

• Aislamiento de la pasarela respecto de internet y de la red interna, e instantánea de disco y memoria si es virtual, según el CERT-FR.
• Copia de la configuración, restablecimiento de fábrica y actualización, o reconstrucción completa si es una máquina virtual o en la nube, antes de restaurar la configuración, según la CISA. Un análisis forense digital previo preserva las evidencias que el restablecimiento destruye.
• Cambio de los secretos del LDAP y del directorio activo configurados en la pasarela, empezando por la cuenta de servicio, y de las contraseñas de administración y locales. El CERT-FR afirma tener constancia de movimientos laterales con esos secretos, y la CISA pide cambiar las contraseñas de todas las cuentas, incluidas las de dominio.
• Revocación y reemisión de los certificados almacenados en la pasarela, y renovación de las claves de API, las credenciales del servidor de licencias y los tickets Kerberos.

Si los registros del controlador de dominio muestran consultas de la pasarela a atributos de LAPS o de BitLocker, las contraseñas de administrador local y las claves de recuperación afectadas también deben renovarse. El CERT-FR recuerda que algunas amenazas pueden sobrevivir a un restablecimiento de fábrica. Un servicio de respuesta a incidentes con contrato previo evita negociar la contratación en mitad del incidente.

¿Sigue sin parche alguna parte de la cadena?

La elevación de privilegios mediante dsinvoked seguía sin parche a 15 de octubre de 2026, según Volexity. Un atacante que encuentre otra forma de ejecutar código como cgi-server podría reutilizarla, así que la vigilancia de las señales anteriores debe mantenerse hasta que Ivanti publique la corrección.

¿Qué piden el CCN-CERT, el RGPD y NIS2 ante CVE-2026-104935?

El CCN-CERT publicó el 14 de octubre de 2026 la alerta CCN-CERT AL 10/26, con nivel de peligrosidad alto. Recomienda actualizar, revisar los indicadores de Volexity, ejecutar el ICT de forma periódica, aplicar los pasos de recuperación de Ivanti si hay indicios de explotación y revisar el tráfico interno que sale de la pasarela para descartar movimiento lateral.

Si se confirma el compromiso de una pasarela que da acceso a sistemas con datos personales, el robo de credenciales puede obligar a notificar a la Agencia Española de Protección de Datos (AEPD) en 72 horas, según el artículo 33 del RGPD. Las entidades sujetas a NIS2 deberán enviar una alerta temprana en 24 horas si el incidente es significativo, conforme al artículo 23 de la directiva, aunque en España esa obligación depende de la ley de transposición, todavía pendiente.

¿Qué otros zero-days de Ivanti Connect Secure se han explotado?

CVE-2026-104935 es el cuarto caso de explotación de fallos críticos en Connect Secure en menos de tres años. En enero de 2024, CVE-2023-46805 y CVE-2024-21887 llevaron a la CISA a emitir la directiva de emergencia ED 24-01 y, después, a ordenar a las agencias federales la desconexión temporal de estos dispositivos. En enero de 2025 se explotó como zero-day CVE-2025-0282.

En abril de 2025 se explotó CVE-2025-22457 en dispositivos sin actualizar, aunque Ivanti lo había corregido en febrero sin identificarlo como fallo de seguridad. El catálogo KEV de la CISA recoge 36 vulnerabilidades de Ivanti desde 2021.

¿Cómo se reduce la exposición de una pasarela Ivanti a futuros fallos?

La pasarela VPN es un objetivo recurrente porque está expuesta a internet, guarda credenciales del dominio y no admite un agente de EDR. Lo explicamos al analizar los puntos ciegos del EDR en dispositivos de red. En el caso de NetScaler, las web shells instaladas antes del parche seguían activas después de aplicarlo.

La cuenta de servicio que la pasarela usa contra el directorio debería tener los permisos mínimos y no poder leer atributos de LAPS ni de BitLocker, conforme al modelo de niveles de Active Directory. Así, el robo de esa cuenta no da acceso a las contraseñas de administrador local ni a las claves de recuperación.

La directiva BOD 26-04 de la CISA fija tres días para corregir las vulnerabilidades del KEV que dan control total del sistema y exige triaje forense, como analizamos en un artículo anterior. Ese plazo sirve de referencia también fuera de la administración estadounidense.

Fuentes y atribución: este análisis se basa en el aviso de seguridad de Ivanti, la investigación de Volexity, las alertas de la CISA, el CCN-CERT y el CERT-FR, y la cobertura de CyberScoop y BleepingComputer. La información está actualizada a 15 de octubre de 2026.

UTA0576 es el nombre que Volexity da a este grupo de actividad, y su valoración de que la motivación es criminal tiene confianza baja y puede cambiar. Este artículo no atribuye fallos a productos distintos de los que cita el aviso de Ivanti.

Aviso técnico: las comprobaciones descritas son orientativas. Los restablecimientos y reconstrucciones de la pasarela deben planificarse con el responsable de red y, si hay sospecha de compromiso, después de preservar las evidencias. Los indicadores publicados pueden ampliarse, y deben consultarse las versiones vigentes en las fuentes originales.