Parchear NetScaler no expulsa al intruso que entró por CVE-2026-88771 y CVE-2026-88772

Un NetScaler puede estar hoy corregido y comprometido a la vez. Quienes explotaron CVE-2026-88771 y CVE-2026-88772 antes de que hubiera parche dejaron instaladas web shells (scripts que aceptan órdenes por HTTP), y la actualización no está pensada para retirarlas. Unit 42 advierte de que actualizar «no retirará el acceso a los atacantes que ya hayan logrado persistencia».

El domingo 27 de septiembre de 2026 Citrix publicó el boletín CTX697096 con ocho vulnerabilidades en NetScaler ADC y NetScaler Gateway. Dos de ellas tienen una puntuación CVSS v4 de 9,5 y ya se explotaban como día cero cuando llegó la corrección. CISA las incorporó ese mismo día a su catálogo KEV de vulnerabilidades explotadas y dio a las agencias federales hasta el 30 de septiembre para corregirlas, según Computer Weekly.

¿Qué permiten CVE-2026-88771 y CVE-2026-88772?

Son dos fallos distintos con el mismo resultado: ejecución de código en el dispositivo sin credenciales. Rapid7 describe CVE-2026-88771 como una validación incorrecta de la entrada presente en la configuración predeterminada, y CVE-2026-88772 como un desbordamiento de memoria que requiere DTLS, el protocolo que cifra el tráfico UDP de la VPN. SecurityWeek precisa que DTLS viene activado por defecto en los servidores virtuales de VPN, lo que hace suponer que la condición se cumple en muchos Gateway expuestos.

Google Threat Intelligence Group (GTIG) explica en su análisis el mecanismo del segundo fallo. Unas cabeceras DTLS malformadas, enviadas durante la negociación previa a la autenticación, corrompen la memoria del proceso y el atacante termina ejecutando código como root sobre el sistema FreeBSD del NetScaler, sin que intervenga ningún usuario.

Están afectadas las versiones 14.1 anteriores a 14.1-73.37 y las 13.1 anteriores a 13.1-64.23, además de las compilaciones FIPS y NDcPP previas a 13.1-37.279. El boletín cubre los equipos gestionados por el cliente. Los servicios en la nube los actualiza Citrix por su cuenta.

La explotación empezó más de tres semanas antes del boletín

La fecha de inicio depende de quién mire y con qué telemetría. Puestas en orden, las observaciones publicadas describen un reconocimiento que empezó a finales de agosto y una explotación confirmada desde el 3 de septiembre, más de tres semanas antes del boletín.

• 21 y 22 de agosto: Unit 42 detecta que varias direcciones IP sondean la versión de equipos NetScaler.
• 3 de septiembre: fecha más temprana de actividad que GTIG da por confirmada, según Cybersecurity Dive.
• Del 4 al 24 de septiembre: campaña de explotación por DTLS que instala web shells desde una infraestructura que cambia a diario, de acuerdo con Unit 42.
• 20 de septiembre: primeros intentos de explotación en la telemetría de Rapid7, que el día 24 observa el despliegue de una web shell.
• 21 de septiembre: Unit 42 observa que CVE-2026-88771 se usa contra objetivos en Estados Unidos.
• 24 de septiembre: GreyNoise registra su primer intento, según BleepingComputer.
• 26 de septiembre: watchTowr habla en X de rumores sobre un fallo sin corregir y varios administradores cuentan que han desconectado sus equipos.
• 27 de septiembre: boletín de Citrix, versiones corregidas y entrada en el catálogo KEV.

Ese mismo fin de semana, antes de que saliera el boletín, el centro de ciberseguridad neerlandés (NCSC-NL) envió una notificación previa bajo TLP:AMBER tras recibir la información de un CERT europeo. Proveedores y equipos de respuesta llamaron a sus clientes para pedirles que apagaran los NetScaler sin poder explicar el motivo, como relatan SecurityWeek y BleepingComputer. Quien atendió el teléfono tuvo que decidir si cortaba su acceso remoto sin más prueba que esa conversación.

¿Por qué el parche no retira la puerta trasera?

La actualización corrige el código vulnerable, pero no es una limpieza. No garantiza que desaparezcan la configuración de Apache alterada, los ficheros añadidos ni los permisos cambiados.

