Fortinet parchea fallos hallados con IA y FortiOS 7.6.8 rompe el SSO

Desde el 22 de octubre, algunos administradores que actualizan un FortiGate a FortiOS 7.6.8 y entran por SSO se encuentran una pantalla con un único mensaje, «Single Sign-On Failed», y un botón para iniciar sesión en local. Es el efecto secundario de la versión que Fortinet pide instalar sin esperar, porque corrige vulnerabilidades críticas y altas que la compañía encontró con modelos de IA de frontera y cuyos CVE no publicará hasta el 10 de noviembre.

Lo que Fortinet ha corregido sin decir todavía qué es

Carl Windsor, CISO de Fortinet, anunció el 21 de octubre de 2026 en el blog de la compañía una tanda coordinada de versiones para FortiOS, FortiManager y FortiAnalyzer, que llegó al día siguiente y que se sumaba a las de FortiMail y FortiAuthenticator ya disponibles. Fortinet lo llama security hardening release y pide tratarlo como una «priority change rather than a routine maintenance cycle» (un cambio prioritario y no un ciclo rutinario de mantenimiento). Las tablas que acompañan al anuncio son lo único concreto que hay por ahora.

La captura recoge las cinco tablas del anuncio. Hay un detalle que conviene mirar dos veces. En la rama 7.4 la versión corregida de FortiOS es la 7.4.13, mientras que FortiManager y FortiAnalyzer se quedan en la 7.4.12, y en la 7.2 ocurre lo mismo con la 7.2.14 frente a la 7.2.13. FortiMail 7.2 no tiene versión corregida y hay que saltar a la rama 7.4.

Sin identificadores no hay ficha en NVD ni puntuación CVSS que consultar, y tampoco puede haber entrada en el catálogo KEV de CISA. Fortinet publicará los avisos en su página de FortiGuard PSIRT el martes 10 de noviembre, coincidiendo con su ciclo mensual de parches. Hasta entonces, la severidad se toma como un acto de fe. La compañía no dice qué componente falla, si hace falta autenticación ni si alguno de los fallos afecta a la VPN SSL o a la interfaz de administración. FortiSASE se actualiza solo, FortiManager Cloud puede necesitar una actualización manual y las instancias en nubes públicas reciben la versión a través de cada proveedor.

En España, INCIBE-CERT publicó el 23 de octubre el aviso INCIBE-2026-779, de importancia crítica y con la etiqueta de aviso preliminar. Repite las versiones del fabricante y recomienda guardar una copia de la configuración antes de actualizar, restringir la administración a IP de confianza, aplicar MFA y no exponer FortiManager a Internet.

Fortinet adelantó el anuncio en X el mismo 21 de octubre, en un mensaje que pone a la IA en primer plano.

Cómo encontró Fortinet los fallos con modelos de IA de frontera

El anuncio agradece su colaboración a Anthropic, OpenAI, Google y SpaceX, y remite a un programa que Windsor ya había descrito el 30 de junio de 2026 en otra entrada del blog de Fortinet. Ahí cuenta que la compañía combina los proyectos Glasswing (Mythos) de Anthropic y Daybreak (GPT 5.5 Cyber) de OpenAI con modelos propios que ejecuta en local.

Las pruebas empezaron imitando a un atacante sin acceso al código. Los modelos analizaron el firmware, construyeron un modelo de amenazas y propusieron fallos que luego se validaban con pentesting en equipos reales. Por esa vía Fortinet no encontró un número significativo de vulnerabilidades explotables, pero sí comprobó que los modelos son muy buenos comparando versiones de firmware y construyendo PoC para fallos ya corregidos. Esa conclusión de junio explica casi todo el tono del anuncio de octubre.

La cosecha llegó al apuntar los modelos al código fuente. Tras más de 100 pruebas sobre 30 familias de producto, Fortinet clasificaba en junio sus hallazgos así.

