Casi 1.000 switches comprometidos en 48 países, un actor vinculado a China y una atribución errónea que dejó desprotegidos incluso a los equipos ya actualizados.
Qué ha pasado
El 3 de noviembre de 2026, Zyxel publicó un aviso de seguridad para una vulnerabilidad de escritura fuera de límites en el firmware de sus switches gestionables de la serie GS1900, identificada como CVE-2026-107441, con una puntuación CVSS de 8.8. El mismo día, la firma de seguridad de firmware Binarly reveló que ese fallo se había estado explotando en internet como zero-day desde agosto.
El dato que convierte este caso en algo más que un parche rutinario es la atribución errónea. El 21 de septiembre, GreyNoise había advertido de que atacantes estaban comprometiendo switches GS1900 explotando el CVE-2026-7273, un fallo de desbordamiento de búfer que Zyxel ya había corregido en junio, y CISA lo añadió a su catálogo de vulnerabilidades explotadas conocidas (KEV). Pero Binarly descubrió que los atacantes no usaban ese fallo: su exploit apuntaba a una vulnerabilidad completamente distinta, que seguía funcionando incluso en switches con el parche de junio instalado.
En palabras de Binarly: «como el actor de amenazas estaba explotando una vulnerabilidad diferente, y el parche para el CVE-2026-7273 seguía siendo ineficaz, esto no tuvo ningún efecto a la hora de proteger los dispositivos frente a este actor de amenazas». Quien aplicó el parche de junio y dio el caso por cerrado siguió expuesto durante meses.
El fallo
El CVE-2026-107441 es una escritura fuera de límites en /cgi-bin/dispatcher.cgi, el programa CGI que procesa los parámetros de gestión web del switch antes de la autenticación. Por una validación de límites insuficiente, un atacante sin autenticar y con acceso de red a la interfaz web puede enviar peticiones HTTP especialmente construidas que corrompen contadores internos de parámetros y provocan una escritura fuera de límites en memoria, sobrescribiendo punteros hasta ejecutar comandos del sistema operativo con privilegios de root.
Zyxel describe al atacante como «basado en LAN» (con acceso a la red local), mientras que la telemetría de GreyNoise y Binarly muestra dispositivos comprometidos a través de internet, lo que apunta a interfaces de gestión expuestas públicamente. En la práctica, cualquier GS1900 con su panel web alcanzable desde internet era un objetivo.
El fallo afecta a diez modelos de la serie GS1900, entre ellos el GS1900-8, el GS1900-24 y el GS1900-48. Todas las versiones de firmware 2.90(XXXX.2)C0 y anteriores son vulnerables; el parche está en las versiones 2.90(XXXX.3)C0, específicas de cada modelo. Zyxel publicó el firmware corregido el 22 y 23 de octubre y el aviso oficial el 3 de noviembre. Binarly había notificado el hallazgo a Zyxel el 29 de septiembre, y el fabricante confirmó la nueva vulnerabilidad unas dos semanas después.
La campaña: casi 1.000 switches en 48 países
Según GreyNoise, los ataques comenzaron alrededor del 17 de agosto de 2026 y comprometieron 996 switches GS1900 repartidos en 48 países. Los atacantes usaban un script para recopilar la configuración del dispositivo, información de la red y las credenciales root cifradas (hash) de cada switch.
Binarly atribuye la campaña a un actor al que llama Kapibala, un clúster presuntamente de habla china vinculado a la campaña Red Heron, el mismo actor que Acronis sorprendió atacando instancias de Gitea a gran escala. La atribución se apoya en la infraestructura de mando y control y en el malware desplegado: el backdoor Jitterly y el rootkit Sixzut, ambos analizados previamente por Acronis en el contexto de Red Heron.
El hallazgo clave de Binarly llegó al investigar infraestructura de mando y control expuesta que alojaba las herramientas de Jitterly y Sixzut: allí encontraron un archivo con un exploit ofuscado en Python (exp.py) y comprobaron que funcionaba contra los firmwares .2 ya parcheados contra el CVE-2026-7273.
El botín no es casual. La configuración de un switch, su topología de red y las credenciales root cifradas dan al atacante un mapa completo de la red de la víctima y una vía para moverse lateralmente hacia dentro de la infraestructura. Y el rootkit Sixzut está diseñado para ocultar archivos, conexiones de red y procesos en ejecución en el propio dispositivo, lo que complica enormemente detectar que un switch está comprometido mirando solo sus pantallas de diagnóstico.
Qué hacer ahora
Si tienes switches Zyxel GS1900, este es el orden:
- Actualiza al firmware
2.90(XXXX.3)C0de tu modelo. No vale el parche de junio: las versiones.2siguen siendo vulnerables a este fallo. Zyxel publicó el aviso con la tabla completa de modelos y versiones el 3 de noviembre. - Si el switch estuvo expuesto a internet con firmware
.2o anterior, no te fíes del parche solo: asume compromiso potencial. Por el rootkit Sixzut, haz un restablecimiento de fábrica tras actualizar, restaura la configuración de VLAN manualmente desde valores conocidos como limpios y rota todas las contraseñas de administración, las claves SNMPv3 y los secretos de RADIUS y TACACS+. - Saca la gestión de los switches de internet. Ningún panel de gestión HTTP/HTTPS de un switch debería ser alcanzable desde la WAN ni desde VLANs de usuarios. Aísla las IPs de gestión en una VLAN dedicada de gestión fuera de banda, accesible solo a través de un host de salto.
- Bloquea el tráfico saliente a internet desde las VLANs de gestión. Si un dispositivo de infraestructura comprometido no puede contactar con su servidor de mando y control, el ataque se queda en nada.
Ángulo Blue Team: qué vigilaría un SOC
Este caso deja dos lecciones que valen más que el propio parche.
La primera es que un parche aplicado no es una prueba de que el fallo esté cerrado. Los equipos de seguridad que vieron la alerta de GreyNoise de septiembre y comprobaron que sus switches llevaban el firmware de junio tenían motivos para relajarse: la vulnerabilidad atribuida estaba corregida. Pero la atribución era errónea. Un SOC debería tratar cualquier alerta de explotación activa contra un modelo concreto como una señal para verificar el comportamiento real del dispositivo, no solo su versión de firmware.
La segunda lección es de detección. Sixzut oculta procesos, archivos y sockets en el propio switch, así que las pantallas de diagnóstico del equipo no son una fuente fiable. Lo que sí deja rastro es el tráfico: hay que vigilar en el cortafuegos perimetral y en el NDR las peticiones HTTP entrantes dirigidas a /cgi-bin/dispatcher.cgi y, sobre todo, conexiones salientes iniciadas por las IPs de gestión de los switches hacia hosts externos. Un switch no tiene ninguna razón legítima para iniciar conexiones a internet.
Y un aviso general: si tus registros no te permitirían reconstruir hoy si un switch de tu red fue tocado en agosto, tienes un problema de visibilidad en la capa de infraestructura que conviene resolver antes del próximo incidente.
Fuentes
- SecurityWeek — «Zyxel Switch Hacks Blamed on Patched Flaw Actually Exploited a Zero-Day» (5 de noviembre de 2026): https://www.securityweek.com/zyxel-switch-hacks-blamed-on-patched-flaw-actually-exploited-a-zero-day/
- CSO Online — «Zyxel patches a zero-day hiding behind an old fix» (5 de noviembre de 2026): https://www.csoonline.com/article/4245028/zyxel-patches-a-zero-day-hiding-behind-an-old-fix.html
- Zyxel — «Zyxel security advisory for out-of-bounds write vulnerability in GS1900 series switches» (3 de noviembre de 2026): https://www.zyxel.com/global/en/support/security-advisories/zyxel-security-advisory-for-out-of-bounds-write-vulnerability-in-gs1900-series-switches-11-03-2026
- Binarly — «New Zyxel GS1900 pre-auth RCE vulnerability revealed» (3 de noviembre de 2026): https://www.binarly.io/blog/zyxel-gs1900-rce-cve-2026-107441
- Shellcode — «Binarly Unmasks Zyxel GS1900 Switch CGI Zero-Day CVE-2026-107441 Exploited to Deploy Jitterly and Sixzut» (5 de noviembre de 2026): https://sh3llc0d3.com/blog/binarly-unmasks-zyxel-gs1900-switch-cgi-zero-day-cve-2026-107441-exploited-to-deploy-jitterly-and-sixzut/