Dos zero-days en Citrix NetScaler explotadas en masa: CISA fijó el 30 de septiembre como fecha límite
Dos fallos críticos de Citrix NetScaler se están explotando sin autenticación para tomar el control total del equipo en minutos, y CISA puso el 30 de septiembre como fecha límite para parchear. Actualizar cierra la puerta: no expulsa a quien ya entró.
Qué pasó y en qué orden
El boletín CTX697096 del 27 de septiembre: ocho fallos, dos zero-days
El domingo 27 de septiembre de 2026, Citrix y Cloud Software Group publicaron el boletín de seguridad CTX697096, una actualización de emergencia que corrige ocho vulnerabilidades en NetScaler ADC y NetScaler Gateway gestionados por el cliente. Dos de ellas son zero-days críticas que ya se estaban explotando en el mundo real antes de que existiera el parche. La compañía reconoce haber observado explotación en despliegues sin mitigar y pide instalar las versiones actualizadas cuanto antes.
Explotadas antes del parche y en masa después de la prueba de concepto
El patrón es el clásico de los últimos años: primero unos pocos atacantes con conocimiento previo, y después la estampida. En cuanto se publicó una prueba de concepto, la explotación se generalizó en Internet en cuestión de minutos, con medios especializados hablando de más de cien organizaciones afectadas y analistas describiendo la instalación de webshells, herramientas de túnel persistente y escalada a privilegios de root. El KEV y varios análisis sitúan la colocación de esas puertas traseras a lo largo de septiembre, es decir, antes de que existieran los parches.
CISA, el catálogo KEV y la fecha límite del 30 de septiembre
La agencia estadounidense de ciberseguridad añadió ambas vulnerabilidades a su catálogo de vulnerabilidades explotadas conocidas el mismo 27 de septiembre, con plazo de remediación para las agencias federales el 30 de septiembre de 2026. Estar en el KEV no es una recomendación: es una obligación con reloj. Para cualquier organización fuera del sector público, es la señal más fiable de que el fallo se está usando de verdad.
Lee también
Los dos fallos, explicados sin adornos
CVE-2026-88771: validación de entradas insuficiente y RCE sin autenticar
La primera vulnerabilidad es un fallo de validación de entradas, clasificado como CWE-20, que permite a un atacante no autenticado ejecutar comandos arbitrarios en el equipo. Puntuación de severidad 9,5 sobre 10 en la escala CVSS 4.0. Traducido: no hace falta tener usuario, ni contraseña, ni sesión iniciada para pedirle al aparato que ejecute lo que le digan.
Por qué la configuración por defecto basta para ser vulnerable
El detalle que más incomoda es el alcance: según Citrix y los análisis de respuesta, la vulnerabilidad afecta a todas las implementaciones de NetScaler ADC y Gateway, incluida la configuración por defecto, sin necesidad de activar ninguna función opcional. No hay una casilla que hayas marcado mal. Si el aparato está expuesto con su configuración de fábrica, ya era alcanzable.
CVE-2026-88772: desbordamiento en el motor de paquetes y el papel de DTLS
La segunda es un desbordamiento de memoria en el motor de procesamiento de paquetes del producto, que puede derivar en ejecución remota de código o en denegación de servicio. También con severidad 9,5, pero sus condiciones son distintas: requiere que DTLS esté habilitado y se dispara mediante cabeceras de registro DTLS malformadas o fragmentadas. Varios análisis describen que la explotación elude la autenticación y provoca una caída no controlada del motor para conseguir acceso inicial con privilegios de root.
Versiones corregidas y qué hacer si tu equipo quedó fuera de soporte
El boletín identifica como corregidas la rama 14.1-73.37 y posteriores y la 13.1-64.23 y posteriores. Si administras una versión que ya no recibe mantenimiento, no hay parche que instalar: la decisión ya no es actualizar, es planificar la retirada del equipo de la exposición pública mientras se reemplaza.
Por qué un appliance de borde es el objetivo favorito
Una puerta y todas las llaves: VPN, aplicaciones internas y certificados en el mismo equipo
Un equipo de borde es la recepción del edificio, no una oficina cualquiera: concentra la terminación de la VPN, la publicación de aplicaciones internas, la validación de identidades y los certificados. Comprometerlo no es ganar una habitación; es quedarse con las llaves de todas.
De RCE a root, y de root a la red interna
Una ejecución remota sin autenticar es poder dar órdenes antes de identificarte, como si el portero aceptara instrucciones de cualquiera que grite desde la calle. Root es, después, sentarse en el despacho del conserje: desde ahí los analistas documentan robo de credenciales y movimiento lateral hacia las redes internas que el aparato protegía.
El historial de NetScaler: no es la primera vez ni será la última
El producto arrastra varios episodios de explotación en los últimos años, y en agosto de 2026 otra vulnerabilidad de NetScaler entró también en el catálogo KEV, con su propio plazo. No es mala suerte: es la superficie de ataque típica de los appliances de borde, software expuesto, muy extendido y difícil de actualizar sin una ventana de mantenimiento.
Parchear no es limpiar: la parte que casi nadie hace
Webshells, túneles, credenciales robadas y registros borrados
El parche es cambiar la cerradura. Si alguien ya copió la llave, la cerradura nueva no lo echa. Por eso los análisis forenses insisten en que actualizar no limpia un equipo sospechoso: las webshells, el túnel y las credenciales robadas siguen funcionando después de la actualización, y hay indicios de que parte de los registros fue borrada para dificultar la investigación.
Preservar evidencia antes de tocar nada: qué piden las guías forenses
Las recomendaciones son concretas y baratas de seguir: conservar los registros locales y, sobre todo, los remotos, mediante syslog externo y la consola de gestión, además de documentar hora, zona horaria y configuración de sincronización horaria del equipo antes de aislarlo. Sin esos datos no hay alcance del incidente, no hay notificación a terceros y no hay forma de saber qué credenciales se llevaron. Reinstalar de fábrica sin copiar antes los registros destruye la evidencia de forma definitiva.
Rotar y revocar: usuarios, sesiones, tokens, certificados y claves de API
Cambiar la contraseña de un usuario no basta. Hay que revocar las sesiones activas, invalidar tokens y certificados que el aparato emitía o guardaba, y rotar las claves de API y los secretos que estuvieran almacenados en él. Mientras eso no ocurra, el atacante conserva un camino de vuelta que no depende del fallo original.
Qué hacer si administras un NetScaler
La secuencia: actualizar, aislar, cazar, rotar, revisar
- Actualizar a las versiones corregidas del boletín, empezando por los equipos que miran a Internet.
- Aislar el aparato si hay sospecha de compromiso, después de copiar los registros y anotar la hora y la zona horaria.
- Cazar señales de intrusión: archivos y procesos que no reconoces, tareas programadas nuevas, conexiones salientes raras, cuentas creadas de la nada.
- Rotar credenciales, sesiones, tokens, certificados y claves de API.
- Revisar cómo entró, qué tocó y qué control faltaba para que no vuelva a pasar.
Qué buscar: señales de compromiso en el borde y en los registros
Las firmas de detección publicadas por fabricantes de seguridad apuntan a webshells colocadas en rutas del propio aparato, procesos con nombres parecidos a los legítimos y tráfico saliente hacia destinos que no figuran en tu inventario. Son herramientas de terceros, no validación oficial: úsalas como pistas, no como certificado de limpieza. Si el aparato es crítico y el compromiso está confirmado, la reconstrucción desde cero con el parche nuevo aplicado antes de reconectar es la opción honesta.
Qué no debes hacer: reinstalar sin copiar los logs y cerrar el incidente el mismo día
Los dos errores clásicos son simétricos: formatear antes de copiar la evidencia, y declarar el incidente resuelto el mismo día del parche. El primero borra la respuesta a qué pasó; el segundo deja al atacante dentro con la puerta nueva puesta.
Qué hacer si no tienes NetScaler pero expones algo a internet
Inventario de exposición: qué responde desde fuera y quién lo sabe
La primera pregunta no es "¿tengo NetScaler?" sino "¿qué de mi organización responde desde Internet y quién de mi equipo lo sabe?". Un appliance que nadie había inventariado es el caso habitual en este tipo de incidentes; la lista debería existir antes de que aparezca una alerta.
Los cinco controles que reducen el impacto de cualquier zero-day
- Guardar los registros fuera del equipo que los genera.
- Dar el mínimo privilegio posible a cada servicio y cada cuenta.
- Rotar credenciales y certificados con periodicidad, no solo cuando hay susto.
- Reducir la exposición pública a lo estrictamente necesario.
- Tener un plan escrito de respuesta, con roles y orden de pasos, antes del incidente.
Lo que todavía no se sabe
No hay atribución pública confirmada de los ataques, ni un alcance definitivo del número de organizaciones comprometidas, ni una cifra fiable de dispositivos expuestos. Tampoco está claro cuánto tiempo llevaban plantadas las puertas traseras antes del 27 de septiembre. Cada una de esas cifras que circula va con su medio y su fecha, no como hecho cerrado.
Conclusión
La emergencia de NetScaler deja tres lecciones que sirven para cualquier servidor expuesto: los equipos de borde concentran demasiado poder, parchear no equivale a limpiar y la evidencia hay que copiarla antes de tocar el aparato. Si administras NetScaler, la secuencia es actualizar, aislar, cazar, rotar y revisar; si no, revisa tu inventario de exposición y guarda tus registros fuera del equipo. Los episodios anteriores de GitLab y plugin4shell siguen la misma lógica.
