El parche de tu switch llevaba 97 días publicado

Ayer, 21 de septiembre, CISA añadió una sola vulnerabilidad a su catálogo de fallos con explotación confirmada: CVE-2026-7273, un desbordamiento de pila en el programa CGI del firmware de los switches Zyxel GS1900. El fallo en sí no tiene nada de extraordinario. Lo extraordinario son las fechas: Zyxel publicó el aviso y las diez versiones de firmware corregidas el 16 de junio. Entre ese día y ayer hay 97 días. El plazo que CISA da a las agencias federales para resolverlo vence el 24 de septiembre: tres.

Qué es y a qué modelos afecta

El aviso de Zyxel lo describe en una frase: «A stack-based buffer overflow vulnerability in the CGI program of the Zyxel GS1900 series switch firmware could allow a LAN-based, unauthenticated attacker to exploit the flaw and potentially execute OS commands via a crafted HTTP request.» Un desbordamiento de pila (CWE-121) en el CGI que sirve la interfaz web de administración: una petición HTTP preparada, sin usuario ni contraseña, y ejecución de órdenes del sistema operativo del switch.

La puntuación la pone Zyxel, que es la autoridad que numeró el CVE: CVSS 3.1 de 8,8, vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Los modelos afectados son diez, cada uno con su cadena de versión. Si administras alguno, esta tabla es toda la comprobación que hace falta:

El fallo no lo encontró nadie explotándolo: el aviso agradece el reporte a cinco investigadores del ISCAS. Se reportó, se corrigió y se publicó. Hasta aquí, el proceso funcionó como debe.

«LAN-based» no es una atenuante: es el requisito

La primera letra del vector es la que más se malinterpreta. AV:A significa Adjacent Network: el atacante no llega desde Internet, tiene que estar en la misma red. Cada vez que sale un fallo así aparece la misma lectura tranquilizadora —«entonces a nosotros no nos afecta, el switch no está publicado»— y es justo al revés. El vector no te dice que estés a salvo: te dice cuál es el único requisito para atacarte. Y en una red plana ese requisito lo cumple, desde el primer día, cualquier cosa que ya esté enchufada: el portátil que picó en un phishing, la impresora del pasillo, la cámara IP que instaló un tercero, el equipo del comercial que viene de visita.

A eso se le suma el resto del vector: PR:N (sin privilegios previos), UI:N (sin que nadie haga clic en nada), AC:L (complejidad baja). Y el objetivo no es un PC más: es el aparato por el que pasa el tráfico de todos los demás, el que puede copiar una VLAN a un puerto, el que decide qué llega a dónde. Es la diferencia entre un fallo y un incidente, y no la pone el fabricante: lo que convierte un fallo en gusano es tu red. La mitigación real de un AV:A no se compra: se diseña, y se llama segmentación y control de quién alcanza el plano de gestión.

Hicimos la cuenta: 30 entradas este mes, mediana de 5 días

Los 97 días invitaban a preguntar si esto es lo normal, así que lo contamos nosotros y publicamos el método para que se pueda discutir. Descargamos el catálogo de CISA (versión 2026.09.21, 1.717 entradas), filtramos las 30 que han entrado en lo que va de septiembre de 2026 y, para cada CVE, pedimos al API del programa CVE la fecha de publicación de su registro. La resta de las dos fechas es lo que medimos. Resultado: mediana de 5 días, media de 57,3. Cuando la media es once veces la mediana, es que la mediana no describe a nadie.

Porque son dos poblaciones distintas metidas en la misma lista. 7 de las 30 entraron en el catálogo el mismo día que su registro CVE se hizo público, o incluso un día antes, y otras cinco al día siguiente: ahí el fallo y la noticia de que se explota llegaron juntos, sin ventana de meses que nadie aprovechase. 17 de 30 están en una semana o menos. Pero 12 llevaban 30 días o más de registro público, y 6 pasaban de 90:

