El parche de Zyxel para GS1900 dejó el zero-day real al descubierto

Zyxel parcheó el fallo equivocado. Dicho sin rodeos, eso es lo que ocurrió con la línea de switches GS1900: los atacantes comprometieron 996 switches en 48 países a partir de alrededor del 17 de agosto, y la corrección de firmware que Zyxel lanzó en junio —la que CISA ordenó instalar a las agencias federales de EE. UU. antes del 24 de septiembre— no impidió el exploit que realmente se estaba usando. Según CSO Online, el fallo real, ahora catalogado como CVE-2026-107441, es una escritura fuera de límites en la interfaz web de gestión de los switches que permite a un atacante no autenticado ejecutar comandos del sistema operativo. Los investigadores de Binarly afirman que esos comandos se ejecutan como root.

El botín robado era poco vistoso pero valioso: configuraciones de dispositivos, credenciales root en hash e información de red. No es ransomware ni desfiguración de webs: es un mapa de tu red y una ventaja inicial para descifrar las claves que la protegen. Si usas GS1900 y instalaste la corrección de junio sintiéndote previsor, estabas protegiendo una puerta que los atacantes no estaban usando. Aquí tienes lo que sabemos con certeza, lo que afirman las partes implicadas y lo que nadie ha respondido todavía, porque en un bypass de parche la diferencia entre las tres cosas es donde reside tu riesgo.

Lo que está confirmado

Empecemos por el suelo firme. GreyNoise, que monitoriza el tráfico de ataques mediante una red de sensores, informó el 21 de septiembre de que los atacantes extrajeron datos de 996 switches GS1900 alrededor del 17 de agosto, usando un script para recopilar configuraciones, credenciales root en hash e información de red, y dejando el botín en los dispositivos para su recogida. GreyNoise vinculó la campaña con CVE-2026-7273, un desbordamiento de búfer que Zyxel había corregido en junio; y, basándose en ello, CISA añadió ese mismo día CVE-2026-7273 a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), con un plazo de tres días para que las agencias federales lo remediaran.

También confirmado: el 29 de septiembre, Binarly comunicó a Zyxel un fallo previamente desconocido y señaló que los atacantes ya disponían de un exploit funcional para él. Zyxel publicó nuevo firmware —2.90 Parche 3, con compilaciones que terminan en .3C0— los días 22 y 23 de octubre, y publicó su aviso el 3 de noviembre. Diez modelos están afectados, desde el pequeño GS1900-8 hasta el GS1900-48 y sus variantes PoE; cualquier equipo con firmware Parche 2 (compilaciones que terminan en .2C0) o anterior necesita la nueva versión. El análisis técnico de Binarly, validado en firmware emulado y en hardware real, demuestra que el exploit funciona contra el Parche 2 sin modificaciones: la propia lista de firmware compatible del exploit incluso menciona la compilación del Parche 2 para el GS1900-24.

Lo que se afirma y quién lo afirma

Ahora el terreno disputado, porque hay bastante. Empecemos por la gravedad: la entrada CVE de Zyxel puntúa CVE-2026-107441 con 8,8; Binarly le asigna 9,8. Esa diferencia no es un quisquilla académica: es una discusión sobre las condiciones previas. El aviso de Zyxel describe a un atacante no autenticado con acceso basado en LAN. El aviso de Binarly dice:

«un atacante solo necesita alcance de red al servicio de gestión» — aviso de vulnerabilidad de Binarly, según informó The Hacker News

Si has pasado algún tiempo en redes reales, sabes con qué frecuencia una etiqueta de «basado en LAN» resulta ser un deseo: redes de invitados planas, VLAN de gestión mal segmentadas, un jump box que no lo es. El alcance sobre el papel y el alcance en la práctica rara vez son lo mismo. Según The Hacker News, Zyxel le dijo a Binarly que el CVE de junio se refería específicamente a la falta de comprobación del número de parámetros, y que considera la falta de comprobación de tamaño como el fallo independiente que ahora lleva el número CVE-2026-107441. En otras palabras, la postura del fabricante es que corrigió el fallo que pretendía corregir. La postura de los atacantes, demostrada 996 veces, es que eso no importa.

Una afirmación más que conviene señalar: Binarly califica el fallo de zero-day y sostiene que el exploit que GreyNoise describió en septiembre coincide con el que ellos encontraron. Es una cadena de inferencia razonable, pero fíjate en en qué se apoya: ni GreyNoise ni Binarly afirman que los switches atacados ejecutaran realmente el firmware Parche 2 de junio. El exploit funciona, de forma demostrada, sobre el Parche 2. Si las víctimas de agosto estaban parcheadas, no está probado.

