NetScaler Gateway: cómo blindar el acceso tras el parche

Qué pasó: dos zero-days con CVSS 9.5 en el borde de tu red

El 27 de septiembre de 2026 Citrix publicó el boletín de seguridad CTX697096, que cubre ocho vulnerabilidades en NetScaler ADC y NetScaler Gateway. Dos de ellas, CVE-2026-88771 y CVE-2026-88772, ya estaban siendo explotadas como zero-day y tienen un CVSS de 9.5, el máximo de la escala v4, según reportó DQ India.

La primera es la más incómoda para cualquier equipo de infraestructura: permite a un atacante no autenticado ejecutar comandos arbitrarios de forma remota y no requiere ninguna configuración no estándar para funcionar. Es decir, el despliegue por defecto ya es vulnerable. La segunda es un desbordamiento de memoria asociado a DTLS, que viene habilitado por defecto en los servidores virtuales de VPN.

CISA incluyó ambas en su catálogo de vulnerabilidades explotadas (KEV) y Cloudflare publicó una regla de WAF de emergencia el 1 de octubre, según detalla el propio análisis de Cloudflare que origina esta nota. Para un founder con producto en producción, la lectura corta es esta: si tu equipo accede a escritorios remotos o consolas internas a través de una página de login publicada en internet, el parche es solo la mitad del trabajo.

Por qué el problema no es NetScaler, sino cualquier login expuesto

La vulnerabilidad no existe porque Citrix hiciera algo raro. Existe porque el Gateway tiene que ser accesible desde internet: si no lo fuera, los usuarios no podrían iniciar su sesión de escritorio remoto. Ese requisito de arquitectura es el que convierte una página de autenticación en una superficie de ataque.

En un despliegue típico de Citrix, el usuario se autentica contra el NetScaler Gateway, que usa una autoridad de tickets segura para pasar a StoreFront, que presenta las aplicaciones y escritorios disponibles. La app nativa de Citrix establece después una conexión aparte con el protocolo ICA, y el gateway valida el ticket antes de hacer de proxy. Todo ese flujo depende de que la primera puerta esté abierta al mundo.

La pregunta que Cloudflare propone hacerse aplica mucho más allá de Citrix: ¿la audiencia de este servicio realmente necesita alcance irrestricto desde internet? Portales de escritorio remoto, consolas de administración y cualquier página de autenticación pública merecen el mismo escrutinio. Si la respuesta es que no, tienes una decisión de diseño pendiente.

El parche llegó, pero el reloj ya había corrido

Los números del escaneo son el dato más duro de esta historia. Censys detectaba alrededor de 42.000 hosts con NetScaler ADC o Gateway expuestos a internet, aunque la firma aclara que no puede ver si están vulnerables o ya comprometidos. La distribución geográfica que reportó Help Net Security: 13.549 hosts en Estados Unidos (32%), 5.678 en Alemania (13%) y Países Bajos, Reino Unido y Suiza con cerca del 4% cada uno. Microsoft aloja 4.254 (10%) y Amazon 3.013 (7%), consistente con appliances virtuales desplegados en nube pública.

Más preocupante todavía: el investigador Kevin Beaumont estimó que menos del 10% de los hosts expuestos estaba parcheado, y dijo estar siguiendo más de 100 organizaciones víctimas, cada una con un webshell único. Y la explotación no empezó con la divulgación: GreyNoise detectó un intento de explotación contra un NetScaler Gateway el 24 de septiembre, tres días antes del aviso público, según Help Net Security.

Después de que watchTowr Labs publicara un proof-of-concept, la campaña pasó de objetivos selectivos a "spray and pray": escaneo masivo de internet buscando appliances sin actualizar. Si corres NetScaler y no has parcheado, la recomendación textual de un investigador citado por Help Net Security es asumir que ya te están sondeando.

La segunda ola: CVE-2026-88779 y el re-parcheo

Como si un ciclo de emergencia no bastara, llegó otro. CVE-2026-88779 es un desbordamiento de memoria que afecta a NetScaler ADC y Gateway configurados con autenticación SAML junto con funcionalidad Gateway o AAA, con un CVSS de 8.7 y explotación observada en ataques dirigidos, según BleepingComputer.

El detalle que importa es que obligó a volver a parchear a quien ya había parcheado: Citrix liberó 14.1-73.41 y 13.1-64.28 para taparlo, y advirtió explícitamente que quienes habían aplicado las versiones del boletín anterior y cumplían las precondiciones de SAML debían actualizar otra vez. CISA lo sumó a su catálogo KEV y dio a las agencias federales civiles de Estados Unidos hasta el 7 de octubre para mitigarlo.

Hay un matiz técnico que conviene registrar: aunque Citrix lo describe como denegación de servicio, administradores reportaron reinicios inesperados de appliances ya parcheados y Beaumont encontró un binario malicioso descargado en uno de sus honeypots. El propio investigador recordó que CVE-2025-6543 fue caracterizado al principio como DoS antes de que los ataques mostraran que permitía ejecución remota de código, según BleepingComputer. El antecedente histórico es conocido: CVE-2019-19781 permitía ejecución de código sin autenticar en los mismos appliances y fue ampliamente explotada, según recoge The Tech Edvocate.

