El boletín decía «denegación de servicio». El exploit da root: NetScaler CVE-2026-8452

Tres fechas y una sola de ellas es tuya. El 30 de junio Citrix publicó el parche de CVE-2026-8452 y lo describió como una denegación de servicio. El 14 de agosto, cuarenta y cinco días después, unos investigadores publicaron el análisis y el código que convierten ese mismo fallo en ejecución de código como root, sin credenciales. Los ataques empezaron poco después y el 26 de agosto CISA lo metió en su catálogo de vulnerabilidades explotadas con fecha límite del 29. Las dos primeras fechas las decidió otra gente. La tercera también. La única que controlas tú es cuánto tarda tu ventana de mantenimiento.

Esto no fue un día cero. El parche llevaba mes y medio publicado cuando empezaron los ataques. Quien lo tenía puesto no se enteró de nada; quien lo tenía en la lista de «lo miramos después de vacaciones» descubrió que el criterio con el que había ordenado esa lista lo escribió el boletín del fabricante.

Lo que decía la ficha, palabra por palabra

La descripción oficial, publicada el 30 de junio y todavía intacta, es esta: «Memory overflow vulnerability NetScaler ADC and NetScaler Gateway leading to unpredictable or erroneous behavior and Denial of Service if the appliance is configured as a Gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or AAA virtual server». Desbordamiento de memoria, comportamiento errático, denegación de servicio. Nada más.

Y sin embargo, en esa misma ficha, dos líneas más abajo, está el vector CVSS 4.0 que puntúa 8,8 con AV:N/AC:L/AT:N/PR:N/UI:N y, atención, VC:H. Vector de red, complejidad baja, cero privilegios, cero interacción del usuario y confidencialidad alta. Si el peor resultado posible fuera que el aparato se reinicia, la confidencialidad no tendría por qué salir alta. Estaba en la propia ficha, en el campo que casi nadie lee, mientras el resumen en prosa hablaba de otra cosa.

Ese 8,8 lo puso el propio fabricante, que actúa como CNA de sus vulnerabilidades. La puntuación primaria, la que firma el NIST, llegó mucho más tarde: CVSS 3.1 de 9,8, CRÍTICA, con confidencialidad, integridad y disponibilidad altas. El registro aparece como analizado y modificado por última vez el 27 de agosto: un día después de que CISA lo catalogara como explotado, y dos semanas después de que el código para explotarlo estuviera publicado. La etiqueta se corrigió cuando ya había webshells.

Qué hace de verdad: una lista de prefijos demasiado larga

El 14 de agosto, watchTowr publicó el desarme completo. El fallo está en el trozo de código que canonicaliza firmas SAML: al procesar el elemento <SignedInfo>, el aparato copia el contenido del atributo PrefixList a un búfer global de tamaño fijo «without checking whether it actually fits». Basta con meter dentro de InclusiveNamespaces una lista de prefijos larga —del tipo N0 N1 N2 … N1999— para pisar la cabecera del búfer contiguo.

A partir de ahí la cadena es de manual y por eso funciona tan bien: se sobrescribe el puntero a datos que hay en el desplazamiento +0x50 de esa cabecera, ese puntero lo usa después splitPktInner para hacer un memcpy, y con un memcpy cuyo origen y destino eliges tienes escritura arbitraria. Con eso se sobrescribe el puntero de función tx_pkt_complete_fptr y se salta al código propio. El código se ejecuta dentro de nsppe, el motor de paquetes, que corre como root. Los investigadores dejaron además el bit SUID puesto en /bin/sh para conservar el privilegio a través de la webshell.

Los 45 días que tuviste

Entre el parche y el exploit público pasaron cuarenta y cinco días. Ese hueco es lo más parecido a un regalo que hay en este oficio: el arreglo ya existía, el mapa para explotarlo no. Y se desperdicia siempre por la misma razón, que no es la pereza.

Actualizar el aparato que termina las VPN significa, en la práctica, echar a todo el mundo. Los comerciales pierden la sesión, el ERP publicado se corta, el turno de noche se queda fuera. Por eso el equipo del borde es el último de la cola de parcheo: es justo el que no puedes reiniciar a las once de la mañana de un martes. Y por eso, cuando además el boletín dice «denegación de servicio», la conversación se acaba antes de empezar: nadie monta una ventana nocturna, avisa a los usuarios y firma un cambio para prevenir un reinicio.

