Ivanti Connect Secure CVE-2026-111357: la 25.1.1.2 y la 22.8R2.5 quedan afectadas

Las versiones 25.1.1.2 y 22.8R2.5 de Ivanti Connect Secure ya figuran como afectadas. El 30 de octubre el catálogo de vulnerabilidades explotadas de CISA sumó CVE-2026-111357, con plazo al 2 de noviembre, y CVE-2026-118527, con plazo al 13 de noviembre. Según la descripción del propio catálogo, las dos se encadenan con CVE-2026-104935, la que entró el 13 de octubre.

La alerta de CISA sobre Ivanti, revisada el 30, da como afectadas las versiones "25.1.1.2 and prior, 25.1.2.2 and prior, and 22.8R2.5 and prior". El aviso AV26-1035 del Centro Canadiense de Ciberseguridad, revisado el mismo día, pone el límite en las anteriores a 25.1.1.3, 25.1.3.1 y 22.8R2.6. Las dos agencias publican una sola lista para las tres fallas, sin separarlas por CVE.

La nota del 14 de octubre recomendaba la 25.1.3.0 o posterior y daba la 22.8R2.5 como no afectada, porque así figuraban en el registro de Ivanti para CVE-2026-104935. Las dos cosas cambiaron: la 22.8R2.5 está en las dos listas nuevas y la 25.1.3.0 está en la canadiense. Esa nota tampoco mencionó que CVE-2026-104935 ya llevaba la marca de triage forense del catálogo: además del parche, CISA pedía revisar si el equipo había sido comprometido.

El Integrity Checker Tool de Ivanti no alcanza para esa revisión. CISA advierte que "may not detect evidence of exploitation of CVE-2026-104935", y Volexity, la empresa que descubrió la cadena, informa que en el equipo que investigó la herramienta no detectó ningún cambio.

¿Qué versión de Ivanti Connect Secure corrige CVE-2026-111357?

Ivanti publicó el parche de CVE-2026-111357 el 29 de octubre, según la actualización que Volexity agregó a su informe. El aviso de Ivanti no se pudo leer: hub.ivanti.com sirve una página que se arma con JavaScript y no cargó. Las versiones salen de cuatro fuentes que coinciden en las ramas 25.1.1 y 22.8, y difieren en la 25.1.3.0:

En la línea 25.x, la 25.1.3.1 es la única versión que ninguna fuente legible da como afectada. En la 22.8, la versión objetivo es la 22.8R2.6. La 25.1.1.3 es el límite que dan NVD para CVE-2026-111357 y el centro canadiense para el conjunto, pero el registro de Ivanti para CVE-2026-104935 dice "before version 25.1.3.0", y leído al pie de la letra la deja afectada. Tampoco se pudo confirmar si la 25.1.3.1 que hoy figura como límite es la misma del 13 de octubre o una republicación con el parche del 29.

CISA agrega en la misma alerta que la rama 22.8 llega al fin de soporte el 31 de enero de 2027.

El equipo que investigó Volexity estaba en la 22.8R2.4, compilación 19097, la última versión disponible en ese momento. Fue un día cero: no había parche que aplicar.

CVE-2026-118527 está en el catálogo de CISA y no tiene registro CVE publicado

CVE-2026-118527 figura como explotada y con plazo al 13 de noviembre, pero no tiene registro publicado ni en el programa CVE ni en NVD. La API de NVD devuelve 0 resultados, la del programa CVE responde CVE_RECORD_DNE (el registro no existe), y la ficha de NVD que enlaza el propio catálogo está vacía. Las consultas son del 31 de octubre a las 11 UTC.

Lo que hay es la descripción del catálogo: una falla de generación de números o identificadores predecibles (CWE-340) que permite a un atacante remoto autenticado subir archivos con contenido propio a una ubicación conocida del disco, y que "can be chained with CVE-2026-104935 and CVE-2026-111357". No tiene puntaje CVSS. Sus versiones son las de la lista conjunta de CISA y del centro canadiense.

Volexity describe tres eslabones, un bypass de autenticación, una escritura de archivos y una escalada a root, y atribuye los dos primeros a CVE-2026-104935. CVE-2026-118527 no aparece en su informe. Sin el aviso de Ivanti no se puede confirmar qué tramo de la cadena es.

