Los tres críticos de FortiOS entran por donde tu cortafuegos ya confiaba

El 10 de noviembre Fortinet publicó 46 avisos de seguridad. Ocho están marcados como críticos y ocho tocan FortiOS; en esa intersección hay tres. Los tres piden lo mismo para funcionar: que quien ataque esté donde el aparato ya confiaba. En el segmento donde se habla OSPF, en la silla del vecino iBGP, o en el canal por el que dos miembros de un clúster se sincronizan. Ninguno de los tres pasa por el portal de la VPN ni por la interfaz de administración, que es donde casi todo el mundo mira.

Un cortafuegos hace más cosas de las que caben en su nombre. Filtra, sí, y esa parte está en el inventario de riesgo, se audita y aparece en la memoria de cumplimiento. Pero además decide por dónde sale el tráfico, habla con sus iguales y se sincroniza con su pareja. Toda esa maquinaria funciona a base de confianza concedida de antemano, casi siempre por alguien que ya no trabaja aquí, y es donde van los tres parches de los que vale la pena hablar.

El que va primero: alta disponibilidad

FG-IR-26-273 / CVE-2026-126259, CVSS 9,0. Lo dice el aviso: «A missing authentication for critical function vulnerability [cwe-306] in FortiOS may allow an unauthenticated attacker with HA FGSP + standalone-config-sync, or autoscale to execute command as super admin via crafted HA packets». Sin credenciales, con permisos de super administrador, mandando paquetes al canal de sincronización. El vector es AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H y ese C:H es lo que lo pone por delante de los otros dos: aquí sí se lee todo. Afecta a 8.0.0, 7.6.0–7.6.7, 7.4.0–7.4.12, 7.2.0–7.2.13 y a toda la rama 7.0; se corrige en 8.0.1, 7.6.8, 7.4.13 y 7.2.14; para la 7.0, como en el de OSPF, el aviso no publica build corregida y manda migrar. Fíjate en el detalle de la rama 8.0, porque es fácil tropezar con él: aquí basta la 8.0.1, pero los dos de encaminamiento piden la 8.0.2.

Hay una tensión en este aviso que conviene señalar en vez de taparla. El título que le pone Fortinet es «Unauthenticated adjacent command execution via HA», o sea adyacente, pero el vector publicado dice AV:N, red. Una cosa significa que hay que estar en el mismo segmento y la otra que vale cualquier sitio desde el que llegue un paquete. Fortinet no resuelve la contradicción y nosotros no vamos a elegir por ellos; lo que hacemos mientras tanto es planificar por la lectura mala, que es la del vector. La condición que sí está clara es la otra: hace falta FGSP con sincronización de configuración activada, o despliegue en autoescalado. Eso es una condición de configuración explícita, y marca la diferencia con los otros dos avisos, que no publican ninguna.

Los otros dos no leen nada: cambian el mapa

FG-IR-26-267 / CVE-2026-126253, CVSS 9,3, en el demonio de OSPF de FortiOS y FortiSASE: «may allow an unauthenticated attacker to broadcast LSA via specially crafted request». Un LSA es el anuncio con el que un router le cuenta a los demás qué redes alcanza, así que difundir LSAs falsos es reescribir el mapa que usan los vecinos. Vector AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H, clasificado CWE-305. Afecta a 8.0.0–8.0.1, 7.6.0–7.6.7, 7.4.0–7.4.12, 7.2.0–7.2.13 y 7.0.1–7.0.19, y se corrige en 8.0.2, 7.6.8, 7.4.13 y 7.2.14; para la rama 7.0 el aviso no publica build corregida, dice «Migrate to a fixed release».

FG-IR-26-268 / CVE-2026-126254, CVSS 9,6, un error de truncamiento numérico (CWE-197) en el demonio de BGP: «may allow a configured ibgp neighbor to send malicious/malformed attributes to all connected routers via a specially crafted request». Vector AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:H, mismas ramas afectadas salvo la 7.0 y mismas versiones de corrección. Y aquí está lo que comparten los dos y no comparte el de alta disponibilidad: llevan C:N. Confidencialidad, ninguna. No leen un byte. Lo que comprometen es la integridad y la disponibilidad; en cristiano, el mapa.

