CVE-2026-104286: Path Traversal Crítico en Fortinet FortiMail bajo Explotación Activa (CISA KEV)

octubre 3, 2026 Alfonso Moreno | Sysadmin Senior 33 Visitas 12 min de lectura

El 1 de octubre de 2026 CISA añadió CVE-2026-104286 a su catálogo KEV (Known Exploited Vulnerabilities). Se trata de un path traversal combinado con inyección de byte NULL en Fortinet FortiMail, con CVSS 9.8 y explotación activa confirmada en producción. La vulnerabilidad está reportada como FG-IR-26-175 en el PSIRT de Fortinet y fue descubierta internamente por Gwendal Guégniaud, del equipo de seguridad de producto de Fortinet. La directiva BOD 26-04 obliga a las agencias federales de EE. UU. a remediarla antes del 4 de octubre de 2026.

Lo importante para un sysadmin que opera FortiMail on-prem o en cloud: un atacante no autenticado puede escribir archivos arbitrarios en el sistema mediante peticiones HTTP/HTTPS manipuladas. No necesita credenciales, ni acceso a la consola. Si tu FortiMail está expuesto a internet — algo común en appliances perimetrales de correo — estás en riesgo hoy.

Esta guía explica qué versiones están afectadas, cómo verificar si tu appliance es vulnerable, y los pasos de mitigación inmediata (workaround) hasta que puedas aplicar el parche oficial.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 4-6 horas la primera vez, 1-2 horas con Ansible.
Requisitos: VPS con IP estática y PTR configurable (Hetzner, OVH), dominio propio.
Resultado: Mail server SMTP/IMAP con antispam rspamd, deliverability aceptable.
Troubleshooting: PTR/DKIM/SPF/DMARC, mail-tester.com score, logs de Postfix.

Qué es CVE-2026-104286 y por qué importa

El PSIRT de Fortinet describe la vulnerabilidad como una combinación de dos clases CWE:

CWE-22: Improper Limitation of a Pathname to a Restricted Directory (path traversal clásico).
CWE-158: Improper Neutralization of NULL Byte or NULL Character (inyección de byte NULL, normalmente %00 en URL-encoded).

El atacante encadena ambas para evadir los chequeos del módulo afectado y escribir archivos fuera del directorio previsto. El vector es HTTP/HTTPS contra el endpoint IBE (Identity-Based Encryption) que FortiMail expone en su interfaz web. Un POST a /ibe con un payload manipulado (path con ../ y un byte NULL al final para truncar la extensión o el path) permite depositar archivos arbitrarios en el sistema de archivos del appliance. La severidad CVSS 9.8 refleja exactamente este escenario: red, sin autenticación, baja complejidad, sin interacción del usuario, impacto alto en confidencialidad, integridad y disponibilidad.

Lo que vuelve esta alerta especialmente urgente es la combinación de tres factores:

Explotación activa confirmada — CISA no añade al KEV vulnerabilidades que no tengan evidencia pública o privada de explotación in-the-wild. En el momento de la publicación ya hay actores maliciosos usándola.
Vector remoto sin autenticación — el atacante solo necesita que el appliance sea alcanzable por HTTP/HTTPS. No requiere phishing, no requiere credencial, no requiere acceso a la red interna.
Función IBE por defecto activa — muchos deployments de FortiMail tienen IBE habilitado para permitir que usuarios externos descarguen mensajes cifrados desde un enlace. Eso es exactamente el endpoint vulnerable.

Para una empresa mediana con un FortiMail expuesto a internet, esto equivale a un RCE realista: una vez que el atacante escribe el archivo arbitrario (típicamente un webshell PHP o un script CGI), puede ejecutar comandos con los privilegios del servicio web del appliance.

Versiones afectadas y versiones corregidas

La tabla de afectados según el PSIRT FG-IR-26-175 es la siguiente:

Producto	Versión afectada	Solución
FortiMail 8.0	8.0.0 hasta 8.0.1	Actualizar a 8.0.2 o superior
FortiMail 7.6	7.6.0 hasta 7.6.6	Actualizar a 7.6.7 o superior
FortiMail 7.4	7.4.0 hasta 7.4.8	Actualizar a 7.4.9 o superior
FortiMail 7.2	7.2.0 hasta 7.2.9	Migrar a la rama 7.4 o superior

La rama 7.2 ya está fuera de soporte de feature y Fortinet no publicará parche para esa línea: el camino soportado es migrar a 7.4 o superior. Si todavía corres 7.2, este es el momento de planificar el salto de versión; combinar una actualización de plataforma con un fix crítico es la única manera de mantener soporte contractual.

Para los que corren 7.4 o 7.6, hay un detalle a observar: en el momento de redactar este post, Fortinet indica “upcoming 7.4.9” y “upcoming 7.6.7”, es decir, los builds de parche estaban en preparación y el PSIRT se publicó antes de tener todas las imágenes disponibles en el portal de soporte. Si al consultar el portal todavía no ves la versión, vuelve a revisar al cabo de unas horas: el rollout del fix suele ser escalonado por región y por contrato.

