Ivanti: el zero day de su VPN que dio acceso root a un equipo parcheado

El caso del Ivanti zero day en el VPN con acceso root se centra en el fallo que la empresa reconoció en su VPN Connect Secure. Según SecurityWeek, ese fallo formó parte de una cadena con la que un atacante obtuvo acceso root en un equipo que tenía todos los parches instalados [3]. El caso deja una conclusión incómoda: estar al día no equivalía a estar seguro.

Para una pyme industrial que abre su red de planta a proveedores y técnicos de mantenimiento a través de un VPN, la lección va más allá de actualizar. Conviene revisar la segmentación de la red industrial y vigilar lo que ocurre fuera del propio equipo VPN.

CVE-2026-104935 es una omisión de autenticación explotada antes de hacerse pública

Según Rapid7, Ivanti publicó su aviso de seguridad el 13 de octubre de 2026 para CVE-2026-104935. Es un fallo clasificado como CWE-290: la autenticación se puede eludir mediante suplantación [2]. En la práctica, eso permite a un atacante remoto, sin credenciales válidas, ejecutar comandos arbitrarios en el equipo [2].

La CISA (Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos) detalla que el fallo afecta a las versiones 25.1.1.1 y anteriores, 25.1.2.2 y anteriores, y 22.8R2.4 y anteriores de Ivanti Connect Secure [1]. Su puntuación CVSS es de 8,6 [2][4]. Rapid7 añade que, según el aviso del fabricante, las versiones 22.7.x y anteriores no están afectadas. También indica que las versiones corregidas son 25.1.1.2, 25.1.3.0, 25.1.3.1 y 22.8R2.5 [2].

Lo que convierte este fallo en un zero day es la cronología. Ivanti informa de que la explotación ya se había producido antes de la divulgación y afectó a un número limitado de clientes [2]. Es decir, los atacantes lo usaban cuando todavía no existía un aviso público ni un parche para todas las versiones soportadas.

Rapid7 explica además que Ivanti había detectado parte del problema con su propio programa de seguridad. Lo había corregido en la versión 25.1.3.0 de julio de 2026, pero la explotación ocurrió mientras trasladaba la corrección al resto de versiones [2]. La CISA incorporó la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas (KEV) el mismo 13 de octubre [1][5].

Hasta aquí, la historia parece la de tantos otros avisos: un fallo grave, un parche disponible y la recomendación de aplicarlo cuanto antes. El matiz llega con la investigación del incidente que destapó la explotación.

Una cadena de tres zero days dio acceso root a un equipo con todos los parches

Según SecurityWeek, que recoge el trabajo de la firma de análisis forense Volexity, la explotación salió a la luz mientras Volexity investigaba un incidente en uno de sus clientes [3]. Allí encontró que un actor de amenazas no documentado hasta entonces, al que denomina UTA0576, había encadenado tres zero days. Con ellos consiguió ejecución de código como root, sin autenticarse, en un Ivanti Connect Secure completamente parcheado [3]. Volexity sitúa las primeras evidencias de explotación el 3 de octubre de 2026 [3].

De acuerdo con Volexity, CVE-2026-104935 engloba dos de esos fallos: la omisión de autenticación y un error de ejecución remota de código [3]. El tercero, una escalada de privilegios, seguía sin parche cuando se publicó la información, y el fabricante prevé corregirlo en las próximas semanas, según el mismo medio [3]. Rapid7 confirma también que esa escalada de privilegios no estaba corregida y que Ivanti la parcheará más adelante [2].

Aquí está la clave. SecurityWeek describe un equipo completamente parcheado que fue comprometido mediante una cadena de tres zero days [3]. En el incidente investigado, los atacantes robaron credenciales y manipularon registros del equipo VPN [3][4].

Volexity detalla lo que hicieron después. Según SecurityWeek, los atacantes robaron credenciales de dominio almacenadas en el equipo y extrajeron metadatos limitados del directorio activo. También buscaron contraseñas de LAPS y claves de recuperación de BitLocker, lanzaron ataques de password spraying y analizaron los registros de autenticación para identificar usuarios válidos [3]. Volexity no encontró ninguna puerta trasera ni web shell en el equipo. Aun así, considera con alta confianza que todo apuntaba a preparar un movimiento lateral y un compromiso más amplio de la red [3].

Parchear cierra la puerta, pero no prueba que nadie entrara antes

La CISA insta a las organizaciones afectadas a actualizar de inmediato a la última versión, tal como indica el aviso de Ivanti. Recuerda además que la versión 22.8 llega al final de su vida útil el 31 de enero de 2027 [1]. Es el primer paso y no admite demora.

Pero el mismo organismo describe que los atacantes explotan el fallo para robar credenciales y exfiltrar datos [1], y la explotación empezó antes del aviso. Hay actualizaciones para corregir CVE-2026-104935, y Rapid7 recomienda buscar señales de compromiso incluso después de aplicarlas [2].

