La escena es poco habitual incluso en la industria de la ciberseguridad: Fortinet decidió desactivar temporalmente el Inicio de Sesión Único (SSO) de FortiCloud para frenar la explotación activa de una vulnerabilidad de día cero. El fallo, rastreado como FG-IR-26-060 y asociado también a CVE-2026-24858, afecta a múltiples productos del fabricante cuando esa opción está habilitada y permite que un atacante con una cuenta maliciosa de FortiCloud llegue a iniciar sesión en dispositivos vinculados a otras cuentas.
El movimiento —un “kill switch” desde el lado del proveedor— es relevante por el parche en sí, pero también por el mensaje: en un mundo donde la administración de infraestructura se apoya cada vez más en identidades centralizadas y servicios cloud, un error en la capa de autenticación puede convertirse en una autopista hacia el control administrativo.
Qué se sabe del fallo FG-IR-26-060 y por qué preocupa
Según el análisis público del equipo PSIRT de Fortinet, la vulnerabilidad se encuadra en un patrón clásico: omisión de autenticación por ruta o canal alternativo (CWE-288). La condición clave es que el SSO de FortiCloud esté activado, una función que no viene habilitada de fábrica, pero que puede quedar encendida durante procesos de registro o integración si no se desactiva explícitamente.
El alcance es amplio porque toca piezas centrales del ecosistema:
- FortiOS
- FortiManager
- FortiAnalyzer
- FortiProxy
Y, según avisos de organismos y CERT, también aparecen afectaciones y rutas de actualización para FortiWeb, además de menciones a FortiSwitch Manager en el contexto del abuso del SSO.
En la práctica, el riesgo no es “solo” un acceso puntual. En incidentes observados, tras lograr autenticarse por SSO, los atacantes habrían descargado configuraciones y creado cuentas administrativas locales para mantener persistencia. Ese detalle es crítico: una configuración de firewall o de gestión suele revelar topología, reglas, VPN, autenticación y rutas internas.
Cronología: cuentas bloqueadas, apagón del SSO y vuelta con restricciones
La respuesta de Fortinet se movió en cuestión de días. En su blog PSIRT, la compañía detalla una secuencia que explica por qué el SSO acabó “apagado” temporalmente:
- 23 de enero de 2026: Fortinet deshabilitó cuentas de FortiCloud que se estaban usando en el ataque.
- 26 de enero de 2026: se desactivó el SSO de FortiCloud para frenar el abuso.
- 27 de enero de 2026: el acceso se restauró, pero con un matiz importante: ya no se permitiría el acceso desde dispositivos en versiones vulnerables.
- 28 de enero de 2026: Fortinet aclaró que no se veían afectados los IdP SAML de terceros ni FortiAuthenticator, corrigiendo la preocupación inicial sobre un impacto más generalizado en SAML.
Este detalle —“SSO vuelve, pero bloquea a quien no parche”— convierte la gestión del riesgo en una decisión operativa inmediata: actualizar o quedarse fuera del flujo de autenticación centralizada.
Versiones afectadas: el parche llega por ramas, no por un único “botón”
Uno de los aspectos más incómodos en entornos corporativos es que el arreglo no se resume en una sola versión universal, sino en múltiples ramas. Los listados publicados en avisos técnicos y recopilaciones especializadas coinciden en el patrón: determinadas series quedan afectadas hasta un “punto de corte” concreto. Por ejemplo, en FortiOS se recomienda actualizar a 7.6.6, 7.4.11, 7.2.13 o 7.0.19 (o superiores) según la rama. En FortiManager y FortiAnalyzer aparecen saltos equivalentes (7.6.6, 7.4.10, 7.2.13, 7.0.16…).
La vulnerabilidad figura además con severidad crítica y puntuación CVSS 9,8 en referencias técnicas, un indicador de que el escenario de explotación encaja con impacto alto y bajo esfuerzo del atacante si se cumple la condición del SSO habilitado.
Indicadores de compromiso: el rastro que deja un acceso “demasiado limpio”
El elemento que más inquieta a muchos administradores es que este tipo de acceso puede parecer legítimo: un inicio de sesión por SSO, y después cambios administrativos. Fortinet compartió indicadores para facilitar la caza en logs, incluyendo cuentas observadas y patrones en registros asociados a inicios de sesión por SSO y a creación de administradores locales.
En paralelo, medios especializados han señalado que parte de la actividad habría usado infraestructuras protegidas por servicios de red, lo que puede difuminar el origen real en términos de IP visible. Esa realidad obliga a mirar menos la “IP milagrosa” y más el conjunto: horarios inusuales, nuevas cuentas admin, exportación de configuraciones, y cambios repentinos en autenticación.
Qué deben hacer las organizaciones: del “parchea” al “reduce superficie”
Más allá de aplicar firmware, el incidente vuelve a poner sobre la mesa una idea incómoda: el SSO aporta comodidad, pero también concentra el riesgo. Entre las medidas recomendadas en avisos y guías están:
- Verificar si FortiCloud SSO está habilitado en los equipos y, si no es imprescindible, desactivarlo temporalmente.
- Actualizar a versiones corregidas siguiendo la rama instalada y las rutas recomendadas por el fabricante.
- Restringir el acceso administrativo a IPs de confianza (políticas de acceso local o controles equivalentes) y minimizar la exposición de interfaces de gestión a Internet.
- Auditar cuentas administrativas en busca de entradas inesperadas y revisar registros de autenticación SSO y acciones administrativas.
- En caso de compromiso, rotar credenciales, revisar integraciones (VPN/LDAP/SAML), y restaurar configuraciones limpias si hay dudas sobre la integridad del dispositivo.
El impacto reputacional para Fortinet es evidente, pero el debate de fondo es más amplio y afecta a toda la industria: cuanto más se “sube” la administración a la nube, más importante es diseñar planes de contingencia para el día en que esa nube sea el problema, no la solución.
Preguntas frecuentes
¿Cómo saber si FortiCloud SSO está activado en FortiOS y por qué es importante en CVE-2026-24858?
Porque la explotación se produce cuando la autenticación SSO de FortiCloud está habilitada. Si no lo está, el vector descrito no aplica en el mismo contexto. Los avisos recomiendan revisar la configuración de autenticación y el acceso administrativo.
¿Qué versiones corregidas se recomiendan para FG-IR-26-060 en FortiOS, FortiManager y FortiAnalyzer?
Depende de la rama: en FortiOS se citan saltos como 7.6.6, 7.4.11, 7.2.13 o 7.0.19 (o superiores); en FortiManager y FortiAnalyzer hay equivalentes por rama (por ejemplo, 7.6.6 y 7.4.10 en determinadas series).
¿Qué señales en logs pueden indicar abuso del SSO de FortiCloud y creación de administradores?
Fortinet publicó indicadores y patrones de actividad, incluyendo rastros de inicio de sesión por SSO y creación posterior de cuentas admin locales. La recomendación es revisar tanto autenticaciones como cambios de privilegios y exportación de configuraciones.
¿Por qué Fortinet desactivó el SSO de FortiCloud “desde la nube” y luego lo reactivó con bloqueos?
Porque el fabricante detectó explotación activa y aplicó una medida de contención rápida: apagar el servicio para cortar la cadena y reactivarlo después impidiendo el acceso desde versiones vulnerables, forzando en la práctica la actualización para recuperar el uso del SSO.
Fuente: Cybersecuritynews