Conviene decir qué puntúa ese C:N y qué no. Puntúa el fallo, no lo que venga después. Desviar tráfico hacia una máquina que lo lea es la jugada clásica, y es perfectamente posible encadenarla; lo que pasa es que el robo lo hace entonces otra cosa, con otra puntuación. Para lo que nos ocupa hoy —decidir a qué hora se toca qué— sigue siendo útil: estos dos no se llevan nada por sí solos, y por eso no van a dejar ninguna huella en el sitio donde la buscarías.

«PR:L» aquí describe a un vecino, no una credencial

En la hoja donde se priorizan parches, PR:L se lee siempre igual: «hace falta una cuenta, baja el riesgo». En el de BGP el requisito no es una cuenta, es estar en la lista de vecinos configurados. Matizamos antes de que nos corrijan: una sesión iBGP en FortiOS admite contraseña TCP-MD5, así que credenciales puede haberlas; lo que describe la métrica no es eso, sino la posición. CVSS no tiene casilla para «par de confianza de un protocolo de enrutamiento», lo codifica como privilegio bajo, y en la hoja de cálculo acaba pareciendo un obstáculo para el atacante cuando es una decisión de arquitectura que tomaste tú.

Antes de cerrar la pestaña con un «yo no tengo BGP», mira cómo montaste el SD-WAN. En el despliegue con fabric overlay que documenta el propio fabricante, el hub y las delegaciones van en el mismo número de sistema autónomo: en el ejemplo publicado se ve un local AS number 65400 y los cuatro vecinos también en 65400. Mismo AS es iBGP. Cada delegación de una SD-WAN montada según el manual es, literalmente, «a configured ibgp neighbor». El router de la tienda de Girona deja de ser un detalle de la red y pasa a ser un par de confianza del cortafuegos central, con todo lo que eso arrastra si un día alguien se pone dentro de él. Si tu respaldo además era un módem de la generación anterior, ya sabes qué pasa cuando el tráfico se va por donde no toca.

S:C: el daño no sale en el aparato que parcheas

Los dos vectores de encaminamiento llevan S:C, alcance cambiado: en CVSS significa que el impacto alcanza más allá del ámbito de seguridad que gobierna el componente vulnerable. El aviso de BGP lo dice sin métricas, en una línea: «to all connected routers». La consecuencia operativa es incómoda. El FortiGate sigue en pie, con la CPU normal, los túneles arriba y el panel en verde, mientras lo que se mueve está en la tabla de rutas de los vecinos: un prefijo que aparece donde no estaba, una métrica que cambia, tráfico que sale por el enlace de respaldo, un destino inalcanzable durante cuarenta segundos sin que nadie sepa decir por qué.

La pregunta que deja eso encima de la mesa no es qué versión tienes, que se contesta en un minuto. Es si tienes una alerta que salte cuando cambia una ruta. Caídas de interfaz las vigila todo el mundo; uso de CPU, también. Un cambio en la tabla de rutas no dispara nada en casi ninguna monitorización que nos hayamos encontrado, y es la única señal que produciría cualquiera de los dos. Lo escribimos hace ocho días a propósito de otro aparato de red: aplicar el parche y dejar de estar expuesto no son la misma fecha. Aquí es peor, porque entre las dos fechas no hay ni un registro que mirar.

Lo que hay mientras no actualizas

Los tres avisos traen un campo que se lee poco y que aquí separa a los tres. El de BGP y el de alta disponibilidad tienen parche virtual: FG-VD-62507.0day, disponible en la actualización de base de datos FMWP 26.118, para el primero, y FG-VD-61445.0day para el segundo. El de OSPF dice Virtual Patch: No, y tampoco trae sección de soluciones temporales. Conviene entender qué es eso antes de respirar tranquilo: un parche virtual es una firma que reconoce el ataque y lo corta al pasar, no una corrección del fallo. Sirve si el tráfico atraviesa un punto donde esa inspección está activa y la suscripción al día. El equipo sigue siendo vulnerable; lo que gana es tiempo hasta la ventana de actualización, que suele ser justo lo que hace falta.