Lo que nadie está diciendo

El aviso de Zyxel no indica si CVE-2026-107441 ha sido explotado, un silencio llamativo si se tiene en cuenta que los investigadores afirman que un exploit funcional existía antes de su informe del 29 de septiembre. No ofrece ninguna medida alternativa para quien no pueda actualizar de inmediato. Y tampoco responde a las dos preguntas más importantes para los 996: ¿aplicar el Parche 3 expulsa a un atacante que ya está dentro?, y ¿qué deben revisar los propietarios en un switch que quizá haya sido comprometido? El aviso guarda silencio sobre ambas. Es la parte de la respuesta a incidentes que los fabricantes siguen tratando como un problema ajeno, y por eso «simplemente parchea» es un consejo, no un plan.

El parámetro número 140: por qué el Parche 2 fue un simple obstáculo

La mecánica merece un minuto, porque es una lección magistral sobre cómo fallan los parches. Según el análisis de Binarly, el programa que gestiona las peticiones web del switch almacena cada parámetro en un área fija dimensionada para 140 parámetros. Nunca comprobaba el tamaño de ningún parámetro, y antes del Parche 2 tampoco comprobaba cuántos había almacenado. El exploit envía un parámetro número 140 demasiado grande; desborda el área y sobrescribe el propio contador de parámetros del programa. El siguiente parámetro cae completamente fuera del área, lo que permite al atacante cambiar la función que el programa está a punto de invocar por otra que ejecuta su comando.

El Parche 2 añadió una comprobación sobre el contador. Buena intuición, mal lugar: la comprobación se ejecuta después de que el parámetro sobredimensionado ya ha sido copiado; en ese momento el contador contiene el valor del atacante y la comprobación deja pasar la escritura. Es como un gorila que revisa los carnés cuando la multitud ya está dentro. En el Parche 3, el contador se comprueba antes de la copia y la propia copia tiene un límite de tamaño, lo que según Binarly sí cierra el agujero. Bien. Pero conviene entender lo que realmente aportó a los operadores el ciclo de parches de junio: tres meses de falsa confianza y una entrada en KEV que apuntaba al CVE equivocado.

La factura y quién la paga

Aquí es donde pierdo la paciencia. El instinto del comentariado es gritar «parchea más rápido», pero los operadores que parchearon más rápido —las agencias federales que cumplieron el plazo de CISA del 24 de septiembre, los equipos diligentes que aplicaron el Parche 2 en junio— no obtuvieron ninguna protección con ello. Aquí el parcheo era el control caro (ventanas de mantenimiento, comités de cambios, pruebas de despliegue en diez modelos) y el aislamiento era el barato. La interfaz web de gestión de un GS1900 no tiene por qué ser accesible desde nada que no sea una VLAN de gestión o un jump host. Ese control cuesta una tarde de trabajo con ACL y habría convertido toda esta campaña —CVE-2026-7273, CVE-2026-107441, elige el que prefieras— en un incidente sin importancia. Hemos visto la misma película con las urgencias de KEV en equipos de borde, desde VeloCloud Orchestrator de Arista en adelante: la cinta de correr del parcheo sigue girando, y el plano de gestión accesible sigue siendo accesible.

Entonces, ¿qué debería preguntar el consejo de administración? No «¿hemos parcheado?», sino estas cuestiones:

1. ¿Cuántos GS1900 tenemos, dónde están y quién puede acceder hoy a sus interfaces de gestión?
2. ¿Alguno ha sido accesible desde internet o desde una LAN amplia entre agosto y ahora? De ser así, ¿quién tiene los hashes que había en ellos y hemos rotado esas credenciales?
3. ¿Qué dice el fabricante sobre la verificación post-compromiso? Y si la respuesta es el silencio, ¿cuál es nuestro propio plan de caza de amenazas?
4. ¿Cuánto cuesta renovar los switches gestionados del borde frente al coste de un solo incidente en el que un intruso ya tiene nuestro mapa de red?

Mi conclusión: aplica el Parche 3 esta semana, pero no archives esto como «parcheado, asunto resuelto». Considera sospechoso cualquier GS1900 que fuera accesible durante la campaña hasta que hayas rotado sus credenciales y revisado su configuración, y trata el aislamiento del plano de gestión como el control que deberías haber comprado hace años. Parchear un switch así es lo mínimo; la verificación y la segmentación son lo sustancial. El fabricante corrigió el contador y luego la copia. Arregla tu arquitectura antes de que alguien escriba el tercer CVE.