La consecuencia práctica es asumir que las credenciales que pasaron por el VPN o estaban guardadas en él pueden estar expuestas. Si se sospecha un compromiso, la CISA recomienda seguir los procedimientos de recuperación de Ivanti [1]:

• Copia de la configuración.
• Restablecimiento de fábrica y actualización, o reconstrucción de la instancia en entornos virtuales y en la nube.
• Restauración de la configuración.
• Cambio de contraseñas de todas las cuentas, incluidas las de dominio, administración y locales.
• Revocación y reemisión de certificados y renovación de claves de API.

Tampoco conviene pensar que el riesgo se limita a ataques dirigidos. Según The Hacker News (thehackernews.com), los sensores señuelo (honeypots) de Previdian registraron 105 intentos de explotación procedentes de 50 direcciones IP únicas hasta el 14 de octubre de 2026 [4]. No es una cifra global ni mide compromisos confirmados. Sí documenta intentos activos de explotación contra los sensores de Previdian. Para ampliar las recomendaciones, puedes consultar la guía sobre cómo proteger una fábrica conectada frente a ciberataques.

Qué revisar si el VPN da acceso a la red industrial

El siguiente apartado es criterio editorial de Hodeitek, no procede de las fuentes citadas. Plantea recomendaciones para un escenario industrial habitual: empleados, integradores o fabricantes de maquinaria que utilizan el mismo VPN para acceder a sistemas de oficina y de planta.

Qué revisar en el acceso remoto

Antes de pensar en arquitectura, conviene tener claro el punto de partida:

• Qué versión de Ivanti Connect Secure (o del VPN que uses) está en producción y si está entre las afectadas.
• Quién accede (empleados, proveedores, cuentas de servicio) y desde cuándo no se revisan esos accesos.
• Qué credenciales se almacenan en el propio equipo VPN y qué otras cuentas comparten esa contraseña.
• Si el segundo factor de autenticación depende del propio VPN o es independiente de él.

Segmentar para que un VPN comprometido no llegue al proceso

Si el VPN cae, lo decisivo es hasta dónde puede llegar el atacante. Como medida de diseño, conviene separar la zona de acceso remoto de la red OT mediante cortafuegos y reglas explícitas, en lugar de dar acceso plano a toda la planta.

Las cuentas de proveedor deberían tener los privilegios mínimos imprescindibles y fecha de caducidad. Las credenciales con acceso a planta conviene rotarlas tras un incidente como este. Por último, conviene plantear pruebas de intrusión y ejercicios de red team que partan de un VPN comprometido para evaluar las barreras de segmentación y buscar posibles vías no documentadas. Estas medidas generales de arquitectura no sustituyen las recomendaciones del fabricante.

Qué revisar para buscar señales de compromiso

Este caso tiene un rasgo que complica la detección. La CISA advierte de que la herramienta de comprobación de integridad de Ivanti puede no detectar la explotación, porque los comandos del atacante se ejecutan en memoria. Señala también que determinar si hubo compromiso requiere análisis forense de red y de memoria [1]. Según The Hacker News, Volexity describe que UTA0576 manipuló los registros para borrar sus huellas [4].

Si el equipo comprometido es el que genera los registros, no puede ser la única fuente de verdad. La vigilancia útil está fuera: los registros de autenticación del directorio activo, el tráfico saliente anómalo desde el VPN y las cuentas de acceso remoto que se conectan a segmentos donde nunca habían estado o a horas poco habituales. Como el objetivo descrito es el robo de credenciales y la exfiltración [1], la detección debe centrarse en esos comportamientos.

Rapid7 recomienda buscar señales de compromiso incluso después de aplicar el parche. Señala que Ivanti no disponía de indicadores fiables en el momento del aviso, aunque Volexity sí ha publicado algunos [2]. The Hacker News añade como pista revisar las peticiones entrantes que incluyan la cabecera «X-DSCGI-PATH» [4]. Para los indicadores concretos, la referencia es el aviso de Ivanti y la alerta de la CISA.

Una pyme industrial sin un equipo propio que revise esos registros a diario puede valorar apoyo externo. En ese caso, conviene estudiar servicios de monitorización y respuesta gestionadas (SOCaaS/MDR) y comprobar qué vigilancia externa incluyen.

Diseñar el acceso remoto asumiendo que el VPN puede caer

El caso de UTA0576 no invalida el parcheo: lo pone en su sitio. Actualizar es necesario, y en este caso urgente. Pero un VPN parcheado no es un VPN a salvo cuando existen fallos que el fabricante todavía no conoce o no ha corregido [3]. Si el acceso remoto llega a tu red OT, conviene revisar la segmentación, limitar privilegios y vigilar lo que ocurre más allá del propio equipo.

Revisar hoy cómo entra cada proveedor en tu planta, y qué podría alcanzar alguien que suplantara ese acceso, es un ejercicio que merece la pena hacer antes del próximo aviso. Si quieres abordarlo con una visión completa del entorno industrial, puedes consultar el enfoque de seguridad OT industrial de Hodeitek.