Cómo se ve una defensa en profundidad, en concreto

La tesis del análisis de Cloudflare es que un WAF es reactivo: cubre la firma del exploit que ya se descubrió, pero no el siguiente. La propuesta es poner tres controles independientes delante del servicio de autenticación.

• Control de acceso antes de la autenticación. La idea es que la petición nunca llegue al servidor de login sin pasar antes por una política de acceso propio (en el caso de Cloudflare, Access). El entorno Citrix sigue decidiendo qué escritorio se lanza y validando el ticket, pero un atacante que no pasa la primera puerta nunca llega a ver el Gateway. La decisión deja de depender de reconocer una firma de exploit.
• Inspección del tráfico web. El WAF corre antes de las comprobaciones de acceso, lo que permite bloquear IPs maliciosas conocidas, países, ASNs o cualquier atributo que sepas que no debería estar ahí. Además de firmas de CVE, un modelo de scoring puede identificar peticiones anómalas que no coinciden con ninguna regla conocida.
• Restricción de la conexión al origen. Cambiar un registro DNS y aplicar políticas de acceso no alcanza: si el atacante puede llegar por la IP directa o por un hostname alternativo, las políticas se vuelven inútiles. Las opciones son un túnel de salida que cierre todo el tráfico entrante, direcciones de egreso dedicadas que la firewall del servidor permita explícitamente, o TLS mutuo para verificar la conexión hasta el origen.

¿Qué significa esto para tu startup?

Si tienes menos de 50 empleados, no vas a montar la arquitectura completa mañana. Pero sí puedes hacer estas cuatro cosas esta semana.

• Haz el inventario de lo que está público. Lista cada página de login, portal de escritorio remoto, consola de administración y webhook que hoy responde en una IP pública. La pregunta por cada uno: ¿realmente necesita ser alcanzable desde cualquier lugar, o solo desde las redes de tu equipo? Este ejercicio, hecho en una hoja de cálculo, ya reduce riesgo.
• Mueve la decisión de acceso delante del servicio de autenticación. La regla es simple: nada debería llegar a la pantalla de login si antes no pasó por un control que tú definas. Ese control puede ser un proxy de acceso con políticas, o al menos una lista de permitidos a nivel de firewall.
• Cierra el camino alternativo. Verifica que no se pueda llegar al servidor por su IP original. Si el proveedor de acceso aplica políticas por hostname, una IP expuesta anula todo el trabajo.
• Antes de parchear, preserva evidencia. Si sospechas compromiso, guarda logs y una captura de memoria antes de reiniciar o actualizar. NCSC-NL recomendó explícitamente hacerlo así, y tiene sentido: una vez que reinicias, la evidencia suele desaparecer. Ojo también con tratar un escaneo de indicadores limpio como prueba de que no hubo intrusión: los propios indicadores de Citrix no cubren todas las técnicas posibles.

Cómo validar que el cierre funcionó

Configurar no es validar. Estas cuatro pruebas tomaron cinco minutos y detectan la mayoría de los errores de configuración:

1. Pide el hostname protegido sin iniciar sesión. La petición debe detenerse antes de llegar al origen, no responder con la pantalla de login original.
2. Entra con una cuenta de prueba fuera del grupo permitido. Debe seguir bloqueada.
3. Prueba la IP directa y los hostnames alternativos. Ninguno debería saltarse la política.
4. Entra como usuario aprobado. Confirma que la autenticación, el lanzamiento del escritorio y la reconexión de sesión siguen funcionando.

Y revisa los logs de política, firewall y origen en lugar de confiar en lo que muestra el navegador. Repite las pruebas cuando cambien el ruteo, la identidad o el failover: el siguiente ajuste de configuración puede reabrir silenciosamente el camino que acababas de cerrar.

Conclusión

La lección para founders no es "Citrix es inseguro". Es que una página de login pública es una decisión de arquitectura, no un default heredado. Los 42.000 hosts expuestos que cuenta Censys y el estimado de menos del 10% parcheado son el síntoma: parchear es urgente, pero es un ciclo que se repite cada pocos meses.

Lo que cambia el resultado es mover la decisión de acceso por delante de la superficie de autenticación, cerrar los caminos alternativos al origen y validar los controles con pruebas reales. Hazlo con un servicio, el más crítico, y luego expande. La próxima vulnerabilidad no avisa, y no quieres descubrir en ese momento que tu única defensa era la esperanza de que nadie te encontrara.

Fuentes

• Beyond the patch: Protecting your NetScaler gateway against future vulnerabilities (fuente original)

• Citrix NetScaler Zero-Day exploitation: What enterprise teams need to know - DQ India

• NetScaler zero-day exploitation escalates into mass attacks (CVE-2026-88771) - Help Net Security

• Citrix patches NetScaler SAML zero-day exploited in attacks - BleepingComputer

• CISA flags new exploited NetScaler flaw as attackers crash appliances (CVE-2026-88779) - Help Net Security