La decisión fue tan rápida como poco habitual: Fortinet desactivó temporalmente el inicio de sesión único (SSO) de FortiCloud tras confirmar la explotación activa de un fallo de día cero que afecta a varios de sus productos más desplegados. La vulnerabilidad, identificada por el fabricante como FG-IR-26-060 y registrada como CVE-2026-24858, permite que un atacante con una cuenta de FortiCloud y un dispositivo registrado pueda iniciar sesión en dispositivos vinculados a otras cuentas, siempre que el SSO de FortiCloud esté habilitado en esos equipos.
El incidente pone el foco en un problema de fondo que preocupa cada vez más a los equipos de seguridad: la comodidad de la gestión cloud y del SSO puede convertirse en una superficie de ataque crítica cuando la autenticación se transforma, de facto, en un “pase VIP” para administrar infraestructuras. El fallo se clasifica como omisión de autenticación por ruta o canal alternativo (CWE-288), una tipología conocida, pero especialmente delicada cuando se mezcla con accesos administrativos.
Qué hace diferente a este 0-day: no es un bug aislado, es un patrón
Según el análisis publicado por Fortinet, el episodio guarda similitudes con la oleada de diciembre de 2025 vinculada a bypass de SSO (CVE-2025-59718 y CVE-2025-59719), pero con un matiz clave: en enero se detectaron casos en los que el acceso no autorizado se produjo contra equipos que ya estaban actualizados a la última versión disponible en el momento del ataque, lo que apuntaba a una nueva vía de explotación.
La compañía también aclaró un punto que había generado inquietud inicial: aunque en un primer momento se temió un impacto más amplio sobre implementaciones SAML, finalmente confirmó que la incidencia afecta a FortiCloud SSO y no a IdP SAML de terceros ni a FortiAuthenticator. Esta precisión es importante para acotar el riesgo en entornos con identidad federada, donde no todo SSO es igual.
Cronología: cuentas maliciosas, apagón del SSO y reactivación con “bloqueo por versión”
La respuesta se aceleró en cuestión de días:
- 22–23 de enero de 2026: Fortinet deshabilitó las cuentas de FortiCloud que se estaban usando en los ataques, según su propio “timeline” público.
- 26 de enero de 2026: el fabricante apagó FortiCloud SSO para frenar el abuso.
- 27 de enero de 2026: el servicio se restauró, pero con un cambio que equivale a un cortafuegos operativo: FortiCloud SSO dejó de aceptar inicios de sesión desde dispositivos en versiones vulnerables, empujando a las organizaciones a actualizar si querían mantener ese flujo de autenticación.
En paralelo, CISA publicó una alerta sobre explotación en curso y, según los registros del NVD, el 27 de enero de 2026 añadió la CVE al catálogo KEV con fecha límite de remediación el 30 de enero de 2026 para organismos federales, una señal clara de urgencia.
Productos y versiones afectadas: parche por ramas, no un único “botón”
Los avisos técnicos describen un alcance amplio, con especial impacto cuando el SSO de FortiCloud está habilitado. En la práctica, el “dolor” para operaciones llega porque los saltos de versión dependen de la rama instalada.
De acuerdo con la alerta de INCIBE, las rutas recomendadas incluyen, entre otras:
- FortiOS: actualizar a 7.6.6 o superior; 7.4.11 o superior; 7.2.13 o superior; 7.0.19 o superior.
- FortiManager: 7.6.6+, 7.4.10+, 7.2.13+, 7.0.16+.
- FortiAnalyzer: 7.6.6+, 7.4.10+, 7.2.12+, 7.0.16+.
- FortiProxy: 7.6.6+, 7.4.13+; y en ramas 7.2/7.0 se recomienda migrar a una versión corregida.
Además, el registro del NVD (NIST) incluye también afectación para FortiWeb en varias ramas (8.0.0–8.0.3, 7.6.0–7.6.6, 7.4.0–7.4.11), lo que refuerza la idea de un problema transversal en el ecosistema cuando la autenticación cloud entra en juego.
Indicadores de compromiso: el ataque deja huella, pero puede parecer “legítimo”
Uno de los aspectos más incómodos de este incidente es que el rastro inicial puede confundirse con un acceso válido: un login por SSO y, a continuación, acciones administrativas.
Fortinet compartió indicadores concretos: dos cuentas observadas en los inicios de sesión, varias IPs (incluidas algunas protegidas por Cloudflare) y un patrón repetido de creación de cuentas admin locales para persistencia. También publicó ejemplos de logs con identificadores de evento para “admin login successful” y para “object attribute configured”, típicos cuando se añade un nuevo administrador.
El riesgo operativo no es solo el control del dispositivo: algunos reportes describen que los actores descargaron configuraciones tras el acceso, un escenario especialmente grave porque ese “mapa” puede exponer reglas, VPN, segmentación, rutas y mecanismos de autenticación. Medios especializados llegaron a hablar de campañas automatizadas y de un número elevado de endpoints potencialmente afectados.
Qué deberían priorizar los equipos de TI y seguridad
En un medio tecnológico, el mensaje clave es sencillo: esto no va de “aplicar un parche cuando haya hueco”. Va de reducir superficie y cortar el vector cuanto antes, porque se trata de autenticación administrativa.
Medidas alineadas con las recomendaciones públicas:
- Confirmar si FortiCloud SSO está habilitado en los equipos de borde y gestión. Si no es imprescindible, desactivarlo de forma temporal mientras se planifica la actualización.
- Actualizar por rama a versiones corregidas (o migrar si la rama no tiene fix directo), priorizando los activos expuestos o con gestión accesible desde Internet.
- Revisar cuentas administrativas (locales y remotas) y buscar altas inesperadas, cambios de perfil y accesos por SSO en horarios anómalos.
- Restringir la administración (por ejemplo, con políticas “local-in”, listas de IPs de confianza y reducción de servicios expuestos), una “vieja receta” que vuelve a ser decisiva cuando falla la identidad centralizada.
- Si se detecta compromiso: rotación de credenciales, auditoría de integraciones (VPN/LDAP), y validación de la integridad de la configuración antes de confiar en el dispositivo.
La lección para 2026: la identidad cloud es infraestructura crítica
Este caso deja una idea que va más allá de Fortinet: cuando un fabricante convierte el SSO cloud en una experiencia “sin fricción”, el sector gana velocidad… pero también concentra riesgo. Y cuando aparece un bypass, el incidente se vuelve sistémico: no afecta a una máquina, sino a un modo de operar.
La propia reacción —apagar el SSO a nivel de proveedor y reactivarlo bloqueando versiones vulnerables— muestra hasta qué punto la frontera entre seguridad, continuidad y control del fabricante se está moviendo. Para muchas organizaciones, el reto inmediato es técnico (parchear y auditar). El reto estratégico es otro: diseñar operaciones que sigan funcionando incluso cuando el “cerebro” de autenticación en la nube se convierte, temporalmente, en el problema.
Preguntas frecuentes
¿Cómo comprobar si FortiCloud SSO está habilitado y por qué es crítico en CVE-2026-24858?
Porque la explotación descrita se activa cuando el login administrativo por FortiCloud SSO está habilitado. Los avisos recomiendan revisarlo explícitamente, ya que puede quedar activado durante el registro si no se desmarca la opción correspondiente.
¿Qué versiones de FortiOS deberían considerarse “mínimas” para mitigar FG-IR-26-060?
Depende de la rama: las guías públicas apuntan a saltos como 7.6.6, 7.4.11, 7.2.13 o 7.0.19 (o superiores), además de rutas equivalentes para FortiManager y FortiAnalyzer.
¿Qué señales en logs pueden indicar abuso del SSO y creación de cuentas admin para persistencia?
Fortinet ha publicado indicadores y ejemplos de logs asociados a login por SSO y a la adición de administradores locales. La recomendación práctica es correlacionar “login por SSO” + “alta de admin” + “exportación/descarga de configuración”.
¿Por qué CISA elevó la urgencia y qué implican las fechas de su catálogo KEV?
El registro del NVD refleja que la CVE se añadió al KEV el 27 de enero de 2026 y fijó una fecha límite de remediación el 30 de enero de 2026 para el ámbito federal, un indicador de explotación real y prioridad alta de mitigación.
Fuente: Fortinet apaga SSO de Forticloud