Cuatro de cada diez hallazgos eran vulnerabilidades reales. El resto se repartía a partes iguales entre falsos positivos y mejoras de buenas prácticas que no son explotables por sí solas. Fortinet dice que un analista humano revisa cada hallazgo antes de descartarlo como falso positivo y calcula un coste medio de unos 540 dólares en tokens por cada vulnerabilidad real, de cualquier severidad. Las versiones de octubre son la primera entrega pública de esos resultados. No sabemos cuántos fallos corrigen ni qué parte de ese 40 % llega a crítica.

FortiOS 7.6.8 deja fuera a los administradores que entran por SSO

El 23 de octubre, un día después de publicar la versión, Fortinet añadió a su comunidad un artículo de soporte que reconoce el problema. Tras actualizar a 7.6.8, el inicio de sesión SSO de los administradores falla sin ofrecer siquiera la opción de introducir la credencial.

El artículo, capturado arriba, delimita bien el alcance. Fallan el SSO de administrador con FortiCloud, el SSO con un proveedor de identidad externo como Entra ID y el SSO de Security Fabric con el FortiGate raíz como proveedor de identidad. Siguen funcionando el SSO de usuarios de VPN, las cuentas locales y los administradores remotos que se validan contra RADIUS, LDAP o TACACS+. FortiOS 7.2.14, 7.4.13, 7.6.7 y 8.0.2 no tienen el problema. Fortinet escribe que «The issue is under investigation and scheduled for fix in FortiOS 7.6.9» (el problema se está investigando y se corregirá en FortiOS 7.6.9), sin fecha para esa versión.

Para confirmar que un equipo sufre este fallo, el artículo de Fortinet indica entrar con una cuenta local y buscar en el crashlog una entrada FORTISM Violation sobre el fichero /tmp/ftnt1_sp_metadata.xml a la hora del intento, filtrando por la fecha.

diagnose debug crashlog read | grep 2026-10-26

La única solución temporal es usar otro método de autenticación. Si el equipo no tiene ninguna cuenta local de administrador, Fortinet remite a la consola física para arrancar el firmware y la configuración de respaldo, o a FortiManager y FortiManagement Cloud para crear una cuenta nueva. En el foro de Fortinet, un administrador describió el 22 de octubre otro síntoma en un clúster HA ya actualizado, una interfaz web inaccesible por un fallo en la negociación TLS que resolvió forzando TLS 1.2. Es un caso aislado y sin confirmación del fabricante, y otro usuario contestó que esa misma configuración no le funcionó.

Una actualización automática que llega de madrugada

La rama 7.6 añade un factor que el anuncio no menciona. Desde FortiOS 7.6.1, según la guía de administración, las actualizaciones automáticas de parche vienen activadas por defecto en todos los modelos de FortiGate, incluidas las máquinas virtuales. Con los valores de fábrica, el equipo espera tres días desde que detecta la versión nueva y la instala a una hora aleatoria entre las 2:00 y las 4:00. Solo salta dentro de la misma rama, así que un 7.6.7 pasa a 7.6.8 por su cuenta.

La guía excluye los FortiGate que forman parte de un Security Fabric, los gestionados por FortiManager y el secundario de un clúster HA. Los que quedan dentro son los FortiGate independientes, el caso habitual en sucursales y pymes con un único equipo. Si la versión llegó el 22 de octubre, esos equipos han podido actualizarse de madrugada desde el 25 o el 26 y amanecer sin acceso por SSO. Eso cierra los fallos que corrige el parche y deja la administración en manos de una cuenta local que muchas veces no existe.

La misma guía de FortiOS 7.6 recoge los comandos para ver si hay una actualización programada y para desactivarla o moverla a una ventana propia.

diagnose test application forticldd 13
show system federated-upgrade

config system fortiguard
    set auto-firmware-upgrade-delay 0
    set auto-firmware-upgrade-day sunday
end

El primer comando muestra si la actualización automática está activa y cuándo es la siguiente comprobación. El segundo, si ya hay una instalación programada. El bloque de configuración sustituye la espera de tres días por un día fijo de la semana. Para decidir cada actualización a mano existe set auto-firmware-upgrade disable.

