- Dos fallos en Xen permiten que una máquina virtual maliciosa lea y escriba la memoria de otras
- Están lanzando campañas de escaneo masivas para explotar los graves fallos de PHP
Zyxel ha publicado un parche para un zero-day en sus switches GS1900 que los atacantes llevaban explotando desde agosto para comprometer casi mil dispositivos y robar sus archivos de configuración y credenciales. La compañía ha tenido que lanzar una segunda actualización de firmware después de comprobar que el primer parche, publicado meses antes, no frenaba los ataques activos en la red.
La vulnerabilidad, registrada como CVE-2026-107441, es un fallo de escritura fuera de límites en la interfaz web que permite a un atacante sin autenticar ejecutar comandos del sistema mediante peticiones HTTP manipuladas. Afecta a diez modelos de la serie GS1900. Zyxel liberó las nuevas actualizaciones de firmware el 22 de octubre y publicó el aviso de seguridad el 3 de noviembre.
Dónde está el fallo dentro de los switches GS1900
El fallo se localiza en tres programas de la interfaz web: dispatcher.cgi, httprestorecfg.cgi y httpupload.cgi. La página de administración guarda los parámetros de cada petición en un bloque de memoria fijo con 140 espacios de 1.024 bytes, y el código copia los datos antes de comprobar el recuento, lo que deja la puerta abierta al ataque. Zyxel considera que se trata de un fallo distinto porque el exploit también aprovecha una falta de validación en la longitud de los parámetros HTTP.
Un valor demasiado largo en el espacio número 139 desborda la memoria reservada y sobrescribe el propio contador. Fijándolo en un número negativo, el atacante puede escribir en zonas anteriores al bloque y sobrescribir punteros de función para ejecutar comandos como root sin autenticarse. Binarly, que destapó el fallo, valora su gravedad en 9,8 sobre 10, frente al 8,8 de Zyxel, porque el ataque funciona por HTTP normal desde cualquier red que alcance el switch.
Por qué el parche de junio no detuvo los ataques
El 16 de junio de 2026, Zyxel lanzó actualizaciones para el CVE-2026-7273, un desbordamiento de búfer previo a la autenticación en los mismos switches GS1900. A partir del 17 de agosto, GreyNoise detectó una oleada de ataques y, al hacer pública la campaña el 21 de septiembre, atribuyó los ataques a ese mismo fallo; ese día, CISA sumó el CVE-2026-7273 a su catálogo de vulnerabilidades explotadas conocidas.
Binarly comprobó el 28 de septiembre que el exploit en circulación apuntaba a un error distinto y desconocido hasta entonces, capaz de burlar los diez firmwares que se daban por corregidos: los atacantes evitaban el parche de junio corrompiendo el contador de parámetros antes de que se validara. Binarly trasladó el hallazgo a Zyxel el 29 de septiembre; el fabricante confirmó el nuevo fallo el 11 de octubre y distribuyó el parche definitivo el 22 de octubre.
Qué han robado los atacantes y a cuántos switches ha afectado
GreyNoise cuantifica en 996 los switches comprometidos en 48 países, con Italia, Estados Unidos y Taiwán a la cabeza. La firma atribuye la campaña a un presunto actor de habla china, rastreado como Kapibala y vinculado a la operación Red Heron, que Acronis había descrito previamente explotando una vulnerabilidad crítica en el servicio Gitea. Los atacantes extraían configuraciones, credenciales root en formato hash y datos de red: información que podría facilitar movimientos laterales en una red corporativa.
De los casi mil dispositivos afectados, 564 seguían con las credenciales de fábrica, lo que habría facilitado buena parte de los accesos. El ataque usaba un script de Python ofuscado con PyArmor que descargaba un recolector por TFTP y copiaba los datos robados en una carpeta accesible desde la propia web del switch. GreyNoise relaciona esta infraestructura con el backdoor para Linux JITTERLY y el rootkit SIXZUT, que oculta archivos, procesos y conexiones de red.
Qué hacer si tienes un switch GS1900 en tu red
Si administras alguno de los diez modelos afectados, comprueba en el panel de control que el firmware instalado corresponde a la versión publicada el 22 de octubre o posterior: el parche de junio no protege frente a este fallo. Si gestionas varios equipos, revisa uno a uno la versión instalada, sobre todo si estuvieron expuestos a internet durante el verano, cuando arrancó la oleada de ataques.
Reduce además la exposición del switch: la interfaz de administración web no debería estar accesible desde internet, sino limitada a una VLAN de gestión o a direcciones IP de confianza. Cambia cualquier contraseña de fábrica activa y rota las credenciales administrativas si el equipo ha estado expuesto. Revisar los registros en busca de peticiones inusuales puede ayudarte a detectar si el switch formó parte de los equipos comprometidos antes del parche de octubre.