Vulnerabilidad zero-day en FortiMail (CVE-2026-104286): qué revisar en la pasarela de correo antes de actualizar

Fortinet hizo pública el 1 de octubre de 2026 la vulnerabilidad CVE-2026-104286 de FortiMail, un día cero (zero-day) crítico que ya se explotaba y para el que ese día no existía versión corregida en ninguna de las ramas afectadas (7.2, 7.4, 7.6 y 8.0). También el 1 de octubre, CISA la incluyó en su catálogo KEV de vulnerabilidades explotadas y dio a las agencias federales civiles de Estados Unidos hasta el 4 de octubre para someter sus pasarelas a triaje forense y aplicar la mitigación, según BleepingComputer.

A 5 de octubre, la documentación de Fortinet ya incluye las notas de las versiones 7.6.7 y 7.4.9, aunque el aviso las sigue describiendo como próximas. Con parche o sin él, el primer paso es averiguar si alguien manipuló la pasarela antes, porque la actualización no lo indica.

¿Qué permite CVE-2026-104286 y a qué versiones de FortiMail afecta?

CVE-2026-104286 es una vulnerabilidad crítica de FortiMail que combina un salto de directorio (path traversal, CWE-22) con un tratamiento incorrecto del byte nulo (CWE-158) y afecta a las ramas 7.2, 7.4, 7.6 y 8.0. Según el aviso de Fortinet del 1 de octubre de 2026, un atacante sin autenticar puede escribir ficheros arbitrarios en el sistema subyacente mediante peticiones HTTP o HTTPS manipuladas. La puntuación CVSS es de 9,8 sobre 10.

Field Effect sitúa el punto vulnerable en la parte de la interfaz web que atiende las peticiones de IBE (Identity-Based Encryption), el servicio de correo cifrado de FortiMail. Escribir un fichero y ejecutar código son cosas distintas, pero el aviso de Fortinet clasifica el impacto como ejecución de código u órdenes no autorizados.

Versiones afectadas y corrección por rama, según el aviso y la documentación de Fortinet:

• Rama 8.0 (de 8.0.0 a 8.0.1): corrección anunciada en 8.0.2, cuya publicación no hemos podido confirmar a 5 de octubre.
• Rama 7.6 (de 7.6.0 a 7.6.6): corrección en 7.6.7, con notas de versión fechadas el 2 de octubre.
• Rama 7.4 (de 7.4.0 a 7.4.8): corrección en 7.4.9, con notas de versión fechadas el 3 de octubre.
• Rama 7.2 (de 7.2.0 a 7.2.9): sin corrección anunciada. El aviso indica pasar a la rama 7.4 o superior, y el destino tiene que ser la 7.4.9 o posterior, porque de la 7.4.0 a la 7.4.8 el fallo sigue presente.

La vulnerabilidad la descubrió Gwendal Guégniaud, del equipo de seguridad de producto de Fortinet, según Help Net Security. Fortinet publicó el aviso con indicadores antes de tener el parche terminado, lo que permitió revisar las pasarelas sin esperar a la actualización.

¿Cuándo se publicó el aviso de FortiMail y hay ya parche?

Fortinet publicó el aviso FG-IR-26-175 el 1 de octubre de 2026 sin versiones corregidas, y entre el 2 y el 3 de octubre aparecieron en su documentación las notas de las versiones 7.6.7 y 7.4.9. La secuencia conocida es esta:

• Fecha sin determinar: comienza la explotación. Fortinet no ha dicho cuándo empezó ni contra cuántos clientes. Las entradas de registro de ejemplo del paquete STIX que acompaña al aviso llevan fecha de 20 de julio de 2026.
• 1 de octubre: Fortinet publica el aviso con versiones afectadas, mitigación e indicadores.
• 1 de octubre: CISA incorpora el fallo al KEV y el Centro Canadiense para la Ciberseguridad publica el aviso AV26-989.
• 2 de octubre: INCIBE-CERT publica su aviso, con importancia crítica. Ese día, TechTimes informa de que las versiones corregidas siguen sin publicarse.
• 2 y 3 de octubre: la biblioteca de documentación de Fortinet publica las notas de versión de FortiMail 7.6.7 y 7.4.9. Ambas incluyen correcciones de salto de directorio (CWE-22), aunque no citan el identificador CVE.
• 4 de octubre: vence el plazo federal estadounidense.
• 5 de octubre, cierre de este artículo: el aviso sigue describiendo 8.0.2, 7.6.7 y 7.4.9 como versiones «próximas». Antes de planificar la actualización hay que comprobar el aviso y el portal de soporte de Fortinet.

