Horas después, el fabricante confirmó ocho vulnerabilidades en NetScaler, incluidas dos críticas que ya estaban siendo explotadas. El episodio también ofrece una primera mirada a un cambio importante en Europa: desde septiembre, los fabricantes están obligados a informar vulnerabilidades activamente explotadas antes de que necesariamente exista una solución.
Durante buena parte del 26 de septiembre, los administradores de Citrix NetScaler se encontraron frente a uno de los escenarios más incómodos posibles en seguridad: había indicios creíbles de ataques reales contra dispositivos expuestos a Internet, pero prácticamente ninguna información pública sobre qué vulnerabilidad estaban utilizando los atacantes.
No había CVE conocido. No había parche. Y todavía no existía un boletín público del fabricante.
Las primeras advertencias comenzaron a circular en comunidades de seguridad y entre administradores, mientras organizaciones recibían recomendaciones para desconectar o aislar sus appliances NetScaler. La firma de investigación watchTowr señaló que estaba reaccionando a información sobre múltiples vulnerabilidades RCE no corregidas y que había podido validar la credibilidad de esas advertencias con fuentes consideradas autoritativas.
Menos de 24 horas después, el panorama cambió.
Citrix publicó el 27 de septiembre un boletín de seguridad que confirma ocho vulnerabilidades en NetScaler ADC y NetScaler Gateway, identificadas como CVE-2026-88771 a CVE-2026-88778. Y, más importante todavía, confirmó que dos de ellas ya habían sido explotadas contra instalaciones que no contaban con mitigaciones.
La emergencia ya tenía nombre.
Dos vulnerabilidades críticas explotadas antes del parche
Las dos fallas más graves recibieron una puntuación CVSS 4.0 de 9,5.
La primera, CVE-2026-88771, permite ejecución remota de código debido a una validación incorrecta de entradas. El escenario es especialmente preocupante porque, según Citrix, afecta a todos los despliegues de NetScaler ADC y NetScaler Gateway, incluso aquellos con la configuración predeterminada. No es necesario habilitar ninguna funcionalidad adicional para quedar expuesto.
La segunda, CVE-2026-88772, es un desbordamiento de memoria capaz de provocar ejecución remota de código o denegación de servicio. En este caso existe una condición: DTLS debe estar habilitado. Sin embargo, Citrix advierte que DTLS está activado por defecto en los servidores virtuales VPN, lo que amplía considerablemente la superficie potencialmente afectada.
Citrix confirmó explícitamente haber observado explotación de ambas vulnerabilidades.
Y eso cambia completamente la prioridad: ya no estamos frente a fallas que podrían convertirse eventualmente en herramientas de ataque. Los atacantes llegaron primero.
Por qué NetScaler es un objetivo particularmente delicado
El problema no es solamente la gravedad técnica de las vulnerabilidades, sino dónde se encuentra NetScaler dentro de una infraestructura empresarial.
NetScaler ADC y NetScaler Gateway suelen cumplir funciones de balanceo de carga, publicación de aplicaciones, autenticación, VPN y acceso remoto. En muchos despliegues están directamente expuestos a Internet y funcionan, literalmente, como una de las puertas de entrada hacia las redes internas.
Comprometer un dispositivo de este tipo es muy diferente a explotar una vulnerabilidad en una estación de trabajo cualquiera.
El atacante está intentando controlar precisamente la infraestructura que media entre Internet, usuarios autenticados y servicios internos.
Por eso los appliances de borde se han convertido en objetivos especialmente valiosos para operaciones de espionaje, ransomware y acceso inicial. Citrix, además, arrastra un historial reciente de vulnerabilidades graves en NetScaler; durante 2026 watchTowr ya había documentado otros problemas pre-authentication en la plataforma, incluyendo fallas de divulgación de memoria y ejecución remota de código.
No eran solamente dos vulnerabilidades
El boletín de Citrix reveló además que la actualización corrige un conjunto mucho mayor de problemas.
Además de los dos RCE explotados activamente, aparecen:
CVE-2026-88773, un HTTP Request Smuggling con CVSS 9,3.
CVE-2026-88774, un bypass de políticas relacionado con expresiones basadas en URL.
CVE-2026-88775, un desbordamiento de memoria que puede generar comportamiento impredecible o denegación de servicio.
CVE-2026-88776, otro desbordamiento de memoria asociado a configuraciones de balanceo Oracle.
CVE-2026-88777, un problema de memoria que afecta determinadas configuraciones con protocolos Layer 7 no HTTP.
CVE-2026-88778, que permite predecir números de secuencia iniciales TCP.
No todas requieren las mismas condiciones de explotación, pero Citrix señala que todos los NetScaler ADC y NetScaler Gateway están afectados por al menos una de las vulnerabilidades incluidas en el boletín.
Los parches ya están disponibles
La situación cambió sustancialmente respecto de las primeras advertencias del 26 de septiembre.
Ya no corresponde simplemente desconectar los equipos mientras se espera una solución: Citrix publicó versiones corregidas y recomienda instalarlas inmediatamente.
Las versiones indicadas son:
NetScaler ADC y NetScaler Gateway 14.1-73.37 o posteriores.
NetScaler ADC y NetScaler Gateway 13.1-64.23 o posteriores.
NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS o posteriores.
NetScaler ADC 13.1-FIPS y 13.1-NDcPP 13.1-37.279 o posteriores.
La actualización, sin embargo, resuelve solamente una parte del problema.
Cuando una vulnerabilidad fue explotada como zero-day, instalar el parche evita nuevas explotaciones pero no demuestra que el dispositivo no haya sido comprometido anteriormente.
Las organizaciones con NetScaler expuestos durante el período de explotación deberían considerar la situación también desde la perspectiva de respuesta a incidentes: revisar evidencias de compromiso, actividad anómala y potencial persistencia, en lugar de limitar el procedimiento a instalar la nueva versión y devolver el appliance a producción.
La otra historia: el Cyber Resilience Act empieza a mostrar sus efectos
Hay además un elemento particularmente interesante en la forma en que apareció esta vulnerabilidad.
Desde el 11 de septiembre de 2026 entraron en vigor en la Unión Europea las obligaciones de reporte de vulnerabilidades activamente explotadas establecidas por el Cyber Resilience Act.
Los fabricantes de productos con elementos digitales deben enviar una advertencia temprana dentro de las 24 horas desde que toman conocimiento de una vulnerabilidad activamente explotada. Luego disponen de 72 horas para presentar información adicional.
Para hacerlo, ENISA puso en funcionamiento su nueva Single Reporting Platform, que permite realizar una única notificación y distribuirla hacia las autoridades correspondientes. Los CSIRT europeos pueden utilizar esa información para coordinar y difundir advertencias.
Esto introduce una dinámica poco habitual.
Históricamente, buena parte de la divulgación de vulnerabilidades seguía una secuencia relativamente intuitiva: el fabricante investigaba, desarrollaba una corrección, asignaba o coordinaba el CVE y finalmente publicaba el advisory junto con el parche.
El CRA introduce deliberadamente otra variable cuando existe explotación activa: la obligación de informar puede aparecer antes de que todo ese proceso esté terminado.
Eso ayuda a explicar por qué defensores pueden recibir una advertencia sobre una amenaza real cuando todavía no existe un CVE público ni una actualización disponible.
Seguridad con información incompleta
El episodio NetScaler muestra tanto la ventaja como la dificultad de ese modelo.
Desde la perspectiva defensiva, saber que una vulnerabilidad desconocida está siendo explotada permite tomar decisiones extraordinarias: restringir accesos, aislar sistemas, aumentar el monitoreo o incluso desconectar temporalmente infraestructura crítica.
Pero también genera una situación incómoda para los equipos de seguridad.
¿Cómo se evalúa el riesgo de una vulnerabilidad cuyo funcionamiento todavía se desconoce? ¿Qué se busca en los logs? ¿Qué controles compensatorios funcionan? ¿Qué versiones están realmente afectadas?
Durante varias horas, esas preguntas no tenían respuestas públicas claras.
Ese vacío informativo no significa necesariamente que el sistema haya fallado. Puede ser precisamente la consecuencia de haber adelantado la advertencia antes de que terminara la investigación técnica y estuviera disponible el parche.
Y ese matiz importa.
El objetivo no debería ser publicar todos los detalles de una vulnerabilidad zero-day mientras continúa siendo explotable, algo que incluso podría facilitar nuevos ataques. El desafío consiste en conseguir que la información suficiente llegue rápidamente a quienes deben defender la infraestructura sin entregar simultáneamente una hoja de ruta a potenciales atacantes.
De un rumor a ocho CVE en menos de un día
La cronología de NetScaler condensa muy bien cómo está cambiando la gestión moderna de vulnerabilidades.
El 26 de septiembre, administradores recibían advertencias sobre vulnerabilidades desconocidas y algunos optaban por sacar equipos de producción.
El 27, Citrix confirmó ocho vulnerabilidades, identificó dos RCE críticos bajo explotación activa y publicó las versiones corregidas.
La lección operativa es bastante menos novedosa que la regulación europea: cuando un dispositivo situado directamente en el perímetro está siendo atacado mediante un zero-day, esperar a que aparezca un CVE perfectamente documentado puede significar esperar demasiado.
Pero el caso deja además una pregunta más interesante para los próximos meses.
Si el flujo observado en NetScaler se vuelve habitual, Europa podría estar inaugurando una etapa en la que los defensores se enteren de ciertas vulnerabilidades críticas antes de que el fabricante esté preparado para explicarlas públicamente en detalle.
Eso traerá incertidumbre y decisiones difíciles.
También puede regalar algo que, frente a un zero-day activamente explotado, vale muchísimo más que un CVE perfectamente redactado: tiempo.