El 4 de octubre CISA agregó CVE-2026-88779 al catálogo de vulnerabilidades explotadas, con plazo al 7 de octubre. Está en NetScaler ADC y NetScaler Gateway, y el número no es casualidad: es el que sigue a la serie 88771–88778 que este sitio cubrió el 1 de octubre.
Y hay algo que corregir de esa nota, porque cambia qué tiene que hacer quien la leyó.
La 14.1-73.37 corrigió las ocho anteriores y no corrige CVE-2026-88779
En la nota del 1 de octubre escribí que la misma actualización corregía las ocho de la serie, y di como versiones corregidas la 14.1-73.37 y la 13.1-64.23. Eso era cierto para esas ocho y sigue siéndolo. No alcanza para la novena.
Dicho sin vueltas: si seguiste la recomendación de esa nota y quedaste en la 14.1-73.37, hoy tenés que actualizar de nuevo, a la 14.1-73.41. La 13.1-64.23 tiene el mismo problema y pasa a la 13.1-64.28.
Es un buen recordatorio de algo incómodo sobre este tipo de cobertura, incluida la propia: una lista de versiones corregidas tiene fecha de vencimiento, y en un producto que acumula fallas semana a semana ese vencimiento llega rápido. La versión correcta no es la que leíste, es la que el fabricante publica hoy.
Solo tira el equipo abajo, y aun así CISA le puso 3 días
Lo segundo que distingue a esta falla de las ocho anteriores es el efecto. Las dos que CISA catalogó la semana pasada terminaban en ejecución de código y acceso de administrador. Esta, según el catálogo, "could allow for a denial of service". Nada más.
El vector que publicó Citrix lo confirma y vale leerlo porque es explícito: no hay impacto en confidencialidad ni en integridad, solo en disponibilidad, y CISA clasifica el impacto técnico como parcial, no total. O sea: no se llevan datos, no cambian nada. Apagan el equipo.
Pero lo marcan como explotación activa y automatizable de punta a punta, y le ponen el mismo plazo de 3 días que a una falla de ejecución de código. Vale preguntarse por qué, y la respuesta sale de medir el catálogo.
Ahí está la explicación, y es más interesante que la falla. Para casi cualquier sistema, una denegación de servicio es una molestia; para un equipo de borde, es el ataque. Un NetScaler Gateway es la puerta por la que entra a trabajar toda la gente que está afuera de la oficina. Tirarlo abajo no filtra un solo dato y sin embargo detiene a la empresa entera.
Por eso el plazo de 3 días no es desproporcionado aunque el impacto sea "parcial": lo que se mide no es cuánta información se pierde, es cuánto se interrumpe. Y es la tercera vez en poco más de un año que NetScaler aparece en el catálogo con una falla de este tipo: también en junio de 2025 y en agosto de 2026.
Cuarta nota sobre NetScaler en 39 días
Vale decirlo porque empieza a ser el dato principal. Este sitio cubrió NetScaler el 27 de agosto, el 10 de septiembre, el 1 de octubre y hoy. Son 4 notas en 39 días, y Citrix acumula 27 entradas en el catálogo.
Eso no es un argumento para cambiar de marca, y conviene decirlo porque es la conclusión apresurada. El sitio ya mostró que lo que atrae al atacante es la posición del equipo en la red y no el fabricante. Lo que sí es, es un argumento sobre el costo operativo real de tener un equipo propio en el borde: si el fabricante publica fallas explotadas cada dos semanas, alguien tiene que estar mirando cada dos semanas. Ese costo no aparece en el presupuesto del equipo, y es el que discute la guía de acceso remoto sin VPN.
Las páginas de Citrix sobre CVE-2026-88779 no se pueden leer desde acá
Igual que el 1 de octubre: la entrada de blog de Citrix sobre esta falla devuelve 403 desde donde escribo, y el artículo de la base de conocimiento CTX697174 responde pero solo entrega un contenedor vacío sin texto del artículo. Lo comprobé en los dos casos.
Así que los datos de arriba —versiones afectadas, versiones corregidas, puntaje y vector— salen de la ficha del CVE en NVD, donde el texto y el puntaje son de Citrix como autoridad de numeración. Es el texto del fabricante por otro camino, no una fuente de segunda mano. Lo que esas páginas puedan decir sobre paliativos, indicadores o condiciones de configuración no lo pude leer y por eso no lo afirmo.
¿A quién afecta CVE-2026-88779 de NetScaler?
A quien tenga NetScaler ADC o NetScaler Gateway por debajo de la 14.1-73.41 o de la 13.1-64.28, según la línea, con las variantes FIPS en su propia numeración: 14.1-73.41 FIPS y 13.1-37.282.
El caso que más importa es el que ya actualizó. Si la semana pasada llevaste el equipo a la 14.1-73.37 por la serie anterior, estás en una versión corregida para esas ocho y vulnerable a esta. No es un error de nadie: es que salió una falla nueva después.
Y como el efecto es una caída, el perfil de riesgo cambia respecto de las anteriores: no hay que preguntarse qué se llevaron, hay que preguntarse cuánto aguanta la empresa con el acceso remoto caído.
¿Quién puede ignorar CVE-2026-88779 de NetScaler?
Quien no tenga NetScaler.
Quien ya esté en la 14.1-73.41 o la 13.1-64.28, o posterior.
Y con una matización honesta: si tu NetScaler no publica nada a internet y solo se usa dentro de la red, el riesgo baja mucho, porque el atacante necesita llegar al equipo. Pero eso es infrecuente en este producto, cuya razón de existir es justamente atender conexiones de afuera.
Lo que no alcanza para ignorarla: que sea "solo" una caída. Si el acceso remoto de tu organización depende de ese equipo, una caída provocada a voluntad y de forma automatizable es un problema de continuidad, no de seguridad de los datos.
¿Cómo sé si mi NetScaler está en la versión correcta?
- Mirá la versión exacta, con los cuatro números. Acá el dígito final es todo: 14.1-73.37 y 14.1-73.41 se parecen y una está corregida y la otra no.
- Fijate si usás una variante FIPS o NDcPP, porque tienen numeración propia y es donde más fácil se confunde cuál corresponde.
- Si administrás varios equipos, lo que importa no es la versión de uno sino cuántos quedaron atrás, incluido cualquier equipo de escenario en espera de ser promovido.
Para saber si ya la usaron contra tu equipo, el síntoma de esta falla es distinto de las anteriores y en cierto modo más visible: caídas o reinicios del servicio sin causa aparente, posiblemente repetidos. Si en los últimos días el acceso remoto se cortó y nadie supo por qué, esa es la señal a revisar en los registros del equipo, cruzada con la versión que tenía en ese momento.
Conviene aclarar lo que no se puede: una caída provocada por esta falla y una caída por cualquier otro motivo se parecen bastante desde afuera. No tengo indicadores publicados del fabricante para distinguirlas, porque no pude leer sus páginas, así que lo que corresponde es tratar una caída inexplicada en una versión vulnerable como sospechosa y no como resuelta.
¿Qué hago con mi NetScaler si ya actualicé la semana pasada?
- Actualizá a la 14.1-73.41 o la 13.1-64.28 según tu línea, incluso si actualizaste la semana pasada. Es el punto entero de esta nota.
- Si tenés FIPS o NDcPP, verificá la versión que corresponde a tu variante antes de bajar nada.
- Planificá la ventana contando con que el equipo se reinicia. Como el efecto de la falla es una caída, la ironía es que la corrección también interrumpe: mejor una interrupción tuya y avisada que una ajena y a las 3 de la tarde.
- Revisá los registros por caídas o reinicios recientes del servicio, cruzando con la versión que tenía el equipo esos días.
- Anotá en algún lado quién mira los avisos de Citrix y con qué frecuencia. Cuatro tandas en 39 días es una cadencia que no se sostiene con buena voluntad: necesita estar asignada a alguien.
El contexto más largo sobre este producto está en la nota del 1 de octubre, que además describe el procedimiento del fabricante para un equipo del que se sospecha compromiso, y los términos, en el glosario.
Preguntas frecuentes sobre CVE-2026-88779 y NetScaler
Actualicé la semana pasada por las otras fallas. ¿Tengo que actualizar otra vez?
Sí, si quedaste en la 14.1-73.37 o la 13.1-64.23. Esas versiones corrigen las ocho fallas de la serie anterior y no corrigen esta novena, que necesita la 14.1-73.41 o la 13.1-64.28. No es que la actualización anterior estuviera mal: es que después salió una falla nueva, con su propia versión corregida.
Si solo provoca una caída, ¿por qué tiene plazo de 3 días?
Porque en un equipo de borde la disponibilidad es la función. Un NetScaler Gateway es por donde entra a trabajar la gente que está fuera de la oficina, así que tirarlo abajo no filtra datos pero detiene la operación. Y el catálogo marca esta falla como explotada y automatizable de punta a punta, lo que significa que alguien puede hacerlo a escala y sin esfuerzo. El plazo no mide cuánta información se pierde, mide cuánto se interrumpe.
¿Puede el atacante aprovechar la caída para algo más?
Con esta falla puntual, no según el vector que publicó Citrix: el impacto es solo en disponibilidad, sin efecto en confidencialidad ni integridad, y CISA clasifica el impacto técnico como parcial. Eso no significa que una caída no pueda ser parte de algo más grande en un ataque real, pero esa es una especulación que no sale de estos documentos y no la voy a presentar como un hecho.
¿Cómo distingo una caída por esta falla de una caída normal?
Desde afuera se parecen, y es honesto decirlo. No pude leer las páginas de Citrix sobre esta falla porque devuelven 403 o llegan vacías, así que no tengo indicadores del fabricante para ofrecerte. Lo que corresponde es lo conservador: si el equipo se cayó o se reinició sin explicación en días en que corría una versión vulnerable, tratalo como sospechoso, revisá los registros y actualizá.
Cuatro tandas de fallas en 39 días. ¿Conviene cambiar de fabricante?
El historial del catálogo no respalda esa conclusión: en los últimos meses aparecieron fallas explotadas en equipos de borde de Citrix, Cisco, Fortinet, Check Point, F5, Arista, WatchGuard, SonicWall y Zyxel. Lo que atrae al atacante es la posición del equipo, que está expuesto a internet y es la puerta de todo lo demás, no el nombre de la marca. La pregunta útil no es qué marca comprar sino si tenés a alguien asignado a mirar los avisos de la marca que ya tenés, y con qué frecuencia.