Zero-days en Citrix NetScaler (CVE-2026-88771 y CVE-2026-88772): qué revisar antes y después de parchear

Por Felipe Traina · 28/9/2026 · 6 min · seguridad, vulnerabilidades, citrix, infraestructura

Dos vulnerabilidades críticas en Citrix NetScaler ADC y NetScaler Gateway permiten ejecución remota de código sin autenticación y ya se están explotando. Una de ellas, CVE-2026-88771, afecta a todas las implementaciones, incluso con la configuración por defecto. La otra, CVE-2026-88772, requiere DTLS habilitado, que viene activo por defecto en los servidores virtuales de VPN. Citrix publicó el boletín el 27 de septiembre de 2026 y ese mismo día CISA las agregó a su catálogo de vulnerabilidades explotadas conocidas (KEV).

Si tu empresa, o un cliente, expone un NetScaler a internet para VPN, balanceo o autenticación, esta es una de esas semanas en las que conviene cortar lo que se esté haciendo. Y hay un detalle que cambia el orden habitual de las cosas: antes de parchear, conviene buscar indicios de compromiso.

Qué se publicó

El boletín de Citrix (CTX697096) cubre ocho CVE. Las dos que importan con urgencia:

CVE Tipo Precondición CVSS v4.0
CVE-2026-88771 Ejecución remota de comandos sin autenticación, por validación de entrada incorrecta Todas las implementaciones (configuración por defecto) 9.5
CVE-2026-88772 Desbordamiento de memoria que puede llevar a ejecución remota o denegación de servicio DTLS habilitado (por defecto en VPN vServer) 9.5

Las otras seis (CVE-2026-88773 a CVE-2026-88778) incluyen HTTP request smuggling (9.3), un bypass de políticas, varios desbordamientos de memoria que pueden causar denegación de servicio y la predicción del número de secuencia inicial de TCP. Dependen de la configuración y de las funciones habilitadas.

Según Citrix: "Se observaron exploits de CVE-2026-88771 y CVE-2026-88772 en implementaciones de NetScaler sin mitigar".

Versiones corregidas

Las builds que corrigen las vulnerabilidades, según el boletín:

Para CVE-2026-88778 (predicción de ISN) la corrección es un cambio de configuración de TCP, documentado por NetScaler. BleepingComputer recuerda además que las versiones 12.1 y 13.0 llegaron a fin de vida y ya no reciben parches: si tenés equipos en esas ramas, la única salida es migrar.

El boletín aplica a NetScaler administrado por el cliente. Citrix indica que actualiza por su cuenta los servicios en la nube que administra.

El orden importa: evidencia antes que parche

CISA lo dice explícitamente en su alerta: si es posible, revisar indicios de compromiso antes de parchear, y si se sospecha un compromiso, preservar la evidencia forense, porque actualizar puede hacer perder visibilidad.

Citrix publicó indicadores de compromiso a través de NetScaler Console, pero advierte, según BleepingComputer, que son genéricos, que "podrían tener un valor forense limitado" y que pueden no detectar compromisos reales. Recomienda contar con investigadores forenses con experiencia. CERT-EU, por su parte, recomendó a las organizaciones europeas hacer una evaluación de compromiso en cualquier equipo expuesto a internet con una build afectada.

Cómo verificar si un equipo cumple las precondiciones

El boletín incluye instrucciones por CVE. Algunas útiles para un primer triage:

# En la CLI de NetScaler: versión instalada
show ns version

# CVE-2026-88772: ¿hay vservers de VPN sin DTLS deshabilitado explícitamente?
# Una línea así indica DTLS habilitado por defecto:
#   add vpn vserver vpn1 SSL 10.0.0.0 443 -Listenpolicy NONE
# Y así, deshabilitado:
#   add vpn vserver vpn1 SSL 10.0.0.0 443 -dtls OFF -Listenpolicy NONE
# (desde el shell del appliance, sobre el archivo de configuración)
grep -iE 'add vpn vserver|add (lb|cs) vserver .* DTLS' /nsconfig/ns.conf

# CVE-2026-88775: ¿el equipo funciona como Gateway o servidor AAA?
grep -iE 'add (vpn|authentication) vserver' /nsconfig/ns.conf

# CVE-2026-88778 (en la CLI de NetScaler): ¿está deshabilitada la generación mejorada de ISN?
show ns tcpparam | grep "Enhanced ISN Generation"

Recordá que para CVE-2026-88771 no hay precondición: si la build es vulnerable, el equipo es vulnerable.

Por qué esto es un problema de negocio, no solo de infraestructura

Algunos datos para dimensionar:

Los equipos de borde (VPN, gateways, balanceadores) son un blanco preferido porque dan acceso inicial a la red interna y suelen tener menos monitoreo que los servidores. Un equipo comprometido antes del parche sigue comprometido después.

Qué hacer con esto

Un plan de respuesta para las próximas 48 horas:

Para equipos de desarrollo, la conexión es directa: muchas aplicaciones internas quedan detrás de estos gateways, y un compromiso del borde expone todo lo que asumía que "la VPN protege".

¿Tu organización sabe cuánto tarda, de punta a punta, en parchear un equipo de borde crítico desde que sale el boletín?

Lecturas relacionadas

En video (Short de menos de 1 minuto): CISA ordena parchear Citrix NetScaler por zero-days

Fuentes

← Volver al blog