Cómo saber si tu FortiMail es vulnerable

Antes de aplicar nada, confirma la versión exacta que corre tu appliance. Desde la CLI de FortiMail:

# Ver la versión del firmware
get system status | grep -E "Version|Build"
# Alternativa: revisar el branch completo
get system status

La salida relevante se ve así:

Version: FortiMail-7.6.4-build1234 (GA)
...

Con eso en la mano, cruza con la tabla de afectados arriba. Si tu versión está en la columna “Affected”, asume que eres vulnerable y aplica el workaround del siguiente apartado antes de continuar con cualquier otra investigación.

Si quieres confirmar exposición a internet — lo que define la urgencia real — verifica los interfaces de gestión:

# Ver qué interfaces aceptan HTTPS/HTTP desde fuera
get system interface
# Ver los puertos administrativos habilitados
get system admin | grep -E "access|port"

Si el puerto de administración HTTPS (por defecto 443 o 8443 según versión) está escuchando en una IP pública, o si el appliance está detrás de un NAT 1:1 con firewall permisivo, la superficie de ataque es completa. En LATAM es relativamente común encontrar FortiMail expuestos directamente a internet para que usuarios externos puedan consultar sus buzones vía webmail — justo el patrón que vuelve a esta CVE crítica.

Workaround inmediato: deshabilitar IBE

El vector concreto está en el módulo IBE (Identity-Based Encryption). Si no usas IBE en absoluto, o si puedes tolerar su desactivación temporal, el workaround del propio PSIRT es directo:

# Por CLI: deshabilitar IBE globalmente
config system encryption ibe
    set status disable
end

Después de aplicar este cambio, verifica que el servicio está caído:

# Confirmar estado
get system encryption ibe
# Salida esperada: status: disable

Equivalente por GUI: Encryption → IBE → IBE Service: off. El cambio se aplica en caliente, no requiere reinicio del appliance. El efecto inmediato: cualquier URL de tipo https://fortimail.example.com/ibe/... dejará de responder, y por tanto el endpoint vulnerable desaparece.

Si tu operación depende de IBE — por ejemplo, porque envías correo cifrado a usuarios externos que descargan mensajes vía enlace — necesitas un plan B: deja IBE activo solo en una red de gestión interna, y bloquea el acceso al puerto HTTPS desde internet hasta que puedas actualizar. Las opciones concretas son:

Restringir el acceso al webmail desde internet. Limítalo a una VPN corporativa o a una IP de gestión fija. El usuario externo puede seguir accediendo si está en la VPN, pero el atacante externo queda fuera.
WAF en frente. Si tienes un WAF o un reverse proxy entre internet y FortiMail (Cloudflare, FortiWeb, HAProxy, NGINX), añade una regla que bloquee POST contra /ibe cuando el body contenga ../. Esto mitiga la variante path-traversal sin tocar la feature de negocio.
Segmentación de red. Saca FortiMail de la DMZ pública y ponlo detrás de un jump host con autenticación. Es la opción más invasiva, pero la que reduce superficie a casi cero.

El workaround no es opcional: mientras la versión siga siendo vulnerable, la única diferencia entre “estoy en riesgo” y “estoy protegido” es si el endpoint IBE responde o no.

Indicadores de compromiso (IoC)

Fortinet publicó dos IPs y un patrón de log en el PSIRT que deberías buscar en tus SIEM, syslog y en los propios logs de FortiMail:

IPs maliciosas:
- 79.141.169.187
- 45.129.0.192

Patrones en System Event Logs:
- Cron ejecutado con un comando sospechoso que empieza con O=/migadmin o similar (típico de un webshell que se instala en el directorio /migadmin del appliance).
- Logout súbito del usuario admin con ui=(null) (un admin script que abre y cierra sesión sin pasar por GUI).
- Cambios de configuración desde CLI que añadan cuentas archive apuntando a IPs externas, especialmente si el campo remote-ip coincide con las IPs maliciosas de arriba.

Patrones en Encryption Logs:
- Errores Caught BufferException(2) con Invalid Base64 Encoding at pos 0. Character=0x2a — la PoC genera payloads Base64 malformados a propósito, y FortiMail loguea el intento de descifrado. Si ves este error en bucle contra /ibe, alguien está intentando explotar la CVE.
- Intentos de login fallidos contra cuentas internas *@tu-dominio.tld — el endpoint vulnerable no requiere login, así que cualquier intento de autenticación asociado al exploit es un indicador adicional.

Para buscar el patrón de cron, en FortiMail con syslog configurado:

