Fortinet ha publicado un aviso de seguridad sobre una vulnerabilidad en FortiOS clasificada como “Incorrect Provision of Specified Functionality” (CWE-684). El fallo puede permitir a un atacante autenticado localmente ejecutar comandos del sistema en el dispositivo mediante órdenes CLI confeccionadas. La compañía ya ha liberado versiones corregidas y detalla qué ramas y modelos FortiGate están afectados.

Aunque no es un 0-day remoto sin credenciales, el riesgo operativo es relevante: en muchos entornos la consola CLI (SSH/console) está disponible para varios operadores, cuentas de servicio o integraciones con directorio. Si una de esas cuentas se ve comprometida —o si existe una mala segregación de privilegios—, un atacante podría elevar alcance y tomar control del plano subyacente del firewall. Por eso el parcheo rápido, unido a medidas de endurecimiento de acceso administrativo, es la prioridad.

Qué versiones de FortiOS están afectadas (y cuáles corrigen el problema)

• 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 (sin fix disponible en esta rama; se debe migrar)
• Versiones con corrección
  • 7.6.1 o superior
  • 7.4.6 o superior
  • 7.2.11 o superior
  • 7.0.16 o superior
  • Para 6.4, Fortinet indica migrar a una rama soportada que incluya la corrección.

La publicación inicial del aviso es del 14 de octubre de 2025. En redes con requisitos de disponibilidad estrictos conviene planificar una ventana de mantenimiento cuanto antes y apoyarse en la ruta de actualización recomendada por el fabricante para saltar entre ramas sin romper compatibilidades.

Qué modelos FortiGate están impactados

El aviso lista expresamente como impactadas las siguientes familias y modelos:

• 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 figuran como afectados en este boletín. Aun así, si su dispositivo corre una versión vulnerable, verifique el modelo y planifique el upgrade de inmediato.

Por qué esta vulnerabilidad importa aunque requiera autenticación

El vector requiere una sesión válida (local/CLI), pero en la práctica:

• Muchas organizaciones tienen varios administradores o proveedores con acceso.
• Es frecuente integrar la administración con LDAP/AD/RADIUS, lo que aumenta la superficie si se compromete una cuenta de dominio.
• Existen jump-hosts y VPN de administración que, si no están bien segmentados o no usan MFA, abren la puerta a accesos indebidos.

En ese contexto, un fallo que amplifica capacidades tras autenticarse puede convertirse en un pivote crítico: desde manipular políticas a implantar persistencia o interferir con el tráfico inspeccionado.

Plan de acción recomendado para equipos de red y seguridad

1) Inventario y verificación de versión

• Enumere todos los FortiGate y apunte modelo y versión (en GUI: Dashboard → Firmware Version; por CLI: get system status).
• Si encuentra 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, agéndelo en la primera ventana posible para subir a 7.6.1 / 7.4.6 / 7.2.11 / 7.0.16 o superior. En 6.4, migrar de rama.

2) Endurecimiento previo (si no puede parchear hoy)

• Restrinja el acceso administrativo a IPs de gestión de confianza (admin-access lists).
• Active MFA para todas las cuentas con privilegios.
• Deshabilite temporalmente el acceso CLI/SSH desde interfaces no esenciales.
• Revise perfiles de administrador y aplique mínimo privilegio.
• Audite los logs de administración y cree alertas para comandos anómalos.

3) Estrategia de actualización en HA/VDOM

• Backup de la configuración (texto y cifrado) y snapshot donde aplique.
• En clúster HA, actualice primero el miembro secundario, conmute (failover controlado) y después el primario.
• Si usa VDOMs, compruebe compatibilidad de la ruta de firmware y particularidades de cada VDOM.
• Tras el upgrade, valide que políticas, VPNs, SD-WAN y routing funcionan y que el clúster vuelve a estado sincronizado.

4) Verificación post-parche

• Confirme versión final (GUI/CLI) y ejecute pruebas funcionales.
• Revise de nuevo logs de administración de los últimos días por si hubiera indicios previos de abuso.
• Documente el cambio y actualice el CMDB/inventario.

Buenas prácticas permanentes que reducen el riesgo de futuros fallos

• Red de gestión separada: administre el FortiGate solo desde una management-LAN o consola fuera de banda.
• Cuentas nominativas y vaulting: sin “cuentas compartidas”; credenciales en gestor seguro, rotación periódica y MFA obligatorio.
• Superficie CLI mínima: si la operación diaria se cubre con GUI/API, limite SSH a la management-LAN y bloquee su exposición en WAN.
• Principio de mínimo privilegio: perfiles de admin granulares; revisión trimestral de permisos.
• Backups probados: no solo copie la config, pruebe restauraciones.
• Calendario de parches: defina ventanas recurrentes y un SLA de actualización para avisos críticos.

Perspectiva para dirección y compliance

• Riesgo: ejecución de comandos del sistema por usuario autenticado; impacto potencial en confidencialidad, integridad y disponibilidad del dispositivo y del tráfico que inspecciona.
• Acción: actualizar a versiones fijas (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16) o migrar desde 6.4; endurecer acceso administrativo.
• Ámbito: familias y modelos listados; el resto no figuran como afectados en este boletín.
• Trazabilidad: conserve evidencias de parcheo (tickets, capturas de versión, logs de cambio) y actualice políticas internas de gestión de vulnerabilidades.

Qué significa “atacante autenticado local” (y qué no)

En la terminología de estos avisos, “local” no implica necesariamente presencia física. Se refiere a alguien que inicia sesión en la interfaz de administración (consola/SSH) con credenciales válidas. Puede ser un operador interno, un proveedor con acceso temporal o una cuenta de servicio. Por eso limitar la administración a una red de gestión, exigir MFA y auditar accesos no son opcionales: son el segundo cinturón cuando aparece un fallo así.

Lo esencial, en una línea

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 la versión corregida (7.6.1 / 7.4.6 / 7.2.11 / 7.0.16) o migre de rama cuanto antes; mientras tanto, cierre la administración a IPs de confianza, active MFA y vigile los logs de CLI.

---

Preguntas frecuentes

¿Cómo comprobar rápidamente la versión de FortiOS por CLI y decidir si debo actualizar?
Conéctese por CLI y ejecute get system status. Si la versión es 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, está en el rango afectado. Debe subir a 7.6.1 / 7.4.6 / 7.2.11 / 7.0.16 o superior; desde 6.4, migre a una rama soportada.

¿Qué modelos FortiGate están afectados por esta vulnerabilidad de FortiOS?
Entre otros: 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. Los demás modelos no están listados en este aviso.

¿Qué hago si no puedo aplicar el parche hoy por una ventana crítica de negocio?
Implemente mitigaciones temporales: limite la administración a IPs concretas, exija MFA a todas las cuentas privilegiadas, desactive SSH/CLI en interfaces no esenciales y monitorice comandos y accesos anómalos. Agende el upgrade en la primera ventana disponible.

¿Esta vulnerabilidad permite un ataque remoto sin credenciales desde Internet?
No. El vector requiere autenticación (sesión CLI) en el equipo. Aun así, si una cuenta administrativa es comprometida, el impacto puede ser severo. De ahí la urgencia de parchear y endurecer identidades y acceso.