Fortinet ha publicado un aviso de seguridad (PSIRT) sobre una vulnerabilidad en FortiOS que, en determinadas versiones, podría permitir a un atacante autenticado localmente ejecutar comandos del sistema a través de instrucciones CLI manipuladas. El fabricante recomienda actualizar de inmediato a las versiones corregidas y recuerda que existe una herramienta oficial de rutas de actualización para planificar el salto entre ramas de firmware sin romper la compatibilidad.
El problema se clasifica bajo CWE-684 (Incorrect Provision of Specified Functionality) y afecta a un conjunto acotado de plataformas FortiGate. Fue descubierto internamente por el equipo PSIRT de Fortinet y su publicación inicial está fechada el 14 de octubre de 2025. La compañía detalla con precisión qué versiones están expuestas y qué releases corrigen el comportamiento.
Qué ha pasado y por qué importa
La vulnerabilidad permite que un usuario autenticado —por ejemplo, con sesión CLI en el equipo— pueda elevar el alcance de ciertos comandos y terminar ejecutando órdenes del sistema en el plano subyacente del firewall. No se trata, por tanto, de un acceso sin credenciales; requiere autenticación local. Aun así, el riesgo operativo es elevado en redes donde la consola de administración (SSH/console) es accesible a varios operadores o donde podría verse comprometida alguna cuenta de administración.
En entornos reales, basta con que una credencial administrativa caiga en manos equivocadas (phishing interno, reutilización de contraseñas, fuga en herramientas de gestión, sesión en un jump-host sin MFA) para que esta clase de fallo se convierta en un pivot hacia el control del dispositivo. Por eso, aunque no se mencione explotación activa, la ventana entre la divulgación y el parche es crítica.
Versiones afectadas y solución disponible
Afectadas:
- FortiOS 7.6: 7.6.0
- FortiOS 7.4: 7.4.0 a 7.4.5
- FortiOS 7.2: 7.2.0 a 7.2.10
- FortiOS 7.0: 7.0.0 a 7.0.15
- FortiOS 6.4: todas las versiones (se indica migrar a una rama corregida)
Solución (actualizar a o por encima de):
- 7.6.1 (o superior)
- 7.4.6 (o superior)
- 7.2.11 (o superior)
- 7.0.16 (o superior)
- En 6.4, migrar siguiendo la ruta de actualización recomendada hasta una rama soportada que incluya el arreglo.
Fortinet aconseja seguir el camino de actualización recomendado (upgrade path) para evitar saltos no soportados entre ramas principales y preservar configuraciones y clusters HA.
Plataformas impactadas (FortiGate/FortiOS)
El aviso identifica como afectados estos modelos y familias:
- 100E/101E, 100F/101F
- 1100E/1101E
- 1800F/1801F
- 2200E/2201E
- 2600F/2601F
- 3300E/3301E, 3400E/3401E
- 3500F/3501F
- 3600E/3601E
- 3800D
- 3960E, 3980E
- 4200F/4201F
- 4400F/4401F
- 5001E
- 6000F
- 7000E, 7000F
Otros modelos no aparecen como afectados en este boletín. Aun así, si la instalación ejecuta una de las versiones vulnerables, conviene comprobar el modelo y planificar la actualización.
Cómo priorizar el parcheo en una red real
1) Identificar exposición y cuentas con privilegios.
- Liste qué FortiGate ejecutan versiones dentro de los rangos afectados.
- Revise quién tiene acceso CLI (local, LDAP/AD, RADIUS) y en qué perfiles.
- Evalúe si hay accesos desde salto remoto (jump-hosts) o VPN de administración.
2) Endurecer mientras llega la ventana de mantenimiento.
- Permita administración solo desde IP de confianza (administration access lists).
- Enforce MFA para todas las cuentas con privilegios.
- Desactive temporalmente el acceso CLI desde interfaces no esenciales.
- Revise perfiles de administrador y aplique mínimo privilegio.
3) Planificar la actualización sin romper el servicio.
- Respalde la configuración (backup plano y cifrado).
- Verifique estado de HA: versiones compatibles, sincronización, graceful failover.
- Si la red usa VDOMs, confirme la compatibilidad de la ruta de actualización.
- Pruebe primero en un equipo no crítico o en el miembro secundario del clúster.
4) Confirmar el arreglo y auditar.
- Tras el upgrade, compruebe versión en Dashboard → Firmware Version o por CLI (
get system status). - Audite logs de administración (SSH, consola, cambios de configuración) para detectar comandos atípicos previos a la actualización.
- Documente el cambio y comunique a operaciones y seguridad.
Buenas prácticas permanentes para minimizar el impacto de fallos similares
- Segmentar la administración: acceso a la consola solo desde una red de gestión separada (out-of-band cuando sea posible) o a través de jump-hosts endurecidos.
- Separar identidades: no comparta cuentas; use cuentas nominativas con roles diferenciados y registro de auditoría.
- Controlar la superficie CLI: si la consola web es suficiente para la operación diaria, limite SSH a la red de gestión y valore bloquear su exposición temporalmente durante periodos de riesgo elevado.
- Rotación y vaulting: almacene credenciales en un gestor seguro, con rotación periódica y MFA.
- Backups verificables: haga copias de la configuración y pruebe restauraciones programadas.
- Parcheo regular: mantenga un calendario de updates y sus ventanas aprobadas por negocio.
- Doble control en cambios críticos: aplique cuatro ojos (aprobación por dos administradores) en modificaciones sensibles de políticas y acceso.
Qué significa “atacante autenticado local” en este contexto
En terminología de producto, local no se refiere necesariamente a alguien físicamente junto al equipo, sino a un usuario que inicia sesión con credenciales válidas en la interfaz de administración (CLI/SSH o consola). Esto incluye operadores internos, proveedores con acceso temporal y cuentas de servicio integradas contra directorio. De ahí que la defensa no pueda limitarse a “no exponer al exterior”: la higiene de identidades y la segmentación de administración son tan esenciales como el parcheo.
Qué deben anotar equipos de cumplimiento y dirección
- Fecha de publicación: 14/10/2025.
- Descubrimiento: interno (Fortinet PSIRT).
- Riesgo: ejecución de comandos del sistema por usuario autenticado; impacto potencial en confidencialidad, integridad y disponibilidad del dispositivo y del tránsito que inspecciona.
- Acción requerida: actualizar a las versiones 7.6.1 / 7.4.6 / 7.2.11 / 7.0.16 (o superiores) y migrar desde 6.4 a una rama soportada.
- Ámbito: modelos FortiGate listados; otros modelos no están afectados según el aviso.
- Seguimiento: registrar el ticket de cambio, evidencia de pruebas post-upgrade y actualización del inventario.
Qué pasa si no puedo actualizar hoy
Si por una restricción operativa no es viable aplicar el parche de inmediato, aumente las barreras:
- Bloquee el acceso administrativo desde redes no confiables.
- Habilite listas de control para que solo IP concretas administren.
- Active MFA y revise perfiles de administrador.
- Supervise comandos ejecutados en CLI; alerte por secuencias anómalas.
- Programe una ventana de mantenimiento lo antes posible y notifique a negocio.
Estas medidas no sustituyen a la corrección definitiva: solo reducen la superficie mientras llega la actualización.
Impacto en grandes entornos y MSP
Para organizaciones con docenas o cientos de FortiGate, o para proveedores gestionados, la prioridad es automatizar el inventario de versiones, agrupar por rama y escalonar upgrades para evitar ventanas simultáneas que dejen regiones sin cobertura. La herramienta de rutas de actualización de Fortinet ayuda a calcular los saltos intermedios necesarios (por ejemplo, de 7.2.x a 7.4.x). En clústeres HA, el patrón seguro suele ser actualizar el miembro secundario, conmutar y, después, actualizar el primario.
Lo esencial en una frase
Si su FortiGate ejecuta FortiOS 7.6.0; 7.4.0–7.4.5; 7.2.0–7.2.10; 7.0.0–7.0.15 o cualquier 6.4, actualice a una versión corregida (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16) o migre de rama cuanto antes. Limite el acceso CLI, aplique MFA y revise logs hasta completar el parcheo.
Preguntas frecuentes
¿Cómo saber si mi FortiGate está afectado por la vulnerabilidad de FortiOS (CWE-684) y qué versión necesito?
Revise la versión en Dashboard → Firmware Version o por CLI (get system status). Si está en 7.6.0, 7.4.0–7.4.5, 7.2.0–7.2.10, 7.0.0–7.0.15 o cualquier 6.4, su equipo entra en el rango afectado. Actualice a 7.6.1, 7.4.6, 7.2.11 o 7.0.16 (o superior); desde 6.4 migre a una rama soportada.
¿Qué modelos FortiGate concretos están impactados por el PSIRT y cuáles no?
El aviso cita: 100E/101E, 100F/101F, 1100E/1101E, 1800F/1801F, 2200E/2201E, 2600F/2601F, 3300E/3301E, 3400E/3401E, 3500F/3501F, 3600E/3601E, 3800D, 3960E, 3980E, 4200F/4201F, 4400F/4401F, 5001E, 6000F, 7000E y 7000F. El resto de modelos no figuran como afectados en este boletín.
¿Puedo mitigar el riesgo si debo posponer el parche por una ventana crítica de negocio?
Sí, reduzca exposición: limite el acceso administrativo a IPs de confianza, aplique MFA a todas las cuentas con privilegios, desactive el acceso CLI en interfaces no esenciales y vigile los logs de comandos. Aun así, planifique la actualización a la mayor brevedad.
¿Este fallo permite un ataque remoto sin credenciales desde Internet?
No según el aviso: el vector requiere un atacante autenticado localmente (con sesión CLI). Sin embargo, si una cuenta de administración se compromete, el impacto puede ser elevado. De ahí la urgencia de parchear y de endurecer identidad y acceso.
vía: fortiguard.fortinet
