7 de septiembre de 2026 · Security-Advisory · Perimeter · Schwachstellenmanagement · IT-Sicherheit

NetScaler ADC y Gateway: el BSI informa de explotación activa

Dos vulnerabilidades en NetScaler ADC y Gateway, entre ellas un bypass de autenticación; el BSI informa de explotación activa. Quién está afectado y qué builds ayudan.

El 19 de agosto de 2026, Cloud Software Group, el fabricante de NetScaler, publicó un Security Bulletin sobre dos vulnerabilidades en NetScaler ADC y NetScaler Gateway. El CERT-Bund del BSI actualizó su aviso al respecto el 7 de septiembre, con la anotación «Explotación activa notificada». Con ello, una actualización que podía esperar a la siguiente ventana de mantenimiento se ha convertido en una que hay que instalar ahora.

El fabricante no menciona ninguna solución alternativa. Queda la actualización, y la pregunta de qué ha ocurrido ya antes.

Las dos vulnerabilidades

CVE-2026-19490 es un bypass de autenticación a través de una ruta alternativa (CWE-288), valorado con CVSS 9.3 (versión 4.0). El CERT-Bund clasifica el aviso en su conjunto como «crítico». Un atacante no necesita para ello ni credenciales ni la colaboración de un usuario; según el vector CVSS, la vulnerabilidad es explotable desde la red sin inicio de sesión previo. El BSI anota la explotación activa para el aviso en su conjunto, sin atribuirla a ninguna de las dos vulnerabilidades.

CVE-2026-19489 es un desbordamiento de memoria (CWE-119) con CVSS 8.8, que puede provocar un comportamiento imprevisible o una denegación de servicio. Presupone una configuración más bien especial: SIP ALG debe estar activado en un grupo de Large-Scale-NAT. Para la mayoría de las instalaciones que usan NetScaler como pasarela de acceso remoto, es la menos urgente de las dos vulnerabilidades; aun así conviene cerrarla, tanto más cuanto que se corrige con la misma actualización.

Quién está afectado

Están afectadas las instalaciones operadas por el cliente en estas versiones:

  • NetScaler ADC y NetScaler Gateway 14.1 anteriores a 14.1-73.32
  • NetScaler ADC y NetScaler Gateway 13.1 anteriores a 13.1-63.21
  • NetScaler ADC FIPS anteriores a 14.1-73.32 FIPS
  • NetScaler ADC FIPS y NDcPP anteriores a 13.1-37.277

Los propios builds 14.1-73.32 y 13.1-63.21 ya están, por tanto, corregidos. No es una sutileza: el registro CVE oficial indica las versiones con «through», el boletín del fabricante con «before». Lo determinante es el boletín.

También están afectadas las instancias de NetScaler en entornos híbridos de Secure Private Access. Los servicios en la nube operados por la propia Citrix, en cambio, los actualiza el propio fabricante.

Para CVE-2026-19490 es decisivo el papel del appliance. La vulnerabilidad solo aplica si está configurado como Gateway (SSL-VPN, ICA Proxy, CVPN, RDP Proxy) o como AAA Virtual Server. En builds más recientes la condición es más estrecha: a partir de 14.1-43.56, de 14.1-66.68-FIPS y de 13.1-61.28, la vulnerabilidad solo es explotable si además hay configurada una SAML-Action. En builds más antiguos y en 13.1 FIPS basta con la configuración de Gateway o AAA por sí sola.

El fabricante indica las líneas de configuración en las que se reconoce: add authentication samlAction para la SAML-Action, add authentication vserver o add vpn vserver para el papel de Gateway y AAA. Para CVE-2026-19489 es add lsn group con sipalg. Un vistazo a la configuración en ejecución responde, por tanto, a la pregunta con más fiabilidad que el recuerdo de para qué se compró el equipo en su día.

Una indicación para priorizar: una NetScaler que no está configurada ni como Gateway ni como AAA Virtual Server no cumple, según el fabricante, los requisitos para CVE-2026-19490. Si, en cambio, sirve como pasarela de acceso remoto, está exactamente en el papel que importa.

