El 21 de septiembre de 2026, CISA agregó una sola vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas (KEV) y le puso a las agencias federales estadounidenses un plazo de remediación de tres días: el 24 de septiembre. Se trata del CVE-2026-7273, un desbordamiento de búfer en la pila del programa CGI de los switches Zyxel de la serie GS1900, con puntuación CVSS 8.8.
La parte relevante no es la puntuación. Es el recuento del daño ya hecho y la fecha del parche.
Qué permite el fallo y qué hizo el atacante
La vulnerabilidad permite que un atacante no autenticado y situado en la red local envíe una petición HTTP especialmente diseñada a la interfaz de administración del switch y, con ella, ejecute comandos del sistema operativo del equipo. No hace falta contraseña. Solo hace falta estar en la LAN.
Según lo reportado, un actor de amenazas explotó el fallo y exfiltró datos de 996 switches ZyXEL en 48 países. El método no fue exótico: usó el propio equipo para invocar TFTP, descargar un script recolector a medida y ejecutarlo. Lo que se llevó fue precisamente el material que convierte un incidente en una campaña:
- Configuraciones completas de los equipos.
- Credenciales de nivel root en formato hash.
- Información de la topología de red.
Es decir: el atacante no se llevó datos de clientes. Se llevó el mapa y las llaves para volver después, por la puerta correcta, y parecer administrador.
El parche llevaba tres meses disponible
Zyxel publicó su aviso de seguridad para el desbordamiento de búfer en la serie GS1900 el 16 de junio de 2026. La explotación activa se documentó desde agosto. CISA lo formalizó el 21 de septiembre.
Tres meses entre el parche y la alerta federal. Ese intervalo no se explica por negligencia deliberada, sino por algo más prosaico: estos equipos no están en el inventario. Un switch de acceso de ocho o veinticuatro puertos, instalado hace cuatro años debajo del mostrador de una sucursal, en el armario del almacén o detrás de la caja, no tiene agente de gestión, no aparece en el reporte de parches del servidor, y solo se le recuerda cuando deja de dar enlace.
Por qué “solo desde la LAN” ya no es un atenuante
Durante años, el requisito de “atacante adyacente a la red” se leyó como un factor mitigante. Hoy es casi lo contrario. Si el atacante necesita estar en la LAN de la sucursal, las vías de entrada son abundantes y ninguna implica romper el perímetro: un portátil de un tercero, una impresora expuesta, un kiosco de autoservicio, una cámara IP, una sesión de soporte remoto o una red de invitados mal segmentada.
Y lo que encuentra allí es un dispositivo que, por diseño, ve todo el tráfico del piso.
Qué revisar esta semana
- Inventariar el equipo de red de sucursal. No el del centro de datos: el de las sucursales, agencias, puntos de venta y oficinas remotas. Marca, modelo, versión de firmware, fecha del último cambio.
- Sacar la administración de la LAN de usuarios. La interfaz web de un switch de acceso no debería ser alcanzable desde la misma red donde se conectan visitantes, kioscos e impresoras. VLAN de gestión separada, y lista de control de acceso.
- Buscar señales de acceso previo. Los equipos afectados deben revisarse en busca de accesos no autorizados, actividad de administración sospechosa, cambios de configuración inesperados y peticiones HTTP anómalas contra la interfaz administrativa.
- Rotar credenciales. Si el hash de root salió del equipo, cambiar el firmware no basta. Y si esa contraseña se reutilizó en otros dispositivos — que es lo habitual —, el alcance es mayor que un switch.
Dónde encaja esto con TEKFENIX
En TEKFENIX diseñamos software que vive precisamente en ese piso de sucursal. Nexturno, nuestra plataforma de gestión de turnos y colas, opera sobre kioscos, pantallas y terminales que comparten red con el resto del equipamiento de la oficina; por eso la desplegamos partiendo de la segmentación, el cifrado del tráfico de gestión y el inventario explícito de cada dispositivo, en lugar de asumir que la red interna es un lugar de confianza. Servigo365 convierte esos hallazgos en tickets con responsable, plazo y evidencia de cierre, que es lo que distingue una revisión hecha de una revisión anunciada. Y CumplimientoControl conserva la traza de qué se remedió y cuándo — el documento que el auditor pide después, no durante, el incidente. Si no sabe cuántos switches tiene su organización en sucursales ni con qué firmware corren, ese es el primer proyecto, no el parche.