Ninguna de las tres fallas tiene un puntaje calculado por NVD. CVE-2026-104935 tiene 8,6, de Ivanti como autoridad de numeración. CVE-2026-111357 tiene 7,0, firmado por MITRE, que asignó el registro, con vector AV:L/AC:H/PR:L: local, de complejidad alta y con privilegios bajos. Es la de puntaje más bajo y una de las dos con plazo de 3 días, porque en la cadena es el paso que da root. El mismo desfasaje tenía el 2,7 de VMware ESX que entró al catálogo, y NVD no lo compensa: desde abril no suma su propio puntaje cuando la autoridad de numeración ya puso uno, aunque esa autoridad sea MITRE y no el fabricante.

Por qué CISA dio 3 días con triage a CVE-2026-111357 y 14 a CVE-2026-118527

La respuesta está en la Tabla 1 de la directiva BOD 26-04, emitida el 10 de junio de 2026 para las agencias civiles del Poder Ejecutivo federal de Estados Unidos. El plazo sale de cuatro preguntas: si el equipo está expuesto a internet, si la falla está en el catálogo, si el atacante puede automatizar la explotación y si obtiene control total o parcial. Algunas combinaciones llevan además "& forensic triage": remediar o mitigar en tres días y "carry out a forensic triage of the asset to assess whether the system is compromised".

Para una falla del catálogo, el triage corresponde cuando el atacante obtiene control total y además el equipo está expuesto o la explotación se puede automatizar. CISA puntuó CVE-2026-111357 con impacto técnico total y explotación no automatizable: en un equipo expuesto a internet, como un appliance de VPN, es la fila 3 de la tabla, 3 días con triage. CVE-2026-104935, con impacto total y automatizable, es la fila 1. CVE-2026-118527 no tiene puntuación publicada porque no tiene registro; sus 14 días encajan con un impacto parcial, pero no se puede confirmar.

El catálogo marca esa combinación en el campo forensicTriage del feed JSON y del CSV. El texto de la acción requerida no sirve para distinguirla: es idéntico palabra por palabra en las dos entradas de Ivanti, y las dos remiten a los "Forensics Triage Requirements" de CISA, que están en la guía de implementación de la directiva.

La tabla explica casi todo el catálogo. Desde el 25 de junio, cuando el campo tomó por primera vez el valor Yes, entraron 139 fallas, todas con 3 o con 14 días: 96 con triage, 14 con 3 días sin triage y 29 con 14 días. Contrastadas con la puntuación SSVC que CISA publica en las fichas de NVD, la tabla explica 58 de 62 entradas revisadas: todas las que no llevan triage y tienen puntuación, más una muestra de 20 de las 96 con triage. Los 3 días sin triage corresponden a explotación automatizable con impacto parcial. Los 14 días con impacto total aparecen en productos que no suelen estar expuestos a internet, como un navegador, que es la fila 11. Las 4 excepciones son fallas con impacto total y 3 días que no llevan la marca, entre ellas una de ISC BIND y una de SimpleHelp. El plazo solo no alcanza para saber si CISA pide triage; el campo sí.

El plazo de 3 días ya se leía como señal de explotación en curso en cinco de las siete altas del 2 de septiembre, y las cinco llevaban la marca. Para las agencias, el plazo se aplica a cada equipo: según la tabla, CVE-2026-111357 en un equipo que no está expuesto a internet pasa a 14 días sin triage. Para cualquier otra organización la directiva no es obligatoria, pero el criterio sirve igual: una entrada con forensicTriage en Yes es una en la que CISA, además del parche, pide revisar si el equipo ya cayó.

Por qué el Integrity Checker Tool de Ivanti puede no ver la cadena de CVE-2026-104935 y CVE-2026-111357

El Integrity Checker busca cambios inesperados en los archivos del disco. Según Volexity, que sigue al actor como UTA0576, la cadena modificaba una biblioteca del sistema solo en memoria y restauraba los datos de configuración que había tocado. En los archivos del producto no quedaba diferencia que marcar: "the tool does not detect any modifications". En sus recomendaciones, Volexity lo dice con más cautela: la herramienta "may not be able to identify device compromise".

