Aplicaste el parche del switch y seguías expuesto 128 días

El 22 de septiembre escribimos aquí que el parche de tu switch llevaba 97 días publicado. Era verdad y la cuenta estaba bien hecha. Lo que no sabíamos —y se sabe desde el 3 de noviembre— es que ese parche dejaba dentro un desbordamiento que permite ejecutar órdenes como root sin autenticarse. Quien lo instaló el primer día siguió expuesto hasta el 22 de octubre: 128 días más.

Esta es una historia de gente que parcheó, y el motivo por el que les dio igual cabe en una línea de pseudocódigo: el arreglo de junio contaba los parámetros después de copiarlos.

Qué se arregló en junio y qué no

El programa CGI de estos switches guarda los parámetros de cada petición HTTP en un objeto global llamado reqParameters. Son 140 huecos de 1.024 bytes —el aviso declara 143.364 bytes de reserva total; 140 × 1.024 son 143.360— y, pegado justo detrás en el mismo segmento .bss, el contador que lleva la cuenta de cuántos huecos se han usado: g_count. El contador vive justo detrás del array, sin nada en medio.

Si mandas un parámetro número 140 más largo que su hueco, la copia se sale del array y aterriza en el contador. A partir de ahí el siguiente parámetro se escribe donde tú digas, y eso incluye la tabla de punteros a funciones del propio programa. Órdenes del sistema, con usuario root, sin autenticarse.

Lo que Zyxel añadió en junio, según el diff de binarios que publica Binarly, fueron dos comprobaciones: incrementar el contador y salir si llega a 140, y recortarlo a 140 si llega a 141. Es decir, una comprobación de límite correcta, puesta en el sitio equivocado. La frase de Binarly es más seca que cualquier paráfrasis: «Este cambio no aborda la vulnerabilidad. La copia sin límite en la entrada 139 ocurre antes de la comprobación. Esto significa que el valor de g_count se puede sobrescribir antes de que se pueda comprobar.»

Los diez archivos de firmware publicados en junio, uno por modelo, contienen exactamente el mismo binario. Binarly da la huella SHA-256 de la carga .bix y de cada uno de los siete programas CGI, y es idéntica en los diez. Eran diez descargas del mismo código. Su conclusión, literal: «En cualquiera de los dos casos, la vulnerabilidad descrita en el presente aviso está presente en los diez lanzamientos de firmware que se anunciaron como correcciones.»

Las tres fuentes que te mandaban a parchear describían otro fallo

Aquí está lo que de verdad interesa a quien gestiona un parque, y tiene poco que ver con Zyxel: va de cómo decides a qué dedicas el martes. Si en septiembre priorizabas por las tres señales habituales, las tres apuntaban al sitio equivocado.

La fila del medio es la más interesante y la menos cómoda, porque las dos puntuaciones pueden ser correctas a la vez. La diferencia entre 8,8 y 9,8 aquí no es técnica, es topológica: Binarly dice que la explotación va por HTTP y no tiene ningún requisito de adyacencia a nivel de protocolo, que basta con «alcanzabilidad de red al servicio de gestión». Si la interfaz web de tus switches solo vive en una VLAN de gestión aislada, el 8,8 describe tu caso. Si está en la misma red que los puestos, describe tu caso el 9,8. Ya lo contamos con otro fabricante: lo decide tu configuración, no la puntuación.

Y sobre la tercera fila, una comprobación que hicimos hoy para no fiarnos: descargamos el catálogo KEV completo (versión 2026.11.04, 1.768 entradas) y buscamos. CVE-2026-7273 está, desde el 21 de septiembre. CVE-2026-107441, el fallo que el firmware de junio se dejó dentro y que implementa el exploit capturado, no. A día de hoy, quien gobierne su parcheo por el catálogo no tiene abierta ninguna tarea por ese desbordamiento.

La cronología, que es el documento más duro

Dos huecos de esa tabla valen una conversación entera. El primero: entre el 22 de octubre, cuando aparece el firmware bueno, y el 3 de noviembre, cuando se explica por qué hace falta, pasan 12 días. Doce días en los que el arreglo estaba publicado como un «Patch 3» en el foro de la comunidad del fabricante —una nota de versión entre otras— sin ningún aviso de seguridad que le diera urgencia. Si tu proceso espera el aviso para mover ficha, llegabas doce días tarde incluso haciéndolo todo bien.

El segundo: nosotros publicamos el 22 de septiembre y Binarly cerró su verificación el 28. Seis días. No teníamos forma de saberlo y no nos inventamos nada —todo lo que escribimos entonces salía de los registros oficiales—, pero el marco estaba mal: contamos los días que el parche llevaba disponible como si instalarlo cerrara el asunto. El número era correcto y la conclusión que invitaba a sacar, no.

