FortiMail: Fortinet confirma ataques activos a una falla crítica

11 oct 2026, 09:00·2 fuentes

Por InfraCrew Editorial · Criterios editoriales y correcciones

Fortinet confirma explotación activa de CVE-2026-104286 en FortiMail. La vulnerabilidad permite escribir archivos sin autenticación y puede abrir la puerta a ejecución remota; las correcciones varían por rama.

Una bandeja roja con sobres junto a una pasarela compacta de seguridad de correo con luces de enlace, en una sala de clasificación vacía.

FortiMail: Fortinet confirma ataques activos a una falla crítica

Fortinet confirmó que atacantes están explotando CVE-2026-104286 en FortiMail. El fallo permite a un remoto sin autenticación escribir archivos arbitrarios en el sistema mediante peticiones HTTP o HTTPS manipuladas y tiene CVSS 9,8. CERT-FR confirmó explotación activa en su aviso del 2 de octubre y describe riesgo de ejecución remota de código. La prioridad es localizar cada FortiMail expuesto y comprobar su versión corregida, sin esperar a que aparezca un síntoma en el correo.

-InfraCrew dice: La pasarela inspecciona el correo que entra; hoy también toca revisar quién está llamando a su puerta web.-

Qué permite la vulnerabilidad

El aviso FG-IR-26-175 describe una combinación de recorrido de rutas y tratamiento incorrecto de bytes nulos en una función de FortiMail relacionada con IBE. Una solicitud especialmente construida puede escapar de la ruta de archivos prevista y escribir fuera de ella, aunque el atacante no disponga de una cuenta. No es un fallo que dependa de robar primero una contraseña válida.

CERT-FR caracteriza el riesgo como ejecución remota de código, consecuencia posible del control de escritura sobre el sistema subyacente. Conviene mantener la distinción: el hecho confirmado por la descripción técnica es la escritura arbitraria; el impacto operativo puede llegar a la ejecución de comandos, pero no significa que cada intento produzca automáticamente el mismo resultado. Fortinet confirma explotación activa, así que la incertidumbre sobre el resultado de un ataque no reduce la urgencia de la revisión.

La vulnerabilidad está vinculada a la interfaz de FortiMail que atiende solicitudes HTTP o HTTPS y a la función IBE, el cifrado de mensajes basado en identidad. Si IBE está habilitado y la interfaz de gestión es accesible desde redes no confiables, el appliance merece prioridad inmediata. Un servidor de correo seguro también forma parte de la superficie que hay que proteger.

-InfraCrew dice: Cuando el filtro de correo necesita una alerta urgente, la bandeja de entrada ya no es el único sitio que conviene mirar.-

Ramas afectadas y correcciones

El aviso de CERT-FR del 2 de octubre identifica FortiMail 7.4.x anterior a 7.4.9, 7.6.x anterior a 7.6.7 y 8.0.x anterior a 8.0.2. Esas son las versiones de corrección publicadas para las ramas 7.4, 7.6 y 8.0 que el aviso detalla. Fortinet PSIRT FG-IR-26-175 es la referencia que debe prevalecer si la tabla cambia o si el equipo pertenece a una rama distinta.

Para FortiMail 7.2, el detalle no coincide entre los registros consultados: la ficha de CVE enumera builds vulnerables de esa rama, mientras CERT-FR la describe como anterior a la rama 7.4 y no ofrece en ese aviso un build corregido concreto. No conviene adivinar una versión 7.2 “segura” a partir de una tabla secundaria; comprueba el advisory actual de Fortinet y la ruta de migración que corresponda al soporte de esa instalación.

El aviso de CERT-FR del 2 de octubre remite a FG-IR-26-175 como fuente de las correcciones y confirma que Fortinet considera activa la explotación. Para operaciones, eso convierte el inventario y la revisión de registros en parte de la respuesta, además de la instalación del parche. Un FortiMail sin identificar puede seguir expuesto aunque los gateways conocidos ya estén corregidos.

Qué revisar ahora

Primero, inventaría los equipos FortiMail, sus ramas y builds; localiza cuáles exponen gestión por Internet o por redes compartidas y confirma si IBE está activo. Fortinet publica en su advisory los pasos de mitigación y los indicadores de compromiso. Deshabilitar IBE o restringir la gestión puede reducir exposición mientras se prepara el cambio, pero no sustituye instalar la versión corregida.

Actualiza cada appliance a la release indicada para su rama soportada, siguiendo las instrucciones del fabricante y validando el servicio de correo después del cambio. Revisa los indicadores del advisory antes y después de actualizar, porque un parche impide nuevas explotaciones conocidas pero no demuestra por sí solo que el equipo nunca fuese comprometido. Si aparecen señales sospechosas, trata el caso como una posible intrusión y conserva registros para el análisis.

-InfraCrew dice: El cambio no termina cuando el paquete se instala: termina cuando la versión, el flujo de correo y los registros cuentan la misma historia.-