Volexity no encontró web shell ni puerta trasera: cada comando volvía a correr la cadena completa, y el atacante borraba sus entradas recientes de dos registros, /home/runtime/dlogs/debuglog y /var/log/audit/audit.log. Lo que sí quedó en el equipo fueron sus herramientas: archivos en /tmp/ y un tcpdump renombrado como dsstatmond, que corría desde el directorio oculto /data/.icscap/ y grababa tráfico en texto plano (LDAP, HTTP, FTP y telnet) para sacar credenciales y hashes NTLM.

Con eso, el atacante fue más allá del appliance. Extrajo las credenciales de dominio que el equipo usa para LDAP y, con una cuenta de servicio de Active Directory, buscó contraseñas de LAPS, claves de recuperación de BitLocker y atributos con contraseñas. También probó credenciales con una herramienta propia de Kerberos e hizo password spraying. Volexity atribuye la operación, con confianza baja, a un actor de motivación criminal y no de espionaje.

Para CISA, quien quiera saber si fue comprometido "will need to conduct network and memory forensics to identify evidence of exploitation".

¿A quién afecta CVE-2026-111357 en Ivanti Connect Secure?

A quien tenga Ivanti Connect Secure en la 25.1.1.2 o anterior, en la rama 25.1.2, o en la 22.8R2.5 o anterior. Y a quien lo haya tenido expuesto a internet en una versión afectada por CVE-2026-104935 desde, al menos, el 3 de octubre, aunque hoy esté en una versión corregida. Es la fecha en que empieza la explotación que documentó Volexity en el equipo que investigó; el servidor de la operación ya corría desde el 30 de septiembre, así que la ventana puede empezar antes.

¿Quién puede ignorar el aviso de CISA sobre Ivanti Connect Secure del 30 de octubre?

Quien no tenga Ivanti Connect Secure. Ni CISA ni el centro canadiense nombran a Ivanti Policy Secure, y en el material legible de Ivanti tampoco aparece. Eso no confirma que no esté afectado, porque el aviso del fabricante no se pudo leer.

La 22.7R2.14 es el caso dudoso. Ivanti la lista como no afectada por CVE-2026-104935 y NVD no la incluye para CVE-2026-111357. Las dos agencias no nombran la rama 22.7, aunque su redacción ("and prior", "prior to") tampoco la excluye expresamente.

¿Cómo reviso si mi Ivanti Connect Secure fue comprometido con CVE-2026-104935 y CVE-2026-111357?

1. Mirá la versión en la consola de administración y compará contra la tabla.
2. No tomes como prueba un Integrity Checker limpio. La cadena trabajaba en memoria: un resultado sin hallazgos no descarta el compromiso.
3. Revisá Active Directory desde los controladores de dominio. Buscá actividad de la cuenta de servicio que el appliance usa para LDAP y de su dirección IP: consultas masivas, lectura de contraseñas de LAPS o de claves de BitLocker, pruebas de credenciales. Volexity pide investigar forensemente los equipos con señales de compromiso, como intentos de movimiento lateral que salgan del appliance. Esa conducta la registran la auditoría de Active Directory y un EDR en esos servidores, no el appliance.
4. Buscá en los registros de red conexiones con 108.165.147[.]64, el servidor de la operación, que Volexity vio corriendo un servidor OpenVPN entre el 30 de septiembre y el 7 de octubre. El resto de los indicadores está en el GitHub de Volexity.
5. Para el appliance hace falta una imagen. Lo que Volexity documentó adentro del equipo, el directorio oculto /data/.icscap/, el proceso dsstatmond, archivos en /tmp/ y en /home/runtime/tmp/ y huecos recientes en los dos registros, se busca en una imagen de memoria y de disco. Volexity la obtuvo trabajando con Ivanti.

¿Qué hago si tengo Ivanti Connect Secure en 25.1.1.2, 25.1.3.0 o 22.8R2.5?

La guía de implementación de BOD 26-04 propone estos tiempos para una entrada con triage forense, y es explícita sobre el orden: "Do not alter or remediate systems prior to evidence/artifact collection when possible", porque "patching may jeopardize the availability of artifacts".