La corrección no es «parchead más rápido», que es un consejo vacío. Es aceptar que la etiqueta de gravedad del fabricante puntúa el fallo, no puntúa tu exposición. Un aparato que mira a internet, termina sesiones y valida identidades no puede compartir cola con el servidor de ficheros interno, se llame la etiqueta como se llame. Ese equipo merece su propia regla, con la ventana pactada por adelantado y con hora escrita, para que el día del aviso la discusión sea técnica y no de calendario.

Cómo saber si estás parcheado sin tumbar el aparato

Lo primero es lo aburrido: las versiones con el arreglo son 14.1-72.61, 13.1-63.18 y 13.1-37.272 para las variantes FIPS y NDcPP. Si estás en 12.1 o en 13.0 no hay parche que aplicar: Citrix no lo va a publicar para esas ramas, y lo tuyo no es una tarea de parcheo sino una migración de plataforma que ya llegas tarde a planificar.

Lo interesante es cómo confirmarlo desde fuera sin lanzar el exploit contra tu propia producción, que es lo que nadie quiere hacer un jueves por la tarde. Bishop Fox publicó un comprobador que usa el tamaño como oráculo: se manda una petición SAML con un PrefixList de 513 bytes o más y se mira la respuesta. «A patched build turns the request away at a size check before it reaches the rewrite step, while an unpatched build carries on and eventually returns a generic internal error». En la práctica: un aparato sin parchear devuelve 500 Internal Server Error 43549; uno parcheado devuelve 200 Malformed Assertion sent to Netscaler. Como control se repite la prueba con una lista corta, de 35 bytes, muy por debajo de cualquier comprobación de tamaño, para asegurarse de que el endpoint está validando de verdad y no contestando cualquier cosa.

Con dos pegas que conviene decir en voz alta. La primera: hay que apuntar al servidor virtual donde vive la política, y probar cada VIP —«Aim at the virtual server where the policy actually lives, and test each VIP»—, porque el inventario de VIPs de un NetScaler mediano rara vez cabe en la cabeza de nadie. La segunda, más importante: esto te dice si el arreglo está puesto, no te dice si entraron antes de ponerlo. Son dos preguntas distintas y la segunda es la que duele.

El parche cierra la puerta; no echa a quien ya está dentro

Que un parche no expulsa al que ya entró lo lleva diciendo medio sector desde que hubo webshells. Lo que no hemos visto en ningún sitio es la contradicción que sale de poner dos textos oficiales uno al lado del otro. La guía de remediación del fabricante para esta CVE dice que «the remediation is a single-step process and you need to upgrade the vulnerable NetScaler instances to a release and build that has the fix». Un paso: actualizar. No menciona sesiones, ni credenciales, ni revisar si el aparato ya estaba tocado.

La entrada de CISA pide otra cosa. En el campo de acción requerida, además de aplicar las mitigaciones del fabricante, exige cumplir la directiva BOD 26-04 y los «Forensics Triage Requirements», y añade que cada organización es responsable de «evaluating each asset's internet exposure». Traducido: el organismo que obliga a parchear da por hecho que parchear no es suficiente, y pide triaje forense en el mismo párrafo. Mientras tanto, la descripción de esa misma entrada del catálogo sigue diciendo, a día de hoy, «which could lead to denial of service».

Si tu aparato estuvo expuesto con SAML activo y sin parchear después del 14 de agosto, la actualización es el primer punto de una lista de cuatro. Lo que se mira, en este orden:

• Ficheros que no pusiste tú. Previdian lo contó el mismo día que empezó, con un «This morning we started seeing exploitation for CVE-2026-8452» y tres IPs de tres países distintos: dejaban webshells con nombres tan discretos como x.php y z.php, y ejecutaban comandos de reconocimiento del tipo id y echo.
• Binarios con SUID. La cadena publicada deja el bit puesto en /bin/sh. Un /bin/sh con SUID en un appliance es una respuesta, no una pregunta.
• Todo lo que el aparato sabe. Un NetScaler guarda credenciales de servicio: el bind contra el directorio, certificados, secretos de las políticas. Con root dentro, eso ya no es tuyo en exclusiva. Rotarlo es lo único de esta lista que no admite «la semana que viene».
• Las sesiones vivas. Un token de sesión emitido antes del parche sigue valiendo después del parche. Es el mismo error de razonamiento que ya contamos cuando alguien apagó el EDR con un reinicio: se arregla el mecanismo y se deja intacto el estado que el atacante ya se llevó.