Para el de OSPF no hay ni eso, y el porqué probablemente esté en su clasificación: CWE-305 es un salto de autenticación, de modo que la contramedida de manual —poner clave de área o de interfaz— es la capa que el fallo pone en cuestión. Hasta ahí llegamos; Fortinet no detalla qué parte del control se salta y no vamos a deducirlo por ellos. Autenticar las adyacencias sigue siendo lo que hay que hacer, entre otras cosas por el portátil que alguien enchufa en la VLAN equivocada, pero no lo vendemos como blindaje contra este CVE porque nadie ha publicado que lo sea. Cuando no hay contramedida clara, la palanca que queda es el alcance: AV:A, hay que estar en el segmento donde se habla OSPF.

¿Y quién está en ese segmento? La lista honesta de una red que ha crecido por capas incluye casi siempre alguna de estas: la VLAN de tránsito compartida con el equipo del operador, el segmento donde vive un appliance de un tercero instalado con prisa, el enlace con un partner montado para un proyecto que ya terminó, un hipervisor con una máquina virtual que tiene una pata ahí, o el punto de interconexión de un centro de datos compartido. OSPF no se configura por quién eres, sino por en qué interfaces escucho. Una interfaz de más es un vecino de más.

Cuándo esto NO te corre prisa

Si tu FortiGate tiene cuatro rutas estáticas y una por defecto hacia el operador, y la pareja de alta disponibilidad —si la hay— es la clásica, los tres críticos de FortiOS pueden esperar a la ventana de mantenimiento normal. Decirlo nos quita trabajo facturable y es la verdad: la mayoría de las pymes que vemos no habla ningún protocolo de enrutamiento dinámico y no lo va a necesitar nunca. La comprobación son cinco minutos y cinco comandos que no modifican nada: show router ospf y show router bgp dicen si hay configuración; get router info ospf neighbor y get router info bgp summary, si además hay alguien hablando al otro lado; y show system standalone-cluster, junto con el standalone-config-sync de show system ha, cubre la condición del tercero.

Dos cautelas para que ese «no va conmigo» sea honesto. La primera: los dos avisos de encaminamiento no publican condición de configuración explícita —hablan del demonio—, así que la configuración se comprueba, no se supone. La suposición que más veces hemos visto fallar es «aquí nadie ha tocado el enrutamiento». La segunda: si el equipo tiene varios VDOM, la configuración de enrutamiento es de cada VDOM y hay que mirarlos todos, incluido el que montó un proveedor anterior y nadie abre; y en un clúster, los dos miembros.

El resto del lote y el orden que seguimos

De los 46 avisos, 38 no listan FortiOS: son casi todos de FortiManager y FortiAnalyzer, y ahí están los otros cinco críticos, entre ellos CVE-2026-126261 (CVSS 9,0, autorización indebida en FGFM antes de la verificación de contraseña, «execute code or commands via crafted FGFM packets» para quien alcance ese puerto), CVE-2026-126260 (SSRF sin autenticar) y CVE-2026-126262 (inyección SQL). Esa es la parte que ha ocupado los titulares, y con motivo: alcanzar el puerto FGFM de un FortiManager es, en casi cualquier red, más fácil que entrar en un segmento OSPF.

Con eso delante, el orden que seguimos cuando cae una tanda así tiene cuatro pasos, y el primero no es parchear. Uno: sacar del FortiManager, que para eso está, qué versión corre cada equipo, cuáles hablan OSPF o BGP y cuáles tienen FGSP o autoescalado. Dos: los que cumplan la condición del CVE-2026-126259, porque es el único de FortiOS que, sin pedir credenciales, acaba en super admin. Tres: el plano de gestión, con la pregunta incómoda de quién alcanza el puerto FGFM, que en demasiadas redes es «cualquiera que esté dentro». Cuatro: los FortiGate que hablan protocolos de enrutamiento, empezando por los que tienen vecinos que no controlas, y el resto en la ventana normal.