# En tu SIEM o grep directo sobre syslog raw
grep -E "O=/migadmin|archive234" /var/log/fortimail/*.log
# Buscar IPs maliciosas en logs de FortiMail
grep -E "79.141.169.187|45.129.0.192" /var/log/fortimail/*.log

Si cualquiera de estos patrones aparece, asume compromiso: el atacante ya pasó la fase de escribir el archivo arbitrario y está usando el appliance como pivote. Pasos inmediatos: aislar FortiMail de la red, hacer backup forense de logs, rotar todas las credenciales que el appliance conocía (usuarios LDAP, cuentas admin, API tokens, secretos de relays), y reconstruir el appliance desde imagen limpia.

Actualizar a la versión corregida

Una vez aplicado el workaround, el siguiente paso es actualizar a la versión parcheada. Desde la GUI:

Ve a System → Firmware.
Si tu contrato de soporte incluye acceso a la imagen, selecciónala y pulsa Upgrade.
Si no la ves, pulsa Refresh desde el portal de FortiGuard; el rollout puede tardar algunas horas.
Tras la actualización, verifica la nueva versión con get system status | grep Version.

Por CLI, el camino equivalente es:

# Subir la imagen .out al appliance vía SCP al puerto 22 admin
# (asume que ya la tienes localmente)
# Restaurar configuración y reiniciar con la nueva imagen
execute restore image tftp <nombre-de-imagen.out> <ip-del-tftp-server>

Antes de actualizar en producción, dos consejos prácticos. Primero: no actualices la misma semana que el PSIRT publica la vulnerabilidad si puedes evitarlo. Los primeros builds de parche a veces traen regresiones, y un FortiMail caído el día que se publica una CVE de CVSS 9.8 es un problema operacional serio. Espera 48-72h, lee los release notes de Fortinet, revisa foros de administradores de FortiMail, y entonces programa el cambio.

Segundo: verifica que la actualización no desactiva el workaround. Algunas actualizaciones de Fortinet reaplican la configuración por defecto, y si tenías IBE desactivado, podría volver a quedar activo. Después de la actualización, repite el get system encryption ibe y confirma que sigue en disable hasta que tu equipo de seguridad dé el visto bueno para reactivar la feature.

Lo que esta CVE dice sobre FortiMail y la superficie perimetral

FortiMail es uno de los appliances de seguridad de correo más usados en empresas y gobierno. Que tenga una vulnerabilidad de CVSS 9.8 explotada activamente, y que el vector sea la interfaz IBE expuesta en el mismo puerto que sirve el webmail, es un patrón que ya hemos visto otras veces en la suite de Fortinet — FortiGate, FortiManager, FortiClient EMS han tenido sus propios CVEs críticos en los últimos meses. El denominador común: appliances con interfaces web expuestas a internet, y features de cifrado/identidad que rara vez son auditadas por el equipo de seguridad.

La lección operacional es la misma de siempre pero conviene repetirla: tu FortiMail no debería ser directamente alcanzable desde internet salvo que sea estrictamente necesario. Si tu caso de uso es “usuarios externos consultan su buzón desde un café”, la respuesta correcta no es exponer FortiMail — es exponer un portal web ligero con autenticación fuerte, con FortiMail en backend detrás de VPN o de un reverse proxy autenticado. La superficie de un appliance corporativo directamente a internet no se justifica nunca salvo para el segmento de relays MTA, y aun así lo razonable es un MTA de borde separado del appliance de gestión de buzones.

Para LATAM, donde muchas empresas medianas corren FortiMail como appliance único para todo el ciclo de correo — recepción, filtrado, entrega, webmail, archivo — el riesgo se multiplica. Si ese único appliance queda comprometido, el atacante tiene buzón completo de la organización, archivo de correo histórico, y pivotaje a la red interna. Una CVE como esta no se evalúa solo por su CVSS: se evalúa por el blast radius si la explotan en tu contexto.

Resumen accionable

Identifica hoy mismo qué FortiMail tienes y en qué versión corre: get system status | grep Version.
Si está en una versión afectada (8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8, 7.2.0-7.2.9): deshabilita IBE por CLI o GUI inmediatamente, o bloquea el endpoint IBE en tu WAF.
Revisa logs buscando las IPs 79.141.169.187 y 45.129.0.192, los patrones de cron O=/migadmin, y los errores BufferException(2) en logs de cifrado.
Programa la actualización a 8.0.2 / 7.6.7 / 7.4.9 (o migración a 7.4+ si corres 7.2) en la próxima ventana de mantenimiento.
Después de actualizar, mantén IBE desactivado temporalmente y verifica que la configuración no se haya revertido.
Mientras tanto, considera mover FortiMail fuera de la exposición directa a internet si tu modelo operativo lo permite.

El plazo de remediación federal es 4 de octubre de 2026. Para el resto, la ventana de gracia es más corta de lo que parece: con la PoC ya circulando y la vulnerabilidad añadida a KEV, el tiempo entre publicación y explotación masiva se mide en días, no en semanas.

Preguntas frecuentes

¿Por qué CVE-2026-104286: Path Traversal Crítico en Fortinet FortiMail bajo Explotación Activa (CISA KEV) es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con CVE-2026-104286: Path Traversal Crítico en?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con CVE-2026-104286: Path Traversal Crítico en?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar CVE-2026-104286: Path Traversal Crítico en y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a CVE-2026-104286: Path Traversal Crítico en?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.