Lo que se llevaron no lo devuelve un firmware

Esta es la parte que se pierde en los titulares sobre parches. GreyNoise documentó qué salió de esos 996 switches en 48 países: las configuraciones, las credenciales de root (en forma de hash) y la información de red. El plano del edificio. VLANs, direccionamiento, nombres, qué habla con qué.

Y un dato del mismo informe que conviene leer dos veces: 564 de las víctimas tenían las credenciales de fábrica. Más de la mitad. El fallo no necesitaba contraseña para entrar —es previo a la autenticación—, así que esos 564 no cayeron por eso; pero cuando se exfiltra la configuración de un equipo con la contraseña de fábrica puesta, lo que se obtiene es una llave que sigue siendo válida después de actualizar el firmware. Actualizar cierra la puerta. No invalida las credenciales que ya salieron, ni hace que el atacante olvide tu topología.

De la clase de equipo del que hablamos ya escribimos a cuenta de el switch que no es de nadie: se compra una vez, se monta, funciona ocho años y no aparece en ningún inventario de parcheo. La diferencia es que aquí nadie se habría enterado desde dentro. Un switch de acceso no lleva agente, no tiene EDR y no te va a llamar. Lo que queda es telemetría guardada y alguien que la mire —el argumento de detección y respuesta gestionada— y ese es justo el problema que ya tratamos cuando contamos que el aviso llegó 47 días tarde y tus registros duran 30.

Antes de que esto se cuente mal

Cuatro acotaciones, porque la versión exagerada de este post sería falsa y circularía mejor.

Seis cosas, y solo una es parchear

Solo el primer punto es «parchear». Los otros cinco son los que cambian algo, y ninguno caduca con el siguiente aviso.

Los puntos 2 y 5 son trabajo de redes y comunicaciones gestionadas y no se hacen con un boletín: se hacen una vez, con la red delante. El punto 6 es mantenimiento informático en una frase. Y segmentar el plano de gestión es lo que convierte el próximo fallo de este tipo —que llegará, de otro fabricante y en otro CGI— en un aviso que lees con calma en vez de en una tarde.

La lección que nos llevamos nosotros no es sobre Zyxel ni sobre un contador mal colocado. Es que «estamos al día» no describe un estado de seguridad: describe un número de versión que coincide con el que un fabricante dijo que estaba bien.

Fuentes. Consultadas el 5 de noviembre de 2026. El análisis técnico —la función web_util_initParaPairs, el objeto global reqParameters con 140 entradas de 1.024 bytes y g_count inmediatamente detrás en .bss, el diff de las líneas añadidas en junio, las dos citas literales, la huella SHA-256 idéntica de la carga .bix en los diez archivos, la valoración AV:N / 9,8 y la cronología de divulgación— es del aviso BRLY-2026-057 de Binarly, publicado el 3 de noviembre de 2026. Las dos fichas oficiales, asignadas por Zyxel como CNA, vía la API del CVE Program: CVE-2026-7273 (publicada el 16-06-2026, CWE-121, CVSS 3.1 8,8 AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) y CVE-2026-107441 (publicada el 03-11-2026 a las 01:41 UTC, CWE-787, mismo CVSS y mismo vector). Los diez modelos y el paso de .2)C0 a .3)C0, el historial de revisiones de una sola línea («2026-11-3: Initial release»), el crédito a Yegor Vasilenko y Fernando Mercês de Binarly y la ausencia de cualquier mención a explotación activa o a rotación de credenciales son del aviso de Zyxel del 3 de noviembre. Los 996 switches en 48 países, la fecha «sobre el 17 de agosto», qué se exfiltró (configuraciones, credenciales de root en hash e información de red) y las 564 víctimas con credenciales de fábrica son del informe de GreyNoise «Open Season on Kapibala», del 21 de septiembre de 2026, que atribuye la actividad a un actor al que llama Kapibala y lo sitúa como «el mismo o relacionado» con la campaña Red Heron. El alta de CVE-2026-7273 en el catálogo KEV el 21-09-2026 con plazo federal el 24, y la ausencia de CVE-2026-107441 en ese catálogo, los comprobamos nosotros descargando el JSON completo del KEV (versión 2026.11.04, 1.768 entradas, publicado el 04-11-2026 a las 20:00 UTC). Las cuentas de días (128 de junio a octubre, 140 de aviso a aviso, 12 del firmware al aviso, 6 de nuestro post a la verificación de Binarly) son nuestras, sobre esas fechas. El uso de NetBox como fuente de verdad y el criterio sobre segmentación del plano de gestión son de nuestro propio trabajo de redes gestionadas, y no están respaldados por esas fuentes.