Una nota de hecho para dimensionar la prisa, con su salvedad. Ninguno de los ocho críticos aparece en el catálogo KEV de CISA: lo hemos comprobado hoy contra el fichero del catálogo, 1.779 entradas, cero coincidencias para los ocho CVE. La salvedad es que la versión que sirve CISA hoy es la 2026.11.10, del mismo día del lote, de modo que lo que ese cero dice de verdad es «todavía no», no «nunca». Fortinet, por su parte, marca los tres de FortiOS como no explotados. Eso no da seis meses; da la diferencia entre esta noche y la próxima ventana.

Lo que no arregla un número de versión

Dentro de un mes habrá otra tanda y estos tres sitios seguirán siendo los mismos sitios. Lo que cambia de una red a otra es cuánto daño puede hacer un vecino que un día se porta mal, y eso depende de cuatro decisiones de diseño que se toman una vez: escuchar OSPF solo en las interfaces donde hace falta; autenticar las adyacencias, por todo lo demás; filtrar los prefijos que entran de los vecinos que no son tuyos, para que una tabla de rutas ajena no pueda reescribir la tuya entera; y sacar el canal de sincronización y el plano de gestión de la red por la que pasa el tráfico de los usuarios.

El caso que nos encontramos más a menudo no es una red mal hecha. Es una red que creció por capas —una sede, luego dos, luego el centro de datos, luego el operador nuevo— y en la que hoy nadie es capaz de dibujar en una pizarra quién le anuncia rutas a quién. Ese dibujo es la mitad del trabajo y es lo primero que hacemos cuando entramos en una red corporativa que ya existe: el mapa real de adyacencias, qué vecino es de quién, qué entra sin filtrar, qué interfaz escucha sin motivo y por dónde viaja el latido del clúster. Las versiones vienen después, y van mucho más rápido cuando ese mapa está hecho. Con una SD-WAN sobre túneles el dibujo es todavía más necesario, porque cada delegación añade un par de confianza más.

Fuentes (verificadas el 13-nov-2026, 18:00 CET). Listado PSIRT de Fortinet, recorrido página a página: 46 avisos con fecha 10-nov-2026, de los cuales ocho críticos (FG-IR-26-267, -268, -273, -219, -244, -274, -275 y -276) y ocho que listan FortiOS (-267, -268, -269, -270, -272, -273, -193 y -195). FG-IR-26-273 (CVE-2026-126259): título, CVSS 9,0, vector, CWE-306, la cita literal, versiones afectadas y corregidas y el parche virtual FG-VD-61445.0day. FG-IR-26-267 (CVE-2026-126253): CVSS 9,3, vector, CWE-305, la cita, las versiones, el «Migrate to a fixed release» de la rama 7.0, «Virtual Patch: No» y «Known Exploited: No». FG-IR-26-268 (CVE-2026-126254): CVSS 9,6, vector, CWE-197, la cita literal completa y el parche virtual FG-VD-62507.0day en FMWP 26.118. FG-IR-26-275 (CVE-2026-126261, 9,0): FGFM y su cita. El iBGP del diseño de referencia sale de la documentación de Fortinet, «Verifying BGP routing on the hub» (AS 65400 local y los cuatro vecinos en el mismo AS). get router info ospf neighbor y get router info bgp summary están en la hoja de resolución de problemas de la CLI; show router ospf, show router bgp, show system standalone-cluster y show system ha son la visualización de las secciones de configuración correspondientes (config system standalone-cluster, donde se configura FGSP; standalone-config-sync va bajo config system ha). KEV comprobado sobre el fichero JSON del catálogo de CISA, versión 2026.11.10, 1.779 entradas. Nuestro es el encuadre —los tres críticos de FortiOS piden estar donde el aparato ya confiaba—, la lectura del C:N y de lo que no puntúa, la prueba de que el diseño de referencia de SD-WAN convierte cada delegación en vecino iBGP, el agujero de monitorización de los cambios de ruta y el orden de cuatro pasos. La lectura de S:C y de PR:L como posición y no como credencial la han publicado también otros análisis del mismo lote. Nota honesta: el aviso del fallo de HA se titula «adjacent» y su vector dice AV:N; planificamos por el vector.