El plazo de tres días corresponde al nivel más urgente de la BOD 26-04, la directiva de parcheo por riesgo de CISA, en su variante con triaje forense. La directiva solo obliga a las agencias federales civiles de Estados Unidos, aunque sirve de referencia a un responsable de seguridad europeo que necesite justificar una prioridad ante su comité.

¿Cómo funciona el salto de directorio con byte nulo de FortiMail?

Un salto de directorio aprovecha que la aplicación construye una ruta de fichero con datos recibidos en la petición y no comprueba que el resultado permanezca dentro de la carpeta prevista. El byte nulo añade un segundo engaño, porque algunas funciones lo interpretan como final de cadena. La comprobación ve un nombre y el sistema de ficheros acaba usando otro.

En esta clase de fallos, quien alcanza la interfaz puede llegar a depositar un fichero allí donde el sistema lo cargará más tarde. Los indicadores publicados encajan con esa lógica, porque entre los ficheros añadidos figura /data/etc/ld.so.preload. En Linux, el fichero /etc/ld.so.preload enumera bibliotecas que el cargador dinámico inserta en los procesos enlazados dinámicamente cuando arrancan. Una biblioteca ajena en la lista se carga con ellos y, si el fichero está en almacenamiento persistente, sigue ahí tras un reinicio.

Roman Sannikov, de iCounter, declaró a SC World que ese mecanismo contribuye en gran medida a dar a los atacantes persistencia, además de acceso. Según VulnTracker, citado por TechTimes, el fallo también puede dejar FortiMail fuera de servicio.

¿Quién está expuesto a CVE-2026-104286?

A juzgar por las mitigaciones del aviso de Fortinet, están expuestas las pasarelas FortiMail de una rama afectada que tienen activo el servicio IBE y cuya interfaz web es alcanzable por el atacante. El texto de Fortinet habla de la interfaz de webmail, mientras que BleepingComputer, Help Net Security y Field Effect la describen como interfaz de administración.

La referencia de consola de FortiMail da disable como valor por defecto de IBE, de modo que el servicio viene desactivado salvo que alguien lo haya habilitado. Aun así, debe comprobarse pasarela por pasarela. No hay cifras públicas de equipos expuestos ni de víctimas, y Fortinet no ha atribuido los ataques a ningún grupo.

Seemant Sehgal, de BreachLock, recuerda en SC World que las interfaces de gestión accesibles desde internet son un hallazgo frecuente en equipos perimetrales. La gestión de la superficie de ataque localiza esas exposiciones y la gestión de vulnerabilidades indica qué rama ejecuta cada pasarela. Quien siga en 7.2 afronta una dificultad añadida, porque su salida es un cambio de rama, con las pruebas que eso exige en un sistema por el que circula el correo de la organización.

¿Por qué pesa más una pasarela de correo que otro equipo perimetral?

Una pasarela de correo como FortiMail pesa más que otro equipo perimetral porque recibe el correo entrante antes que los buzones, custodia la cuarentena y aplica las reglas de filtrado. Los especialistas consultados por SC World describen lo que puede hacer quien la controla: capturar credenciales de administrador, leer enlaces de restablecimiento de contraseña y alterar el filtrado.

John Bambenek, de Bambenek Consulting, añade que casi todos los casos de BEC que ha examinado incluían reglas de reenvío. El BEC es el fraude por suplantación en el correo corporativo, y su variante más conocida es el fraude del CEO.

FortiMail es además un sistema cerrado que no admite un agente EDR, de manera que lo que sucede dentro se aprecia sobre todo en los registros de la pasarela y en el tráfico que esta genera. Es la dificultad que tratamos al hablar de la detección en dispositivos de red sin agente.

¿Qué indicadores de compromiso de FortiMail hay que buscar?

Los indicadores de compromiso (IoC) que Fortinet publicó el 1 de octubre de 2026 para CVE-2026-104286 son ficheros, direcciones IP y entradas de registro asociados a las intrusiones. BleepingComputer reproduce los ficheros con sus rutas y sus sumas SHA-256. Este resumen orienta la revisión, y los valores completos de cada indicador de compromiso deben tomarse del aviso y de su paquete STIX descargable, que es donde Fortinet publica las sumas.

Ficheros añadidos o modificados

• /data/etc/ld.so.preload y /data/lib/liblog.so, añadidos. El primero apunta al segundo, lo que encaja con un mecanismo de persistencia.
• /data/bin/webconsole y /data/bin/mailservice, añadidos con nombres que pasan desapercibidos en un sistema de correo.
• /bin/smit, /data/etc/httpd.conf y /data/migadmin.tar.gz, modificados.

Entradas de registro y direcciones IP

