El 13 de octubre el catálogo de vulnerabilidades explotadas de CISA pasó a la versión 2026.10.13 y sumó dos entradas, las dos con plazo al 16 de octubre: 3 días. Para comparar, la mediana del plazo de las 305 entradas de los últimos 12 meses es de 14 días, y el plazo más corto que usó el catálogo en ese período fue de 2 días. Cuando el catálogo da tres, no está midiendo gravedad: está diciendo que lo están usando ahora, como ya pasó con las siete altas de septiembre.
Las dos:
- CVE-2026-104935, en Ivanti Connect Secure: bypass de autenticación que permite ejecutar comandos sin credenciales. 8,6, puntaje asignado por Ivanti como autoridad de numeración.
- CVE-2026-96951, en Windows Shell: 8,8 según Microsoft, que la marca como explotada el mismo día que publicó su actualización mensual.
CVE-2026-104935 y CVE-2026-96951: qué hace cada una
Vale detenerse en ese último renglón, porque es el tipo de dato que se lee mal. En la falla de Windows, NVD figura con estado "Undergoing Analysis": el 8,8 que aparece en su ficha tiene como fuente a Microsoft. No hay todavía una segunda opinión del NIST, ni rangos de versiones validados por NVD. En la de Ivanti pasa algo parecido: el 8,6 lo puso Ivanti actuando como autoridad de numeración, y lo verifiqué contra el registro oficial del programa CVE, donde el campo que identifica a quien lo firma dice ivanti.
Y un detalle del propio catálogo que conviene saber antes de hacer clic: la URL del aviso de Ivanti que publica el KEV está mal escrita, con una sola barra en https:/forums.ivanti.com/.... Además forums.ivanti.com ahora redirige a hub.ivanti.com. Si copiás el enlace tal como viene, no llegás.
Microsoft publicó 1413 fallas en octubre y una se está usando
Ese es el dato con el que conviene quedarse si administrás equipos y no tenés un área de IT: 1413 fallas publicadas, 1 que alguien está usando. El resto se parchea con el ciclo normal. La que corre es la de Windows Shell, y es la que entró al catálogo de CISA el mismo día.
Sobre el mecanismo hay que ser preciso con lo que el fabricante dice y lo que no. Microsoft la titula "Windows Shell Security Feature Bypass Vulnerability" y define el impacto como evasión de una característica de seguridad, pero no dice cuál característica: el campo que listaría los binarios corregidos viene vacío y no hay guía de detección, ni artefactos de registro, ni indicadores. El vector sí aclara algo importante: requiere interacción del usuario, así que no es un gusano que entre solo. Lo que no se puede afirmar es qué tiene que hacer exactamente la víctima, porque Microsoft no lo publica.
Tampoco hay workaround: verifiqué que no publica ninguna mitigación provisoria. O se aplica el parche, o se queda expuesto.
Ivanti dice que la 22.7R2.14 y las anteriores no están afectadas
Acá está la parte contraintuitiva, y es fácil publicarla al revés. De hecho yo la tenía mal redactada antes de verificarla.
Lo que dice el registro oficial, que Ivanti redacta porque actúa como autoridad de numeración, es textual: "Authentication bypass by spoofing in ICS before version 25.1.3.0 allows a remote unauthenticated attacker to execute arbitrary commands. This does not impact ICS version 22.7R2.14 or prior."
El "or prior" es inclusivo: la 22.7R2.14 está entre las no afectadas, no afuera. Y el registro la lista explícitamente junto a los parches, lo que dice algo sobre qué es: no es una versión atrasada, es el nivel de parche vigente de su línea de código. Por eso no corresponde la conclusión fácil de que "estar atrasado te salva". El rango afectado tampoco es una banda continua, como muestra el diagrama.
Hay una inconsistencia que conviene conocer antes de planificar la actualización: el blog de Ivanti lista la 25.1.1.2 entre los arreglos, pero esa versión no figura en la lista de no afectadas del registro oficial. Son dos fuentes del mismo fabricante que no coinciden, y no pude resolver cuál manda. Lo prudente es apuntar a 25.1.3.0 o posterior, que es la única rama que las dos fuentes tratan como corregida.
Dos cosas más que Ivanti dice y que cambian la planificación. La primera: hay un segundo bug encadenado todavía sin parche. En sus palabras, el arreglo de "una falla de escalada de privilegios relacionada, usada en la misma cadena", llega "en las próximas semanas". La segunda: las líneas 22.x dejan de tener soporte el 31 de enero de 2027, y el fabricante recomienda pasar a 25.x por eso.
Connect Secure: cinco de cinco antecedentes terminaron en ransomware
Esto lo calculé sobre el feed del catálogo, y hay una trampa de método que conviene declarar antes del número.
La trampa es la carga inicial del catálogo: el 3 de noviembre de 2021 entraron 287 entradas de una sola vez, y 8 de las 14 de Connect Secure son de ese día. Contarlas como si fueran incidentes separados a lo largo del tiempo infla el historial. Descontándolas quedan 6 altas secuenciales, y ahí el patrón es nítido: las 5 anteriores a la de ahora figuran con uso confirmado en campañas de ransomware. La nueva dice "desconocido", que no es lo mismo que "no".
Un detalle de conteo, por si alguien reproduce el cálculo: hay una entrada más de la familia bajo el fabricante antiguo "Pulse Secure", separado de "Ivanti" en el catálogo, así que la familia completa suma 15 y no 14.
Y el contexto más amplio: los equipos de acceso remoto y VPN de 6 fabricantes suman 90 de las 1741 entradas, el 5,2% —Citrix 21, Cisco 16, Fortinet 15, Ivanti 14, Palo Alto 12 y SonicWall 12—. El aparato que existe para dejar entrar gente de afuera es el que acumula historial, y es el mismo razonamiento de la falla de NetScaler donde parchear no alcanzaba y de las diez fallas del componente de VPN de WatchGuard.
¿A quién afectan CVE-2026-104935 y CVE-2026-96951?
La de Ivanti toca a quien tenga un Ivanti Connect Secure publicado para dar acceso remoto, en las líneas 25.1 o 22.8R2. No es el equipo de la PyME de cinco personas: es el de la empresa con sucursales, con personal que entra desde afuera, o la que lo heredó de un proveedor de IT. Si no sabés si tenés uno, la pregunta concreta a quien administra la red es si el acceso remoto pasa por un appliance de Ivanti, Pulse o alguna de sus marcas anteriores.
La de Windows Shell toca a mucho más gente, porque son 31 productos y versiones de Windows. Pero necesita que el usuario haga algo, así que su camino de entrada es el de siempre: un archivo o un adjunto que alguien abre. Es el terreno de cómo funciona el robo de sesión, donde el eslabón es la persona y no el servidor.
¿Quién puede ignorar el aviso de Ivanti Connect Secure?
Quien no tenga ningún appliance de acceso remoto de Ivanti, que es la mayoría de las PyMEs chicas.
Quien tenga Connect Secure en 25.1.3.0, 25.1.3.1 o 22.8R2.5, que son las versiones que el registro oficial de Ivanti marca como no afectadas.
Quien tenga Connect Secure en 22.7R2.14, porque el fabricante la lista explícitamente como no afectada. Con una advertencia que no es menor: esa línea pierde soporte el 31 de enero de 2027, así que no estar afectado hoy no significa poder quedarse ahí.
Para la de Windows, en cambio, prácticamente nadie puede ignorarla: alcanza con haber aplicado la actualización de octubre. Lo que no alcanza es tener antivirus o EDR, porque Microsoft no publica indicadores ni guía de detección para esta falla, así que no hay nada específico que un producto pueda estar buscando.
¿Cómo sé qué versión de Ivanti Connect Secure tengo?
- Entrá a la consola de administración del appliance. La versión figura en la pantalla de estado del sistema. Compará contra la lista de cuatro versiones no afectadas: 25.1.3.0, 25.1.3.1, 22.8R2.5 y 22.7R2.14.
- Para Windows, mirá el número de compilación, que es más confiable que "¿se actualizó?". Los parches de esta falla son KB5127648 para las versiones 24H2, 25H2 y 26H2, KB5127646 para 26H1 y KB5126653 para 23H2. Las compilaciones corregidas terminan en .9711 para 24H2, 25H2 y 26H2, y en 10.0.22631.7652 para 23H2.
- Si el appliance estuvo expuesto y no sabés desde cuándo, el orden importa: Ivanti recomienda correr su Integrity Checker Tool de forma regular. No pude confirmar si conviene correrlo antes o después de actualizar, ni si la actualización borra evidencia, y es un detalle que para una PyME cambia el procedimiento. Si hay sospecha de compromiso, esa pregunta va al fabricante o a un tercero antes de tocar nada.
Sobre qué buscar como señal de uso, hay que ser honesto: para las dos fallas no hay indicadores publicados. Ni Microsoft ni Ivanti publican hashes, dominios ni artefactos de registro, y el catálogo de CISA marca las dos con uso en ransomware "desconocido". Lo que sí corresponde es lo general en un appliance de borde: cuentas de administración que nadie creó, reglas de acceso cambiadas, sesiones desde países donde no tenés gente, y validación de integridad del equipo. El encuadre largo de qué dejar expuesto está en la guía de acceso remoto.
¿Qué hago si tengo un Ivanti Connect Secure publicado?
En este orden, teniendo en cuenta que el plazo del catálogo vence el 16 de octubre, es decir en 2 días:
- Mirá la versión hoy. Es una pantalla y define todo lo demás.
- Si está en una versión afectada, actualizá a 25.1.3.0 o posterior. Es la rama que las dos fuentes de Ivanti tratan como corregida. No hay workaround: ninguna fuente legible del fabricante ofrece una mitigación para quien no puede actualizar, así que no existe la opción de esperar con una regla puesta.
- Tratá el appliance como potencialmente comprometido si estuvo expuesto en una versión afectada. Con cinco de cinco antecedentes de esta línea terminando en ransomware, y con el fabricante pidiendo "validación continua de la integridad del equipo", la hipótesis prudente no es "lo parcheé, listo". Es la misma lógica de reconstruir en vez de parchear que ya aplicó a NetScaler.
- Aplicá la actualización de octubre de Windows en las máquinas, por la otra falla. Es la única de 1413 que alguien está usando.
- Anotá la fecha de fin de soporte de la línea 22.x: 31 de enero de 2027. Si vas a quedarte en 22.7R2.14 porque no está afectada, al menos que la salida esté planificada y no sea una sorpresa en enero.
Los términos están en el glosario, y las alternativas de acceso remoto, en la sección de VPN y acceso remoto.
Una aclaración sobre lo que no se pudo leer, porque cambia el peso de lo que afirmo. El aviso de seguridad de Ivanti para este CVE no se pudo leer: hub.ivanti.com sirve una página de comunidad que solo devuelve un cascarón de JavaScript, y la cadena "CVE-2026-104935" no aparece ni una vez en el HTML servido. Todo lo que digo de Ivanti sale de tres fuentes que sí se pudieron leer: el registro oficial del programa CVE firmado por Ivanti, dos entradas del blog propio del fabricante fechadas el 13 de octubre, y el feed JSON del catálogo de CISA. Por eso no publico la tabla oficial de versiones afectadas: no la pude ver. Y una precisión para evitar una confusión fácil: el blog de Ivanti menciona al grupo Flax Typhoon, pero por las otras cinco fallas que entraron al catálogo el 8 de octubre, no por esta. Para esta no hay atribución publicada; conté las de esa tanda en la nota del 12 de octubre.
Preguntas frecuentes sobre CVE-2026-104935 y CVE-2026-96951
¿Por qué Microsoft publicó 1413 fallas y solo una importa hoy?
Porque el volumen y la urgencia son cosas distintas. De todo el paquete de octubre, exactamente una está marcada con "exploited":"Yes" en la API de Microsoft, y es CVE-2026-96951. Dos más figuran como divulgadas públicamente antes del parche. El resto se aplica con el ciclo normal de actualizaciones. Una advertencia de método: el documento incluye además 341 fallas de Azure Linux que son paquetes de terceros reempaquetados y no traen campo de estado de explotación, así que ese "una" vale sobre las entradas que sí lo traen. Y el propio Microsoft no coincide consigo mismo en el total: su encabezado dice 1413 y la fila Total de su tabla dice 1414.
¿Es verdad que una versión más vieja de Ivanti Connect Secure está más segura?
Es más sutil que eso, y conviene no sacar la conclusión fácil. Ivanti dice textual que la falla "no impacta la versión 22.7R2.14 o anteriores", y el "o anteriores" incluye a la 22.7R2.14 misma. Pero esa versión no es una versión atrasada: el registro oficial la lista como no afectada junto a los parches, o sea que es el nivel de parche vigente de su línea de código. Y el rango afectado no es una banda continua, sino dos tramos de la línea 25.1 más las versiones 22.8R2 a 22.8R2.4. Así que no se sostiene que "estar atrasado protege": lo que hay es un alcance acotado a ciertas líneas.
¿Hay alguna mitigación si no puedo actualizar el appliance ya mismo?
No pude encontrar ninguna, y es importante decirlo con esas palabras. Ninguna fuente legible de Ivanti ofrece un workaround: el blog solo dice que hay que pasar a la versión corregida lo antes posible y recomienda un enfoque por capas, con controles de acceso, monitoreo de red y revisión de registros. Eso es buena práctica general, no una mitigación para esta falla. Microsoft tampoco publica mitigación provisoria para la de Windows Shell. En los dos casos, la respuesta del fabricante es aplicar el parche.
Si actualizo el Ivanti, ¿alcanza con eso?
El fabricante reconoce que hay un segundo problema todavía sin arreglo: dice que el parche de "una falla de escalada de privilegios relacionada, usada en la misma cadena" llega "en las próximas semanas". Así que al 14 de octubre la cadena completa no está cerrada. Sumado a que las cinco altas anteriores de esta línea de producto terminaron con uso confirmado en ransomware, lo prudente si el equipo estuvo expuesto en una versión afectada es tratarlo como potencialmente comprometido y validar su integridad, no solo actualizarlo.
¿Qué característica de seguridad evade la falla de Windows Shell?
Microsoft no lo dice, y preferimos dejarlo así antes que suponerlo. El título oficial es "Windows Shell Security Feature Bypass Vulnerability" y el impacto declarado es evasión de una característica de seguridad, pero el campo que listaría los binarios corregidos viene vacío y no hay guía de detección ni descripción del componente. Lo que sí se sabe por el vector es que requiere interacción del usuario, es decir que alguien tiene que abrir o ejecutar algo. Qué exactamente, no está publicado.