Dónde está la frontera de nuestro recuento, dicho claro: la fecha de publicación del registro CVE no es la fecha del parche. En el caso de Zyxel coinciden, porque el aviso del fabricante y el registro son los dos del 16 de junio, y por eso los 97 días son 97 días de parche disponible. En otras de esas once entradas puede no coincidir, y por tanto no afirmamos que todas tuvieran corrección desde el primer día: solo que su registro era público hacía tanto. Los dos casos del kernel de la tabla —este mes entraron tres— enseñan además otra cosa —un fallo corregido en la rama estable puede tardar un año en llegar a tu hierro— y eso es exactamente lo que hace que la cola larga viva donde vive.

El aviso del fabricante sigue siendo el de junio

Al pie del aviso de Zyxel hay un apartado de historial de revisiones. Entero, dice: «2026-6-16: Initial release». Una línea. Ni una palabra sobre la explotación activa, porque el documento no se ha tocado desde que se publicó. No lo contamos como reproche —casi ningún fabricante reescribe un aviso de hace tres meses—, sino porque tiene una consecuencia operativa concreta: lo que cambió ayer no fue el parche, fue la información. Si tu proceso para decidir qué firmware urge consiste en mirar la web del fabricante, ayer no viste nada distinto de lo que veías en junio. La señal venía de otro sitio.

Ese sitio es el catálogo de CISA, que es público, se puede descargar en JSON y no pide registro. Nosotros lo leemos por esto: un aviso de fabricante te dice que hay un parche; el catálogo te dice que alguien ya lo está usando contra alguien.

La frase que decide si tu modelo entra o no

Sobre la tabla de modelos, el aviso pone una condición que conviene leer despacio: «we identified the vulnerable switch firmware versions and released patches for models still within their vulnerability support period». Y a continuación: «Please note that on-market products not listed in the table remain unaffected.» Las dos frases juntas dicen algo bastante preciso, y no es «si no sales en la tabla, estás bien». Dicen que hay parche para los modelos que siguen dentro de su periodo de soporte, y que los que siguen en catálogo y no aparecen en la tabla no están afectados.

La GS1900 es una gama veterana y con varias revisiones de hardware encima. En la tabla están el -24HPv2 y el -48HPv2, pero no sus versiones anteriores sin «v2», que existieron y siguen montadas en armarios. Para uno de esos, el aviso no responde: no está en la tabla y tampoco es un producto en catálogo, así que la frase que tranquiliza no le aplica. No decimos que sea vulnerable —no lo sabemos y no lo vamos a afirmar—; decimos que el aviso no lo aclara, y que en una lista de tareas eso no es un «no aplica», es una pregunta abierta con un aparato detrás.

CISA, para ese caso, escribe la instrucción sin rodeos en la acción requerida de la entrada: aplicar las mitigaciones del fabricante «or discontinue use of the product if mitigations are unavailable». Retirar el aparato. Es una frase incómoda de llevar a un comité, y es la correcta: un switch sin firmware que lo corrija no se arregla con una excepción documentada, igual que la vulnerabilidad es del fabricante pero la excepción es tuya.

Y antes de reflashear: la entrada pide triaje forense

En el JSON del catálogo, la entrada de este CVE trae el campo "forensicTriage": "Yes" y la acción requerida remite a los «Forensics Triage Requirements» de la directiva BOD 26-04. O sea: antes de actualizar, recoge. Reflashear un switch es escribir una imagen y reiniciar, de modo que aquí reaparece el conflicto que ya contamos con el parche del kernel, esta vez con la tabla MAC, la ARP y los contadores por puerto en juego.

Ahora, la parte honesta: de un switch gestionado de gama de acceso no vas a sacar una imagen forense. Lo que se puede recoger es lo que ya estuvieras sacando fuera antes de todo esto —el syslog remoto del equipo, los flujos que registró el cortafuegos o el router, quién tenía alcance a la IP de gestión, la configuración exportada para comparar— y un volcado de la configuración actual y de las tablas antes de tocar nada. Si no hay syslog remoto configurado, no hay nada que recoger: la prueba no se recoge el día del incidente, se prepara meses antes. Es el argumento menos vendible de la monitorización y el único que importa cuando llega el día.

Lo que se comprueba esta mañana

Cinco cosas, en este orden, y ninguna necesita presupuesto:

1. Cuántos hay y dónde. Del inventario, no de memoria. Los switches de acceso son el activo que más veces falta en la lista, porque se compraron con la obra y no con un proyecto.
2. La cadena de versión de cada uno —la del tipo 2.90(AAHL.1)C0— contra la tabla del aviso. El dígito que importa es el que va antes de )C0.
3. Quién alcanza el puerto 80 y el 443 de la IP de gestión. Si la respuesta es «toda la oficina», esa es la tarea urgente de verdad, y es de hoy: no depende de ninguna ventana ni de ningún fabricante.
4. Dónde acaban los logs del switch. Si la respuesta es «en el switch», el punto 5 se hace a ciegas.
5. Actualizar, con ventana y con la configuración exportada antes. Un switch de acceso reiniciándose es la planta entera sin red durante un minuto largo, así que esto se avisa; y los modelos que no aparecen en la tabla del aviso se deciden ahora, con fecha, no cuando salga el siguiente CVE.

Nuestra opinión, dicha como opinión: el fallo es de Zyxel, pero los 97 días son del sector. El switch es el activo sin dueño por excelencia —no tiene agente, no tiene EDR, no se actualiza solo, no aparece en ningún cuadro de mando y nadie lo echa de menos hasta que deja de pasar tráfico—, y esa orfandad no es una casualidad: es lo que pasa cuando el mantenimiento no es de nadie. Un parche disponible que nadie aplica no es un fallo del fabricante. Es una decisión, tomada por omisión, todos los días durante tres meses.

Nota de fuentes

Todo consultado el 22 de septiembre de 2026. Uno: el aviso de seguridad de Zyxel para los switches GS1900, fechado el 16 de junio de 2026, de donde salen la descripción del fallo en inglés, la tabla completa de diez modelos con versión afectada y parche, la frase sobre el vulnerability support period, la nota sobre los productos en catálogo, el agradecimiento a los cinco investigadores del ISCAS y el historial de revisiones de una sola línea. Dos: el registro CVE-2026-7273 del programa CVE, con Zyxel como autoridad asignadora, publicado el 16 de junio de 2026 a las 02:20 UTC; de ahí el CVSS 3.1 de 8,8 con su vector, la clasificación CWE-121 y la lista de productos afectados. Tres: el catálogo de vulnerabilidades explotadas conocidas de CISA, versión 2026.09.21, descargado en JSON; de ahí la fecha de incorporación (21 de septiembre de 2026), el plazo del 24 de septiembre, la acción requerida citada, la referencia a la directiva BOD 26-04, el campo de triaje forense y el hecho de que el uso en campañas de ransomware figura como desconocido. Cuatro, nuestro: el recuento de las 30 entradas incorporadas en lo que va de septiembre de 2026 y la distancia entre la publicación de cada registro CVE y su entrada en el catálogo, calculada por nosotros cruzando ese JSON con el API del programa CVE (cveawg.mitre.org/api/cve/<CVE>) y restando fechas de calendario, sin horas; mediana 5 días, media 57,3, 7 entradas con distancia cero o negativa, 5 más a un día, 17 de 30 en una semana o menos, 12 a partir de 30 días y 6 a partir de 90. El catálogo se descarga en cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json y el aviso de Zyxel está en su página de avisos de seguridad, los dos sin registro. Lo que no afirmamos: no hemos reproducido el fallo ni tenemos un GS1900 en el laboratorio; no sabemos quién explota esto ni cómo, porque CISA no lo publica; no afirmamos que los diez modelos de la tabla sean los únicos afectados de la gama, ni que los modelos ausentes sean vulnerables —el aviso simplemente no lo dice—; y la fecha de publicación de un registro CVE no equivale a la fecha del parche, salvo cuando coinciden, como aquí. Opinión nuestra: la lectura de AV:A como requisito y no como atenuante, que la mediana del catálogo mezcla dos poblaciones distintas, el orden de las cinco comprobaciones y la idea de que un parche disponible sin aplicar es una decisión.

Imagen de portada: fotografía de dominio público de un armario de comunicaciones, recortada por nosotros. Los textos y la marca los añadimos nosotros encima.