El aviso de Fortinet señala varias entradas de registro y dos direcciones IP, 79.141.169.187 y 45.129.0.192. La primera entrada es el alta de una cuenta de archivado llamada archive234 con destino remoto en 79.141.169.187 y en la carpeta /uploads. La segunda es una tarea programada de cron, lanzada como root, relacionada con /migadmin. Según el paquete STIX del aviso, esa tarea vuelca la configuración del equipo en un fichero HTML dentro de /migadmin/www y lo borra a las 24 horas.

De las dos entradas, el alta de la cuenta de archivado es la más grave. El archivado es una función legítima de FortiMail que guarda copia de los mensajes, y el destino remoto sugiere que se usó para la exfiltración de datos con las herramientas del mismo producto. El paquete STIX incluye dos políticas de archivado con patrón * asociadas a esa cuenta, es decir, aplicables a todo el correo. Como se trata de configuración, una comparación de sumas de ficheros difícilmente la detecta, y no hay motivo para suponer que una actualización de firmware la retire.

Un equipo de detección puede buscar conexiones salientes de la pasarela que no sean SMTP y que se dirijan a destinos distintos de los servidores de actualización del fabricante y de los sistemas internos conocidos. Fuera del envío de correo, el tráfico saliente de una pasarela es bastante predecible, siempre que esos registros se envíen a otro sistema. Lo explicamos en la guía sobre qué registros enviar al SIEM.

¿Cómo se mitiga CVE-2026-104286 antes de actualizar?

El aviso de Fortinet del 1 de octubre de 2026 mitiga CVE-2026-104286 con la desactivación de IBE y, como alternativas, con dos medidas de red que pueden combinarse con ella:

• Desactivación de IBE desde la consola, con config system encryption ibe seguido de set status disable, o desde la interfaz gráfica. Antes hay que confirmar que ningún usuario depende del correo cifrado por ese servicio.
• Acceso web a FortiMail retirado de internet y limitado a redes internas de confianza.
• Un cortafuegos de aplicaciones web delante de FortiMail que bloquee las peticiones POST a /ibe que contengan ../, si la organización dispone de él.

Si la revisión encuentra alguno de los indicadores, la pasarela debe tratarse como un sistema comprometido. Primero se conservan los registros y una copia de la configuración, y hasta entonces no se modifica el equipo. Después hay que dar por comprometidas las credenciales que la pasarela almacena o ve pasar: las cuentas de administrador, las credenciales de conexión con el directorio y las contraseñas restablecidas por correo durante el periodo dudoso.

No hemos encontrado en lo publicado instrucciones de Fortinet para limpiar una pasarela afectada. La opción conservadora, que también plantea Field Effect, es reconstruirla desde una imagen fiable y revisar la configuración línea a línea antes de restaurarla.

La semana pasada contábamos el mismo problema con otro fabricante: parchear NetScaler no expulsa a quien ya había entrado. Con FortiMail ocurre lo mismo, porque la actualización tampoco indicará si alguien entró antes.

¿Cuándo hay que notificar el compromiso como brecha de datos?

Un compromiso de FortiMail pasa a ser una brecha de datos personales a efectos del RGPD cuando se confirma que hubo copia de correo hacia un servidor ajeno. El RGPD obliga a notificarla a la autoridad de control sin dilación indebida, a ser posible en un máximo de 72 horas desde que se tiene constancia de ella, salvo que resulte improbable un riesgo para los afectados. Las entidades sujetas a NIS2 deben enviar además una alerta temprana en 24 horas cuando el incidente es significativo.

Determinar qué buzones y qué periodo se vieron afectados exige un análisis forense. Coordinarlo con los plazos de notificación forma parte de la respuesta a incidentes.

¿Qué queda por saber de CVE-2026-104286?

A 5 de octubre de 2026 siguen pendientes estos hechos:

• La actualización del aviso FG-IR-26-175 con las versiones corregidas y la confirmación de la 8.0.2.
• La aparición de análisis técnicos o de código de explotación públicos, que ampliaría el número de atacantes capaces de usar el fallo.
• Una atribución, la fecha de inicio de los ataques o nuevos indicadores.

Mientras tanto, los registros de la pasarela deben copiarse a otro sistema, porque tras la actualización serán la prueba disponible de lo que ocurrió antes.

Artículo divulgativo y defensivo, elaborado con la información pública disponible a 5 de octubre de 2026. No incluye código de explotación. Las rutas, órdenes de consola, direcciones e indicadores citados proceden del aviso de Fortinet, de su paquete STIX y de las fuentes enlazadas: deben contrastarse con el original y probarse antes de aplicarlos en producción. Versiones, fechas y atribuciones pueden cambiar.