Según el análisis de GTIG, la carga inicial modifica /etc/httpd.conf, la configuración del servidor Apache que atiende el portal, para que interprete como PHP ficheros con extensiones que no suelen revisarse: .deb, .sig o rutas con apariencia de hoja de estilos. La web shell se guarda en los directorios donde el equipo almacena los instaladores del cliente VPN y se sirve como si fuera uno más.

El mismo informe documenta dos familias de código malicioso. WHIPSHOT es una web shell en PHP que recibe las órdenes ocultas en cabeceras HTTP y contesta con un error 404 cuyo cuerpo lleva la respuesta real. SLAPSHOT es un túnel en Python que reenvía tráfico TCP hacia la red interna y se cierra solo tras diez minutos sin sesiones.

Para asegurarse la persistencia, el atacante activa el bit setuid en /bin/sh, un permiso que hace que el intérprete de órdenes se ejecute con los privilegios de root, su propietario, lo invoque quien lo invoque. Después borra el rastro: el implante elimina de los registros y de /etc/crontab las líneas que mencionan la ruta de sus ficheros.

Charles Carmakal, director técnico de Mandiant Consulting, añade un problema distinto en una declaración que publica Cybersecurity Dive: las credenciales robadas siguen siendo válidas después de actualizar.

¿Cuántos equipos están expuestos y cuáles hay que revisar?

Unit 42 contaba 50.277 equipos NetScaler visibles desde internet a 27 de septiembre. La Shadowserver Foundation habla de más de 20.000 expuestos y posiblemente vulnerables, según Cybersecurity Dive. La primera cifra cuenta todo lo que se ve y la segunda lo que parece vulnerable, así que no se suman.

En cuanto a organizaciones afectadas, el mismo medio atribuye a Arctic Wolf un recuento de al menos 78 organizaciones con actividad de explotación en Estados Unidos, Canadá y Europa. GTIG y Mandiant hablan de decenas, repartidas entre administración pública, servicios financieros, tecnología, educación y servicios jurídicos y profesionales. La autoría no está establecida: se sospecha de un actor vinculado a un Estado, que por ahora no se ha asociado a ningún grupo conocido.

Nuestra recomendación es tratar como posiblemente comprometido todo NetScaler que haya estado expuesto a internet con una versión afectada desde finales de agosto, hasta que una revisión lo descarte. Haber actualizado el mismo domingo reduce el riesgo, pero no lo elimina, porque la campaña dirigida es anterior al boletín.

The Hacker News recuerda que la rama 13.1 pasó a fin de mantenimiento el 15 de septiembre y que, aun así, Citrix ha publicado corrección para ella. Quien siga en 13.1 dispone de parche, y tiene además un motivo para planificar el salto a 14.1.

¿Cómo comprobar si un NetScaler está comprometido?

El NCSC británico pide aislar los sistemas afectados y conservar las pruebas forenses antes de parchear, de acuerdo con Computer Weekly. Una actualización o un reinicio pueden destruir las pruebas volátiles (procesos en ejecución, ficheros en /tmp, registros), así que lo primero es guardar una copia de la configuración y de los registros y, si es una máquina virtual, una instantánea del disco.

GTIG ha publicado órdenes de comprobación y reglas YARA, y Rapid7 y BleepingComputer añaden indicadores de compromiso propios. Las señales que se repiten son estas:

• Directivas AddHandler, AliasMatch o php_flag en /etc/httpd.conf que asocien a PHP extensiones distintas de .php.
• Ficheros .deb o .sig que resulten ser texto, y ficheros .php ajenos a la instalación, en /var/netscaler/gui/vpn/scripts/linux/ y directorios equivalentes. Un paquete de instalación auténtico es binario.
• El intérprete /bin/sh con el bit setuid, visible como -rwsr-xr-x al listar sus permisos.
• Los ficheros /tmp/.uxdport y /tmp/.uxdlock, o procesos de Python que los mencionen.
• Respuestas 404 de varios kilobytes a peticiones bajo /vpn/media/ o /vpn/scripts/ en los registros de acceso.
• Fallos de negociación DTLSv1.0 con el motivo «Handshake failure-Internal Error» y caídas del proceso NSPPE que el sistema no reinicia.
• Un fichero oculto llamado .ctxs.receiver en /var/netscaler/logon/LogonPoint/custom/.

