El lunes 2 de noviembre, Ivanti publicó parches para dos vulnerabilidades nuevas en Connect Secure, su pasarela de acceso remoto. Son CVE-2026-111357, una escalada de privilegios de severidad alta, y CVE-2026-118527, que permite subir ficheros a un equipo sin actualizar. Ninguna funciona sola: llevan un mes encadenándose con CVE-2026-104935, un bypass de autenticación corregido el mes pasado, hasta lograr ejecución de código como root sin credenciales en aparatos que estaban completamente parcheados.
La cifra que ordena la urgencia la da Shadowserver, que rastrea más de 5.000 instancias de Connect Secure expuestas a internet y no puede decir cuántas han aplicado ya las actualizaciones. Connect Secure no es un programa cualquiera en la red de una empresa. Es la puerta por la que entran empleados y proveedores desde fuera, y por eso los atacantes la eligen desde hace años.
Un aparato así combina acceso remoto, credenciales y confianza implícita en una sola caja que casi nadie revisa a diario. El detalle incómodo de esta cadena no es el acceso, es la ausencia de rastro: quien entró no dejó malware ni webshell, volvió a explotar el equipo en cada comando y tocó los registros para que el Integrity Checker Tool de Ivanti no viera nada raro.
La cadena que empieza en octubre
Volexity siguió el rastro de un actor al que llama UTA0576 y fechó el uso de CVE-2026-104935 al menos desde el 3 de octubre, combinado con otras dos piezas que ahora tienen nombre. El resultado era acceso root sin autenticar sobre dispositivos actualizados, algo que en la práctica convierte la pasarela en un punto de entrada silencioso a toda la red corporativa.
La firma de inteligencia Defused registró los primeros indicios de explotación el 1 de octubre, dos días antes de la fecha que publicó Volexity. Esa diferencia de dos días no cambia el incidente, pero sí recuerda que las cronologías de un ataque se construyen con retraso y que las primeras señales suelen estar en el tráfico, no en el disco.
La cronología de Ivanti explica por qué las dos vulnerabilidades de hoy llegan tarde. Cuando la empresa descubrió la explotación de CVE-2026-104935 ya tenía un arreglo para la escalada de privilegios en control de calidad, y decidió no retrasar la entrega de lo que cortaba la vía principal de ataque.
Es una decisión defendible y a la vez una lección sobre cómo se comunican los parches parciales. Quien leyó el aviso de octubre y actualizó se quedó con la mitad del problema resuelto, sin saberlo, durante cuatro semanas.
Un ataque sin malware que borra sus huellas
La descripción técnica del intruso es la parte que más debería preocupar a un equipo defensivo. En lugar de instalar una puerta trasera, el atacante repetía la explotación cada vez que necesitaba ejecutar algo. No había binario que detectar, ni proceso persistente que matar, ni fichero que enviar a un sandbox.
Solo había peticiones legítimas en apariencia contra un servicio que estaba haciendo su trabajo. A eso se suma la manipulación de registros para esquivar el Integrity Checker Tool, el mecanismo con el que Ivanti permite comprobar si un equipo ha sido alterado. La herramienta sigue siendo útil, pero deja de ser prueba de inocencia cuando el adversario sabe exactamente qué mira.
La lección se repite en cada incidente de este tipo. La integridad de un aparato no se demuestra solo con su propio verificador, se demuestra con telemetría externa que nadie dentro del equipo puede reescribir. En la práctica, eso significa conservar durante semanas los logs de la pasarela en un sistema aparte y revisar sesiones administrativas fuera de horario.
También implica auditar certificados emitidos sin un proceso claro detrás y tratar cualquier acceso nuevo a la consola de administración como un evento que merece explicación. Es trabajo menos vistoso que buscar un nombre de malware en VirusTotal y, precisamente por eso, es el que suele faltar cuando llega la auditoría posterior.
Cinco mil puertas expuestas y un calendario de parches
La cifra de instancias expuestas no baja con la misma velocidad con la que se publican los avisos. Muchas organizaciones heredaron su Connect Secure de un contrato anterior, lo gestiona un proveedor externo o vive en una sucursal que nadie visita. Si a eso se suma que el aparato funciona, actualizarlo entra en una lista de tareas que compite con cien cosas más urgentes.
El 28 de octubre, la agencia de ciberseguridad estadounidense metió CVE-2026-104935 en su catálogo de fallos explotados y dio a las agencias federales hasta el viernes para aplicarlo. Ese tipo de orden tiene un efecto secundario útil: convierte una nota de proveedor en una fecha límite con consecuencias. Fuera del sector público, la mayoría de empresas sigue sin un calendario equivalente.
Ivanti tiene un historial cargado en esta familia. En enero de 2024 corrigió una inyección de comandos, CVE-2024-21887, junto a un bypass de autenticación, CVE-2023-46805, y dos semanas después un fallo de falsificación de peticiones del lado del servidor. En enero de 2025 llegó CVE-2025-0282, una ejecución remota de código explotada como zero-day.
El patrón no es casualidad. Son aparatos con mucha superficie, poca observabilidad y una posición en la red que los hace rentables. Quien tenga uno delante debería tratar la actualización como un incidente y no como mantenimiento, con rotación de credenciales y revisión de los accesos de las últimas seis semanas.
El reloj cuenta tanto como el fallo. Un parche que llega cuatro semanas tarde no evita la intrusión, solo acorta su duración, y en ese intervalo el atacante ya decidió qué copiar, por dónde salir y a qué proveedor culpar.
Aplicar el parche es el primer paso, no el último. La guía para leer un CVE y saber si te afecta ayuda a ordenar esa revisión sin perder tiempo en siglas, y el repaso al CVE-2026-98432 del kernel de Linux que ya publicamos muestra hasta qué punto un mismo mes puede acumular fallos críticos en capas muy distintas.
Por qué las VPN seguirán siendo el objetivo fácil
Los atacantes no eligen estas pasarelas por elegancia técnica. Las eligen porque concentran tres cosas que ninguna empresa puede permitirse perder a la vez: acceso, identidad y confianza. Un fallo en una aplicación interna afecta a una aplicación. Un fallo en la puerta de entrada afecta a todo lo que hay detrás.
Ese cálculo seguirá funcionando mientras las VPN sean el pegamento de las redes corporativas. La corrección de fondo no es un parche más rápido, es reducir el número de puertas. Cada servicio que se mueve detrás de un modelo de acceso con identidad verificada y permisos mínimos resta valor a la siguiente cadena de zero-days, que llegará.
Mientras tanto, la única defensa realista es aburrida y conocida: inventario de lo expuesto, parcheo con fecha, registros fuera del alcance del atacante y una revisión honesta de qué confianza regala cada aparato. Ninguna de esas tareas cabe en un titular, y todas ellas juntas son las que deciden si una cadena de zero-days se queda en un susto o en un trimestre perdido.
Si el atacante puede entrar, ejecutar como root y borrar sus huellas sin dejar un solo fichero, ¿cuántas intrusiones de las últimas semanas siguen sin detectarse en redes que se consideran limpias porque el antivirus no dijo nada?
