Ivanti cierra la cadena de Connect Secure: parche para la falla que daba root y CISA da hasta el 2 de noviembre

Ivanti terminó de cerrar la cadena de fallas que se explotaba en Ivanti Connect Secure desde principios de octubre. El 29 de octubre de 2026 actualizó su aviso de seguridad con dos identificadores nuevos, CVE-2026-111357 y CVE-2026-118527, y con versiones que corrigen las tres fallas encadenadas. Este viernes 30 de octubre, la agencia de ciberseguridad de Estados Unidos (CISA) agregó ambas a su catálogo de vulnerabilidades explotadas (KEV) y dio a las agencias federales hasta el lunes 2 de noviembre para atender la más grave.

Es la pieza que faltaba de el día cero de Ivanti Connect Secure que contamos el 20 de octubre: el escalamiento a root (control total del equipo) ya tiene parche. Y Volexity, la firma que descubrió el ataque, detalló qué hizo el atacante una vez dentro.

Las tres fallas de la cadena

Fuentes: catálogo KEV de CISA (versión 2026.10.30), registro de NVD de CVE-2026-111357 (modificado el 30 de octubre de 2026), GBHackers y Cybersecurity News (30 de octubre de 2026).

La calificación de CVE-2026-111357 no coincide entre fuentes: el registro en NVD, aportado por MITRE, le da 7.0 porque exige acceso local previo, mientras que los reportes que citan a Ivanti hablan de 8.8. En la práctica da igual: encadenada con las otras dos, un atacante sin usuario ni contraseña termina como root. CISA marcó además CVE-2026-111357 con requisito de triage forense, algo que no pidió para la de 4.3.

Según NVD, la falla de root está en la forma en que el servicio interno dsinvoked confía en datos de configuración guardados en caché, y el mismo registro indica que se explotó en octubre de 2026.

Qué versión instalar

Ivanti dice, en la frase que recoge SecurityOnline el 30 de octubre: «A fix is available now for all vulnerabilities which were chained and exploited in the wild» (ya hay parche para todas las fallas encadenadas y explotadas).

• Rama 25.1.1: actualizar a 25.1.1.3.
• Rama 22.8: actualizar a 22.8R2.6.
• Rama 25.1.3: las notas publicadas no coinciden sobre si 25.1.3.1 ya cubre las dos fallas nuevas. Confírmalo en el aviso de Ivanti antes de dar el tema por cerrado.
• Rama 22.7 y anteriores: SecurityOnline indica que no están afectadas. Revisa de todos modos si tu versión sigue con soporte.

Ojo con un detalle del reporte de Volexity: el equipo comprometido que analizó estaba en 22.8R2.4 (build 19097), la versión más reciente de su rama en ese momento. Estar al día no bastó. Lo que importa ahora es instalar las versiones del 29 de octubre.

Lo que hizo el atacante después de entrar

Esta es la parte que más le importa a una PyME. Volexity, que sigue al grupo como UTA0576 y rastreó la actividad hasta el 3 de octubre de 2026, actualizó su análisis tras el parche del 29 de octubre. Según ese reporte:

• Usó la cuenta de servicio de Active Directory del propio equipo VPN para consultar al controlador de dominio. Buscaba contraseñas de administrador local guardadas con LAPS, claves de recuperación de BitLocker y atributos de usuario que contienen contraseñas.
• Probó credenciales en la red interna con password spraying y Kerberoasting, y extrajo material de autenticación (LDAP, HTTP Basic, NTLM) de capturas de tráfico.
• No dejó web shell ni puerta trasera persistente. Volvía a explotar el equipo para cada paso y movía comandos y resultados por HTTPS.
• Borró sus huellas: eliminó entradas recientes de los registros de depuración y de auditoría del equipo, y revirtió en memoria los cambios que había hecho.

Volexity concluye que el robo de credenciales preparaba un compromiso más amplio de la red, pero no pudo determinar el objetivo final porque la operación se interrumpió.

Traducido: si tu VPN Ivanti estuvo expuesta en octubre, el riesgo no se queda en el equipo. Su cuenta de Active Directory fue la llave para ir por las contraseñas de las computadoras y las claves de los discos cifrados.

Qué hacer antes del lunes

1. Confirma si tienes Ivanti Connect Secure (o un Pulse Secure viejo) y en qué versión exacta está. Si lo administra un proveedor, pídela por escrito hoy.
2. Actualiza a 25.1.1.3 o 22.8R2.6 según tu rama, o a la versión que el aviso de Ivanti indique para tu hardware. Trátalo como cambio de emergencia; no esperes la ventana de mantenimiento del mes.
3. Cambia la contraseña de la cuenta de servicio de Active Directory que usa la VPN y revisa qué permisos tiene. Si puede leer LAPS o BitLocker, quítale ese acceso; para validar usuarios no lo necesita.
4. Rota las contraseñas de LAPS y, si hay sospecha, las claves de recuperación de BitLocker de los equipos críticos.
5. Busca rastros fuera del equipo. Volexity sugiere vigilar muchas peticiones a /dana-na/auth/url_default/welcome.cgi con un encabezado X-DSCGI-PATH que no coincide con la ruta, y archivos extraños en /tmp/. Como los registros del equipo pudieron alterarse, revisa también los del firewall, del controlador de dominio y de tu SIEM desde el 1 de octubre.
6. No te fíes del Integrity Checker Tool. Córrelo, pero un resultado limpio no descarta nada: los cambios del atacante vivían en memoria.
7. Si encuentras algo, conserva evidencia (imágenes de memoria y de disco) antes de restablecer el equipo. Volexity dice que eso fue clave para reconstruir la intrusión.
8. Cierra la exposición mientras parchas: limita el portal a IP conocidas y exige MFA a todos. Si tu MFA todavía depende de SMS, revisa lo que cambió en Entra ID con los métodos por SMS y voz.

Un octubre pesado para el acceso remoto

Este mes también cayeron la VPN de Cisco ASA y FTD, GlobalProtect y SonicWall SMA1000. El equipo de acceso remoto está en internet, tiene credenciales del dominio y casi nadie lo revisa: es la primera puerta que buscan quienes luego cifran todo, y el tercer trimestre de 2026 cerró con récord de ransomware.

Si ya es el cuarto susto con la misma VPN, evalúa un esquema por aplicación (VPN tradicional vs. ZTNA) y confirma tus respaldos contra ransomware.

En ciberseguridad y redes hacemos la revisión de versión, el parche, la búsqueda de rastros y la rotación de credenciales del dominio.