El atacante borra líneas de los registros y los registros rotan, de modo que un resultado limpio obtenido en el NetScaler vale poco sin una copia externa con la que contrastarlo. Es uno de los motivos para enviar los registros del perímetro a un SIEM, y también la razón por la que los dispositivos de red son un punto ciego para el EDR: no admiten agente y hay que vigilarlos desde fuera.

La revisión tampoco termina en el NetScaler. Carmakal ha señalado que en algunas organizaciones hubo movimiento lateral hacia otros sistemas. La recomendación que traslada Cybersecurity Dive es auditar los servidores StoreFront y los Delivery Controllers y buscar en los registros de Windows inicios de sesión inusuales y uso de Escritorio Remoto. Si aparece alguna de las señales de implante (directivas, ficheros o setuid), el caso deja de ser mantenimiento: es respuesta a incidentes, con análisis forense.

Parchear, mitigar mientras tanto y rotar credenciales

La corrección es actualizar a 14.1-73.37 o 13.1-64.23, o a las compilaciones FIPS y NDcPP equivalentes. No hay atajo de configuración que sustituya a la actualización para los dos fallos a la vez.

Si la actualización se retrasa, GTIG propone desactivar DTLS en los servidores virtuales de Gateway expuestos y bloquear el tráfico UDP/443 entrante en el cortafuegos situado delante del NetScaler. Esa medida solo cubre CVE-2026-88772. Para CVE-2026-88771, que no depende de ninguna opción activada, el boletín no ofrece alternativa, según The Hacker News, y lo que queda es restringir el acceso por origen o retirar el dispositivo de internet hasta poder actualizar.

Con indicios de compromiso, o sin forma de descartarlo, hay que tratar como expuesto todo lo que guardaba el dispositivo:

• Revocar todas las sesiones administrativas, de Gateway y de VPN.
• Cambiar las contraseñas de administración y las claves SSH del NetScaler.
• Renovar las credenciales de las cuentas de enlace LDAP, los secretos compartidos de RADIUS, las credenciales TACACS, las comunidades SNMP y las credenciales de la API NITRO.
• Sustituir los certificados TLS y sus claves privadas.

Rapid7 observó que uno de los primeros movimientos de los atacantes fue empaquetar /flash/nsconfig, el directorio de configuración donde residen credenciales y certificados. Un NetScaler actualizado cuyas claves siguen siendo las mismas continúa siendo útil para quien se las llevó.

GTIG añade dos medidas de bastionado que valen para cualquier dispositivo de este tipo: que la interfaz de gestión no sea accesible desde internet y que el tráfico saliente del NetScaler esté denegado salvo excepción expresa. Para las entidades sujetas a NIS2 hay una consecuencia adicional, porque un compromiso confirmado en el acceso remoto puede ser un incidente significativo y los plazos de alerta temprana cuentan desde que la entidad tiene conocimiento de él.

Lo que falta por saber

Tras la divulgación, Unit 42 describe escaneo y pruebas a gran escala, y Cybersecurity Dive habla ya de explotación masiva. Una campaña selectiva, que las fuentes asocian a espionaje, da paso a un uso oportunista en el que cabe esperar actores con otros fines. Es el recorrido que analizamos en Citrix Bleed 2 y el ransomware Anubis. El plazo de tres días que fijó CISA es el que prevé su directiva operativa BOD 26-04 para fallos explotados en equipos expuestos.

La atribución sigue abierta y el recuento de organizaciones afectadas no está cerrado. Tampoco ha afirmado nadie que los mecanismos de persistencia descritos sean los únicos. Los indicadores publicados reflejan lo observado hasta el 30 de septiembre, y GTIG, Rapid7 y Unit 42 están actualizando sus informes.

Al cerrar la revisión de cada NetScaler debería quedar por escrito la versión instalada, la fecha en que se revisó, las comprobaciones realizadas y las credenciales que se cambiaron. Es la información que previsiblemente pedirá la dirección cuando quiera saber si la organización estuvo entre las afectadas. Ese registro forma parte del plan de respuesta a incidentes.

Artículo divulgativo y defensivo, elaborado con la información pública disponible a 2 de octubre de 2026. No incluye código de explotación. Las rutas, directivas y medidas citadas proceden de los informes enlazados: contrástalas con el original y pruébalas antes de aplicarlas en producción. Versiones, fechas, cifras y atribuciones pueden cambiar.