Un aviso privado desde los Países Bajos, luego el sobresalto público
La agencia neerlandesa de ciberseguridad NCSC-NL pidió a un pequeño grupo de operadores de NetScaler que apagaran sus equipos antes de que Citrix dijera nada en público. Así comenzó, el sábado 26 de septiembre de 2026, la tercera emergencia de NetScaler del trimestre, un día entero antes del propio boletín de seguridad de Citrix, el CTX697096.
El domingo, Citrix ya había confirmado la explotación activa de dos vulnerabilidades nuevas, CVE-2026-88771 y CVE-2026-88772, y publicó versiones corregidas. La agencia estadounidense CISA añadió ambas ese mismo día a su catálogo de vulnerabilidades explotadas activamente y dio a sus propias agencias federales hasta el martes 30 de septiembre para parchear cada equipo expuesto.
No es la primera emergencia de NetScaler de 2026. Es la tercera en noventa días.
Qué hacen realmente CVE-2026-88771 y CVE-2026-88772
CVE-2026-88771 es un fallo de validación de entradas que permite a un atacante sin ninguna credencial ejecutar comandos arbitrarios en el equipo, y el propio Citrix lo califica con 9,5 sobre 10 en la escala CVSS. Funciona ya en la configuración predeterminada, sin necesidad de activar antes ninguna función opcional.
CVE-2026-88772 es un desbordamiento de memoria que puede bloquear el equipo o darle a un atacante ejecución remota de código, pero solo en sistemas con DTLS activado, algo predeterminado en todo NetScaler Gateway usado como puerta de enlace VPN. Entre las dos fallas, casi cualquier patrón habitual de despliegue de NetScaler queda cubierto.
Investigadores de seguridad de watchTowr, autores del análisis técnico publicado, confirmaron que ambas fallas se explotaron como auténticos días cero: los atacantes ya tenían exploits funcionando antes de que existiera siquiera una versión corregida para instalar.
Noventa días, tres emergencias
| CVE | Conocida desde | Tipo de falla | Explotada antes del parche |
|---|---|---|---|
| CVE-2026-8451 (CitrixBleed 3) | 7 de julio de 2026 | Fuga de tokens de sesión vía el analizador de inicio SAML | Sí, en aproximadamente un día tras publicarse el parche |
| CVE-2026-8452 | Parcheada el 30 de junio, prueba de concepto pública en agosto | Ejecución remota de código sin credenciales | Sí, en cuanto la prueba de concepto se hizo pública |
| CVE-2026-88771 / CVE-2026-88772 | 27 de septiembre de 2026 | Ejecución de código / desbordamiento de memoria | Sí, como día cero genuino, antes de que existiera corrección alguna |
Citrix NetScaler ha necesitado ya tres ciclos de parcheo de emergencia distintos dentro de un mismo trimestre, y ninguno de los dos comparte la misma causa raíz.
Cada fila de esta tabla termina igual: los atacantes se movieron más rápido que la corrección. Un fabricante cuyo equipo insignia produce ese patrón tres veces seguidas no tiene mala suerte, mantiene una línea de producto bajo ataque activo sostenido.
Veintitrés mil equipos, dos avisos ya ignorados
El rastreo global de Shadowserver sigue contando unos 23.000 equipos NetScaler ADC y Gateway accesibles desde internet, unos 22.000 ADC y más de 1.500 Gateway.
Es, en gran medida, el mismo grupo al que CISA y Citrix pidieron parchear en julio y de nuevo en agosto. Una parte considerable no reaccionó a tiempo en ninguna de las dos ocasiones, y esa es la razón real por la que un tercer día cero golpea con tanta fuerza: la superficie expuesta nunca se redujo de verdad entre una emergencia y la siguiente.
Qué hacer si usted utiliza NetScaler
Parchee primero a las versiones corregidas: 14.1-73.37 o posterior, 13.1-64.23 o posterior, o la versión FIPS o NDcPP equivalente si las utiliza. El propio boletín de Citrix, el CTX697096, detalla los números de versión exactos para cada rama.
Si su equipo era accesible desde internet antes de parchearlo, trátelo como comprometido hasta demostrar lo contrario. La guía de CISA para este incidente es inusual para un aviso rutinario: capture los registros, una instantánea del sistema, un paquete de soporte y un volcado de memoria antes de aplicar la actualización, porque la propia actualización puede borrar justo la evidencia forense que necesitaría para saber si ya había sido vulnerado.
Después, hágase la pregunta más difícil que ya deberían haber planteado las dos emergencias anteriores: si un único equipo de perímetro merece seguir sin vigilancia entre su red e internet, o si necesita detrás un segundo control que no dependa de que Citrix entregue a tiempo una corrección.
Leer a continuación: La mayoría de los servidores Artifactory siguen expuestos | El fallo peor calificado de GitLab solo necesita un proyecto público