1. Si el equipo está expuesto y no se reinició desde que pudo ser atacado, capturá antes de tocar. La memoria no sobrevive a un reinicio, y el restablecimiento de fábrica de la recuperación borra el disco.
2. Si ya actualizaste en octubre y el equipo se reinició, la memoria de ese período ya no está. La revisión pasa por la red y por Active Directory, los puntos 3 y 4 de la lista anterior.
3. Actualizá a la 25.1.3.1 o a la 22.8R2.6, según la rama. Desde la rama 25.1.1, la 25.1.1.3 es el límite que dan NVD y el centro canadiense, pero el registro de Ivanti para CVE-2026-104935 no la confirma.
4. Si hay indicios de compromiso, aplicá la recuperación que recomienda CISA, tomada de los procedimientos de Ivanti: respaldar la configuración; restablecer de fábrica y actualizar, o reconstruir la instancia si es virtual o en la nube; restaurar la configuración; cambiar las contraseñas de todas las cuentas, "including domain, administrator, and local accounts"; revocar y volver a emitir los certificados guardados, y cambiar las claves de API y las credenciales del servidor de licencias. Es la lógica de reconstruir en vez de parchear que ya se aplicó a NetScaler.
5. Con indicios de compromiso, rotá también lo que el atacante pudo leer o capturar: las contraseñas de LAPS y las claves de recuperación de BitLocker a las que llegaba la cuenta de servicio, y las credenciales que pasaron por el appliance en texto plano. Volexity documenta que el atacante buscó las primeras y capturó las segundas. Ni CISA ni Volexity piden rotarlas por nombre.
6. Planificá la salida de la rama 22.8 antes del fin de soporte. Para pasar a 25.x, CISA remite a la guía de compatibilidad y migración de Ivanti.

No es el primer caso de octubre en que el parche aplicado a tiempo no fue el último: pasó con el tercer nivel de parche de Arista VeloCloud. Y si la pregunta de fondo es si hace falta un appliance de VPN expuesto a internet, las alternativas están en acceso remoto seguro sin VPN.

El aviso de Ivanti no se pudo leer. Fuentes leídas: el registro oficial del programa CVE firmado por Ivanti para CVE-2026-104935 y el firmado por MITRE para CVE-2026-111357; las fichas y configuraciones de versiones de NVD; la alerta de CISA revisada el 30 de octubre; el aviso AV26-1035 del centro canadiense; el informe de Volexity del 13 de octubre con su actualización del 29; la entrada del blog de Ivanti del 13 de octubre; la directiva BOD 26-04 con su Tabla 1 y su guía de implementación; y el feed del catálogo de CISA, versión 2026.10.30, sobre el que están hechas las mediciones. La nota no detalla cómo se dispara cada falla; la forma de detectar el bypass en los pedidos web está en el informe de Volexity.

Preguntas frecuentes sobre CVE-2026-111357 y CVE-2026-118527 en Ivanti Connect Secure

¿Alcanza con la versión de Ivanti Connect Secure que corrigió CVE-2026-104935?

Depende de cuál. La 25.1.3.1 no figura como afectada en ninguna fuente legible. La 25.1.1.2 y la 22.8R2.5 sí, en la alerta de CISA y en el aviso canadiense, y la 25.1.3.0 en el canadiense. En la rama 22.8, la versión objetivo es la 22.8R2.6.

¿Por qué CVE-2026-118527 no aparece en NVD?

Porque no tiene registro CVE publicado. Al 31 de octubre a las 11 UTC, la API de NVD daba 0 resultados y la del programa CVE respondía que el registro no existe. Lo publicado es la descripción del catálogo de CISA y la lista conjunta de versiones de CISA y del centro canadiense. Desde afuera no se puede saber quién asignó el identificador.

¿El Integrity Checker Tool de Ivanti detecta la cadena de CVE-2026-104935 y CVE-2026-111357?

CISA advierte que puede no detectar la explotación de CVE-2026-104935, porque los comandos corren en memoria. En el equipo que investigó Volexity, la herramienta no detectó ningún cambio. Un resultado limpio no descarta el compromiso.

¿Qué pide CISA con el triage forense de CVE-2026-111357 en Ivanti Connect Secure?

Que, además de remediar o mitigar en 3 días, se revise si el equipo ya fue comprometido. Para las agencias civiles federales de Estados Unidos lo exige la directiva BOD 26-04 en los equipos expuestos a internet, y la guía pide juntar la evidencia antes de parchear cuando sea posible.

¿La versión 22.7R2.14 de Ivanti Connect Secure está afectada por CVE-2026-111357?

NVD no la incluye, e Ivanti la lista como no afectada por CVE-2026-104935. Las agencias no la nombran, aunque su redacción no la excluye. Sin el aviso de Ivanti no se puede dar por confirmado.