Orden de trabajo para FortiGate, FortiManager y FortiAnalyzer

1. Crea o comprueba una cuenta local de administrador de emergencia en cada FortiGate de la rama 7.6 antes de actualizar, con contraseña larga guardada fuera del equipo y acceso restringido a IP de confianza.
2. Actualiza primero los equipos con administración o VPN SSL expuestas a Internet, a FortiOS 8.0.2, 7.6.8, 7.4.13 o 7.2.14 según la rama.
3. Actualiza FortiManager y FortiAnalyzer a 8.0.2, 7.6.8, 7.4.12 o 7.2.13, sin confundir sus números con los de FortiOS.
4. Revisa con diagnose test application forticldd 13 los FortiGate 7.6 que no gestiona FortiManager y decide si mantienes la actualización automática o la fijas a una ventana de cambios.
5. Si un administrador ya no puede entrar por SSO tras la actualización, usa la cuenta local o la consola y confirma el fallo en el crashlog antes de tocar la configuración SAML.
6. Mientras no actualices, saca la interfaz de administración de Internet, limita HTTPS y SSH a IP de confianza y exige MFA en todas las cuentas de administrador.
7. Revisa los eventos de administración antes y después de actualizar en busca de accesos desde IP desconocidas o cambios no autorizados.

Si encuentras indicios de intrusión, trata el equipo como comprometido. Las empresas y los ciudadanos pueden notificar el incidente a INCIBE-CERT, y los organismos públicos, al CCN-CERT. La pieza sobre cómo endurecer un firewall perimetral repasa las medidas de base que reducen la superficie mientras llega el parche.

Diecinueve días de ventaja para quien compare los binarios

Entre el 22 de octubre y el 10 de noviembre hay 19 días en los que los binarios corregidos están publicados y los avisos no. Fortinet defiende ese margen para que los clientes parcheen antes de que se conozcan los detalles, y a la vez escribe que «The window between disclosure and exploitation continues to shrink» (la ventana entre la divulgación y la explotación sigue estrechándose). Su propio informe de junio explica por qué. Los modelos que probó comparan versiones de firmware y construyen PoC para fallos ya corregidos con mucha soltura, y ese es exactamente el trabajo que un atacante hará con 7.6.8 frente a 7.6.7.

El historial del fabricante no invita a apurar. En lo que va de 2026, CISA ha añadido nueve vulnerabilidades de Fortinet a su catálogo KEV, la última el 16 de octubre. Fue el path traversal de FortiOS que el grupo detrás de PEERSTITCH usó para pasar a root, como contamos en la inclusión en KEV de CVE-2025-61624. Dos semanas antes, el 1 de octubre, había entrado el path traversal de FortiMail CVE-2026-104286. Y la campaña FortiBleed dejó en junio un catálogo con credenciales de VPN SSL de 73.932 FortiGate.

La tabla resume las nueve entradas, con datos del catálogo publicado por CISA el 23 de octubre de 2026.

En nuestra lectura, la decisión de retener los CVE es defendible, pero traslada todo el riesgo a quien no puede actualizar rápido. Sin CVSS ni vector, un equipo de operaciones no puede priorizar entre esta tanda y PHP2Shell, que llegó la misma semana con ataques en marcha. Y el fallo de SSO de 7.6.8 da a muchos administradores de la rama 7.6 una razón para quedarse en 7.6.7 justo cuando más expuestos están. El uso de IA por parte de grupos como Storm-0940 con ARTEX muestra que el lado atacante ya automatiza el reconocimiento y la intrusión.

No hay recuento público de FortiGate sin actualizar en España a 26 de octubre, cuando se escribe esta pieza, y ninguna fuente ha publicado aún un análisis de las diferencias entre 7.6.7 y 7.6.8. Si administras FortiGate 7.6, crea hoy la cuenta local de emergencia y actualiza después, sin esperar al 10 de noviembre.