Cuándo esto no es tu problema

Sin NetScaler, esto no va contigo, y no hace falta que nadie te venda urgencia por una marca que no tienes. Con NetScaler pero sin SAML configurado como SP o IdP, la cadena publicada no te alcanza —aunque el aviso del fabricante habla también de configuraciones de Gateway y de servidor virtual AAA, así que el criterio prudente es parchear igual y no discutir el matiz con quien te está escaneando—. Y si el aparato no publica nada a internet, tienes tiempo de sobra: ponle fecha en el calendario del próximo mantenimiento y olvídate hasta entonces.

Sobre el tamaño del asunto conviene ser igual de honesto. Las cifras de Shadowserver —más de 22.000 NetScaler ADC y cerca de 1.800 Gateway asomados a internet— ya las miramos hace seis días, cuando escribimos que en NetScaler tu versión no te dice si estás expuesto, y el matiz sigue siendo el mismo: miden superficie. El recuento de comprometidos no lo tiene nadie, porque ahí dentro hay señuelos, aparatos ya parcheados y configuraciones que jamás exponen la ruta vulnerable. Lo que ha cambiado en estos seis días es que ahora el código para entrar está publicado.

Sí, otra vez la misma conclusión

No vamos a fingir que esto es un hallazgo nuevo, ni siquiera para nosotros. Ayer escribimos que el fallo de Gitea «requiere permiso de escritura» y que ese permiso lo regala el formulario de registro; anteayer, que tu proveedor de identidad no es una aplicación, es infraestructura. Tres posts en una semana con la misma cosa debajo: la ficha describe el fallo y la instalación la tienes que describir tú. Cuando algo se repite así deja de ser una noticia y pasa a ser una propiedad del sistema; la propiedad, aquí, es que el orden de tu cola de parcheo lo está escribiendo el departamento de marketing técnico de otra empresa. Y la descripción de esta CVE sigue igual dos meses después, con los ataques ya documentados.

Qué hacemos nosotros con esto

No vendemos licencias de Citrix ni de nadie: diseñamos, desplegamos y mantenemos infraestructura, y por eso lo que sigue no es una recomendación de producto. Nuestro trabajo con un aviso así es aburrido y no tiene truco. Empieza por saber qué responde de verdad desde fuera —para eso mantenemos la red documentada en NetBox, que es la fuente de verdad y no la hoja de compras—, sigue por tratar el equipo del borde como un caso aparte cuando toca decidir a qué hora se puede reiniciar, y acaba, si el aparato estuvo expuesto, en credenciales y en sesiones.

Es lo que hay detrás de nuestro servicio de ciberseguridad y del EDR/MDR gestionado: no una consola bonita, sino alguien que sabe qué equipos tuyos miran a internet y que, cuando sale un aviso, ya tiene decidido de antemano a qué hora se puede reiniciar cada uno. Si no tienes esa lista, empieza por ahí; y si la tienes pero nadie la mira los sábados, para eso está el soporte 24×7.

Fuentes (verificadas una a una): descripción oficial de la vulnerabilidad, fecha de publicación (30 de junio de 2026), vector CVSS 4.0 de 8,8 del fabricante como CNA con PR:N y VC:H, puntuación primaria del NIST de 9,8 CRÍTICA en CVSS 3.1 y estado del registro (analizado, última modificación el 27 de agosto de 2026) — NVD, CVE-2026-8452; fecha de inclusión en el catálogo (26 de agosto), plazo del 29 de agosto, texto de la acción requerida con BOD 26-04 y los «Forensics Triage Requirements» — CISA KEV; análisis técnico, condición de SAML como SP o IdP, ejecución como root en nsppe y SUID en /bin/sh — watchTowr Labs, 14 de agosto de 2026; método de comprobación por tamaño (513 bytes, error 43549 frente a «Malformed Assertion»), prueba por VIP y ausencia de parche para 12.1 y 13.0 — Bishop Fox; remediación «de un solo paso» del fabricante — documentación de NetScaler Console; webshells x.php y z.php, comandos de reconocimiento y confirmación de explotación por Defused y Previdian — Help Net Security; recuento de aparatos expuestos según Shadowserver — BleepingComputer. Todo consultado el 28 de agosto de 2026. Los 45 días entre parche y exploit público son una resta nuestra sobre esas fechas. No probamos el comprobador de Bishop Fox contra equipos ajenos ni te recomendamos hacerlo: se lanza contra los tuyos y con permiso por escrito.