El 27 de septiembre CISA sumó CVE-2026-88771 y CVE-2026-88772 a su catálogo de vulnerabilidades explotadas, con plazo de corrección al 30 de septiembre, o sea 3 días. Las dos están en NetScaler ADC y NetScaler Gateway, y la primera es la que más incomoda: según el texto de Citrix, permite "an unauthenticated attacker to execute arbitrary commands". Sin credenciales, comandos arbitrarios.
Las dos son parte de un boletín más grande, que cubre ocho fallas correlativas de CVE-2026-88771 a CVE-2026-88778. Y una aclaración de método antes de seguir: la página del boletín de Citrix devuelve 403 desde este entorno, así que no la pude leer. Los datos de las ocho que van abajo salen de la ficha de cada CVE en NVD, donde el que puntúa y describe es Citrix como autoridad de numeración, o sea el mismo texto del fabricante por otro camino. Lo que el boletín pueda decir sobre versiones fuera de soporte o sobre condiciones de configuración no lo pude verificar y por eso no lo afirmo.
Las ocho fallas del boletín, y por qué CISA catalogó solo dos
Ese detalle es la lección más transferible de la tanda. CVE-2026-88773 tiene 9,3, también es crítica y no está en el catálogo. No porque sea menos grave, sino porque el catálogo de CISA registra otra cosa: explotación observada, no gravedad. Son dos preguntas distintas y conviene no confundirlas, porque llevan a decisiones distintas. El puntaje dice cuánto daño puede hacer; el catálogo dice si alguien ya lo está haciendo.
En la práctica, para quien administra el equipo, la distinción no cambia el trabajo: la misma actualización corrige las ocho. Las versiones corregidas, según el texto de Citrix, son la 14.1-73.37 y la 13.1-64.23 para ADC y Gateway, más la 14.1-73.37 FIPS y la 13.1.37.279 en FIPS y NDcPP.
Vale anotar una diferencia entre fuentes, de las que este sitio viene marcando: CISA etiqueta las dos entradas como CWE-119, un problema de manejo de memoria, mientras que Citrix clasifica la 88771 como CWE-20, validación de entrada. No es un error de nadie, son dos lecturas del mismo defecto, pero si buscás por clase de falla vas a encontrar cosas distintas según dónde busques.
Las tres de denegación de servicio son las únicas que no salen del NetScaler
Hay un dato en los vectores que vale la pena leer, y que retoma lo que explicaba la nota de WordPress de ayer sobre las diferencias entre las escalas. CVSS 4.0 tiene un eje que la versión 3.1 no tenía: mide aparte el impacto en el sistema siguiente, o sea si el daño se queda en el equipo afectado o sigue de largo hacia lo que está detrás.
Mirando ese eje en las ocho: cinco arrastran impacto más allá del propio equipo y tres no. Y las tres que no son exactamente CVE-2026-88775, CVE-2026-88776 y CVE-2026-88777, las tres cuyo efecto descrito es comportamiento erróneo o denegación de servicio.
Tiene toda la lógica, y por eso vale decirlo: lo que solo tira abajo el equipo se queda en el equipo; lo que ejecuta código lo atraviesa. Un NetScaler caído es una interrupción molesta. Un NetScaler con código ajeno adentro es un problema de la red entera, porque el equipo está justo en el medio y guarda las credenciales y los certificados con los que habla con todo lo demás.
Citrix no dice actualizá el NetScaler, dice reconstruilo
Acá está lo que hace a esta nota distinta de las dos anteriores sobre NetScaler de este mismo sitio. Junto a las entradas del catálogo, CISA remite a un documento propio de Citrix con el título "Steps to Take if NetScaler ADC is Suspected to be Compromised". Y ese documento no describe una actualización. Describe una reconstrucción.
Hay una frase en ese documento que conviene leer dos veces si el equipo es una máquina virtual: para VPX, "Cloud Software Group recommends replacing and restoring the instance". Reemplazar, no limpiar. Para los equipos físicos MPX, remite a su guía de borrado y reinstalación.
El paso final tampoco es corto: endurecer el equipo y vigilarlo durante 90 días después de recuperarlo. Y hay otra frase que define el alcance de lo que podés esperar del fabricante: "Cloud Software Group does not support forensic investigations". Te dan el paquete de soporte técnico y el archivo de volcado para que se los lleve tu equipo de respuesta a incidentes, pero el análisis no lo hacen ellos. Si no tenés a quién dárselo, ese es un problema a resolver antes de que haga falta, no después.
Es la versión extrema de algo que este sitio viene repitiendo desde la nota de GitLab: el parche cierra la puerta, no echa a quien ya entró. En un servidor de aplicaciones eso significa revisar. En un equipo de borde que termina sesiones cifradas y guarda credenciales de servicio, el propio fabricante te dice que significa tirarlo y empezar de nuevo.
¿A quién afecta CVE-2026-88771 de Citrix NetScaler?
A quien tenga NetScaler ADC o NetScaler Gateway en versiones anteriores a la 14.1-73.37 o a la 13.1-64.23, según la línea que use, con las variantes FIPS y NDcPP en su propia numeración.
En una PyME chica esto no suele estar. Donde sí aparece es en la empresa mediana que resolvió el acceso remoto con un equipo dedicado: NetScaler Gateway es, en muchas de esas redes, la puerta de entrada de todo el mundo que trabaja de afuera. Si es tu caso, el equipo no es un servidor más: es el que ve todas las sesiones y guarda los certificados.
Y conviene ubicarlo en el patrón más largo, porque no es una casualidad de esta semana. En los últimos 32 días este sitio publicó cinco notas sobre fallas explotadas en equipos de borde: WatchGuard Firebox, switches de Zyxel, Check Point, F5 y Arista y NetScaler, dos veces antes. Lo que atrae al atacante no es la marca: es la posición del equipo en la red.
¿Quién puede ignorar las ocho fallas de NetScaler?
Quien no tenga NetScaler. Si el acceso remoto de tu organización pasa por un servicio en la nube o por una red privada moderna en vez de un equipo propio en el borde, esta tanda no te toca —y ese enfoque es justamente el que discute la guía de acceso remoto sin VPN—.
Y quien ya esté en la 14.1-73.37 o la 13.1-64.23, o posterior. Con una salvedad importante: estar actualizado hoy responde la pregunta de si te pueden entrar, no la de si ya entraron. Si el equipo estuvo expuesto con una versión vieja durante los días previos, la pregunta que queda abierta es la segunda.
¿Cómo sé si mi NetScaler está comprometido?
Primero lo fácil: la versión. Está en la consola de administración y en la salida de la línea de comandos del equipo. Si es anterior a las corregidas, estuviste expuesto.
Lo segundo es más incómodo y es lo que pide CISA en la nota de las dos entradas: "running the provided IOCs in the NetScaler console may help identify indicators of exploitation", y exige además una revisión forense. O sea que el fabricante publicó indicadores de compromiso para correr en el propio equipo, y la recomendación oficial es usarlos, no suponer.
Dos cosas que hay que decir con precisión acá. La primera: los indicadores concretos están en el boletín de Citrix, que no pude leer desde este entorno, así que no los reproduzco ni los resumo de segunda mano. Están en el aviso del fabricante y en el artículo de respuesta que sí es accesible, y ahí hay que ir a buscarlos. La segunda: un resultado limpio con esos indicadores es una buena señal, no un certificado. Los indicadores encuentran lo que se sabe buscar.
Lo que sí se puede hacer sin depender de eso, y que sale del paso 4 del procedimiento de Citrix: mirar hacia adentro, no solo al equipo. Si el NetScaler fue tomado, lo valioso no era el equipo, eran las credenciales de servicio y los certificados que tiene guardados, y el camino hacia los servidores de autenticación con los que habla. Revisar accesos raros en esos servidores en las fechas en que el equipo estuvo sin parchear es una búsqueda que no necesita ningún indicador publicado.
¿Qué hago si tengo NetScaler en el borde de mi red?
El orden depende de una sola pregunta: si encontraste indicadores o no.
Ese último punto es el que se pasa por alto con más frecuencia y el que no tiene vuelta atrás: el reflejo de actualizar apenas se lee el aviso destruye lo que haría falta para saber si te entraron. Si tenés cualquier sospecha, la instantánea va primero. Tarda minutos y es la diferencia entre poder responder la pregunta y no poder responderla nunca.
Sobre el paso de restaurar configuración, una consecuencia que conviene tener resuelta de antes: el procedimiento pide una copia anterior al compromiso, lo que supone tener copias con historia y saber de qué fecha es cada una. Si tus copias se sobrescriben, ese paso no existe. Es el mismo argumento de backup y recuperación aplicado a un equipo de red, que es donde menos se piensa en copias.
Los términos técnicos que aparecen acá están en el glosario, y las alternativas del catálogo para resolver el acceso remoto, en VPN y acceso remoto.
Preguntas frecuentes sobre CVE-2026-88771 y NetScaler
Actualicé el firmware. ¿Ya estoy tranquilo?
Depende de si el equipo estuvo expuesto antes de actualizar. Actualizar impide que entren de ahora en adelante, pero no revierte lo que haya pasado antes, y en este equipo lo que puede haber pasado incluye que se lleven las credenciales de servicio y las claves privadas de los certificados. Por eso el procedimiento de Citrix para un equipo sospechado no es actualizar: es preservar evidencia, aislar, revocar credenciales, reconstruir y rotar todo de nuevo.
¿Por qué CVE-2026-88773 tiene 9,3 y no está en el catálogo de CISA?
Porque el catálogo no ordena por gravedad. Registra las fallas para las que hay evidencia de explotación en el mundo real, y hasta ahora esa evidencia existe para las dos de 9,5 y no para la de 9,3. Son dos preguntas distintas: el puntaje dice cuánto daño puede hacer, y el catálogo dice si alguien ya lo está haciendo. Para el trabajo concreto no cambia nada, porque la misma actualización corrige las ocho.
Tengo NetScaler pero no lo uso como Gateway de acceso remoto. ¿Me afecta igual?
El texto de Citrix en las fichas de los CVE nombra tanto a ADC como a Gateway, sin distinguir configuraciones para estas dos fallas. Los boletines de Citrix suelen aclarar cuándo una falla requiere que el equipo esté configurado de una forma determinada, pero la página del boletín no es accesible desde este entorno y no la pude leer, así que no puedo confirmar si hay una condición de ese tipo. Ante la duda, la versión corregida es la misma para todos los casos.
¿Cómo consigo los indicadores de compromiso para revisar el equipo?
Están en el aviso del fabricante, y CISA remite a él desde las dos entradas del catálogo. No los reproduzco acá porque el boletín devuelve 403 desde donde escribo esta nota, y repetir indicadores de segunda mano es la forma más fácil de publicar un dato equivocado sobre un equipo crítico. El artículo de respuesta CTX694799 sí es accesible y es el que describe el procedimiento completo.
Somos una empresa chica y nuestro acceso remoto es un NetScaler viejo. ¿Qué hago si no puedo actualizarlo hoy?
Si no podés actualizar en el plazo, lo que sí podés hacer hoy es reducir la exposición: limitar desde qué direcciones se llega a la interfaz de administración, y si el servicio de acceso remoto no es imprescindible en estos días, apagarlo hasta poder actualizar. Un equipo de borde apagado no es explotable. Y si el equipo quedó fuera de soporte y no hay versión corregida para tu línea, eso ya no es un problema de parches sino de reemplazo, con una fecha puesta.