Qué hacer ahora

  • Instalar la actualización sin esperar a la siguiente ventana de mantenimiento. El fabricante pide a los clientes afectados que instalen las versiones corregidas «lo antes posible» y declara expresamente que no hay ninguna solución alternativa. Desde la actualización del aviso del BSI consideramos obligada una actualización inmediata.
  • Determinar el build exacto, no la rama de versión. «Estamos en 14.1» no responde a la pregunta. La diferencia está en el número de build detrás del guion.
  • Registrar todas las instancias, no solo la conocida. Forman parte de ellas los pares de alta disponibilidad, los sistemas de prueba con conexión al exterior y las instancias en entornos híbridos. Basta con un segundo nodo sin parchear.
  • Partir de un posible compromiso anterior a la actualización. La vulnerabilidad era públicamente conocida desde el 19 de agosto. La actualización la cierra, pero no deshace lo que pueda haber ocurrido entretanto. Revise los registros, los cambios de configuración y las cuentas creadas en busca de anomalías.
  • Cerrar sesiones y renovar credenciales. El boletín no lo exige; nosotros lo recomendamos de todos modos. Un bypass de autenticación proporciona sesiones, y una sesión ya establecida no termina porque el equipo se actualice. Tras la actualización, cierre las sesiones existentes y renueve las credenciales que puedan haber pasado por la pasarela, también las de cuentas de servicio con las que el appliance se comunica con servicios de directorio o proveedores de identidad.
  • Aclarar la situación de notificación. Si su empresa está sujeta a NIS-2 y una sospecha se confirma, con el conocimiento comienza un plazo.

Si por motivos operativos la actualización no es posible de inmediato, solo queda reducir la ventana de tiempo: desactivar las funciones de Gateway y AAA que no se necesiten, limitar el acceso a las interfaces de administración a redes de origen conocidas y vigilar de cerca los inicios de sesión en la pasarela. Esto, expresamente, no es una solución alternativa en el sentido del fabricante: una pasarela que ofrece acceso remoto no puede separarse razonablemente de internet sin renunciar a su finalidad. Planifique, por tanto, la actualización en paralelo a tales medidas, no después, y documente desde cuándo qué instancia funcionaba con qué build. Esos momentos los necesitará más adelante, cuando revise los registros en busca de anomalías.

Por qué siempre les toca a los equipos perimetrales

El BSI describe el patrón en el informe de situación de 2025, en el apartado «Vulnerabilidades en sistemas perimetrales»: los firewalls y las pasarelas VPN de distintos fabricantes volvieron a ser objetivo de ataques, y el intervalo entre la disponibilidad de un parche y su explotación se ha vuelto «cada vez más corto en los últimos años». En el caso presente, entre el boletín y la anotación del BSI sobre la explotación activa transcurrieron casi tres semanas.

La razón es la posición de estos equipos. Una pasarela está por definición en internet, recibe inicios de sesión y, por el otro lado, tiene acceso a la red interna. Quien elude la autenticación no está ante la puerta, sino en el pasillo. Al mismo tiempo, en un appliance cerrado no corre por regla general ninguna detección de endpoint que informe de comportamientos sospechosos: la visibilidad es mínima justo donde la exposición es máxima.

De ahí se desprende la frase que el BSI formula en el mismo informe de situación: «En caso de explotación de vulnerabilidades, parchear por sí solo no suele bastar para volver a operar los equipos con seguridad». Los accesos establecidos por los atacantes podrían seguir usándose meses o años después si el malware instalado no se elimina y las credenciales no se cambian. El BSI recomienda mantener mínima la superficie de ataque, desactivar las funciones del producto que no se necesiten y limitar los accesos de administración a fuentes de confianza.

Para la operación esto significa tres cosas. Los equipos perimetrales deben figurar en el inventario con su build y una persona responsable. Sus registros deben ir a un sistema central antes de que se sobrescriban en el equipo. Y tras una vulnerabilidad como esta, la pregunta no es «¿está parcheado?», sino «¿qué fue posible entre la divulgación y el parche, y cómo lo descartamos?».

Cómo apoya sector7

Revisamos la superficie de ataque accesible desde fuera mediante escaneos de vulnerabilidades periódicos y conducimos las vulnerabilidades encontradas, a través de la gestión de parches, a una corrección priorizada. En los entornos que atendemos operamos firewalls y accesos VPN en el marco de nuestros servicios gestionados y le apoyamos, en caso de incidente, en el análisis de eventos de seguridad. Más información en Ciberseguridad.

Fuentes

Hablemos de su situación.

Concertar una conversación+49 212 240915 0