El 1 de octubre de 2026, Fortinet publicó un aviso de seguridad sobre una vulnerabilidad en FortiMail, su pasarela de seguridad de correo electrónico, y confirmó que el fallo se está explotando de forma activa. La Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) añadió la vulnerabilidad a su catálogo de vulnerabilidades explotadas conocidas el mismo día y dio a las agencias federales civiles hasta el 4 de octubre de 2026 para aplicar la corrección o una solución alternativa. Las versiones que resuelven por completo el problema aún no se han publicado, lo que significa que buena parte del perímetro de seguridad de correo de muchas organizaciones depende hoy de un comando de CLI y no de una actualización de software.
Qué hace la vulnerabilidad
El fallo se identifica como CVE-2026-104286 y tiene una puntuación CVSSv3 de 9.8, la parte más alta de la escala de gravedad. Combina una debilidad de path traversal, catalogada como CWE-22, con una neutralización incorrecta de caracteres de byte NULL, CWE-158. El efecto práctico es que un atacante sin autenticar puede escribir archivos arbitrarios en el sistema subyacente de un appliance FortiMail mediante peticiones HTTP o HTTPS modificadas. No se necesitan credenciales.
Las versiones afectadas son FortiMail 8.0.0 a 8.0.1, 7.6.0 a 7.6.6, 7.4.0 a 7.4.8 y 7.2.0 a 7.2.9. Fortinet corregirá el problema en las versiones 8.0.2, 7.6.7 y 7.4.9, ninguna publicada todavía al momento del aviso, y recomienda a los usuarios de la rama 7.2 actualizar a la 7.4 o superior cuando las correcciones estén disponibles. La vulnerabilidad fue descubierta internamente por Gwendal Guégniaud, del equipo de seguridad de producto de Fortinet.
Cómo se ve un equipo comprometido
Fortinet compartió indicadores de compromiso para que los administradores comprueben si sus appliances han sido afectados. La infraestructura atacante incluye las direcciones IP 79.141.169[.]187 y 45.129.0[.]192. Los indicadores de archivo son más reveladores. Entre los archivos añadidos figuran /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice y /data/etc/ld.so.preload. Los archivos modificados incluyen /bin/smit, /data/etc/httpd.conf y /data/migadmin.tar.gz.
La presencia de un archivo ld.so.preload añadido o modificado merece atención especial, porque ese archivo controla qué bibliotecas compartidas carga el enlazador dinámico al iniciar los procesos. Manipularlo es una técnica conocida para ejecutar código controlado por el atacante dentro de procesos legítimos, algo típico de la instalación de una puerta trasera y no de un simple escaneo oportunista. Fortinet no detalló cuándo ni dónde se observaron los ataques, cuántos sistemas resultaron comprometidos ni quién está detrás, así que el alcance completo sigue siendo desconocido.
Qué hacer ahora mismo
Hasta que existan versiones corregidas, Fortinet ofrece dos mitigaciones. La primera es desactivar el soporte de IBE, la función de cifrado basado en identidad, con estos comandos de CLI:
config system encryption ibe
set status disable
end
La segunda es desactivar el acceso desde internet a la interfaz de administración de FortiMail o restringirlo a una red privada de confianza. Los administradores también deberían comparar los indicadores de archivos y las direcciones IP anteriores con sus propios registros, porque el parche no existe todavía y la detección es hoy la única forma de saber si un despliegue concreto fue objetivo.
Por qué esto importa más allá del appliance
Un FortiMail comprometido no es solo un problema de infraestructura para pasar al equipo de red. El appliance está directamente en la ruta del correo. Ve el correo entrante antes que tus usuarios, aplica el filtrado antispam y antiphishing y, en muchos despliegues, también gestiona el correo saliente. Un atacante con capacidad de escritura arbitraria de archivos en ese equipo tiene un punto de observación sobre todo el flujo de correo: puede leer mensajes, debilitar el filtrado que protege a tus usuarios y manipular correos en tránsito.
Por eso los estándares de autenticación a nivel de dominio como DMARC importan tanto en un incidente así. DMARC no se aplica en tu pasarela. Lo aplica el servidor de correo del destinatario, que verifica de forma independiente la alineación de SPF y DKIM con el dominio de la cabecera From visible antes de decidir qué hacer con un mensaje. Un receptor que aplica tu política p=reject rechazará el correo suplantado que dice venir de tu dominio sin importar lo que una pasarela intermedia comprometida haya hecho o dejado de hacer en el camino.
Hay una segunda implicación, menos cómoda. Si un atacante consigue control suficiente sobre la infraestructura de correo, puede enviar mensajes que pasan la autenticación de forma legítima, porque realmente se originan en una infraestructura que controlas. Eso no es un fallo de DMARC. DMARC responde a la pregunta de si un mensaje viene realmente del dominio que dice, y el correo de un remitente legítimo comprometido sí viene de ahí. Lo que DMARC te da aquí es otra cosa: tus informes agregados se convierten en un sistema de alerta temprana. Un cambio repentino en los resultados de autenticación, fuentes de envío inesperadas o anomalías de volumen en tus datos DMARC es exactamente la señal que delata rápido un componente interno comprometido, si alguien lee los informes.
Qué significa para tu programa
Trata la pasarela como objetivo, no solo como escudo. Los appliances de seguridad que están en la ruta del correo son blancos de gran valor precisamente por donde están. Necesitan la misma disciplina de parches, la misma restricción de exposición de sus interfaces de administración y la misma vigilancia de compromiso que cualquier sistema expuesto a internet.
Aplica controles por capas. Un solo appliance, por bueno que sea, es un solo componente. La aplicación de DMARC en los receptores, la firma DKIM en una capa que el atacante no alcanzó y la monitorización de los informes agregados te dan juntos una protección que no depende de que una sola máquina permanezca limpia.
Vigila tus informes DMARC durante cualquier incidente de seguridad. Durante y después de un evento así, la telemetría de autenticación es una de las formas más rápidas de confirmar si hubo manipulación del flujo de correo o si aparecieron fuentes de envío nuevas. Los informes que nadie lee no pueden avisar a nadie.
Reduce la exposición del plano de gestión en todas partes. La mitigación que recomienda Fortinet, mantener las interfaces de administración fuera de internet, es un consejo válido para cada componente de tu infraestructura de correo, no solo para FortiMail.
La conclusión
Un zero-day con puntuación 9.8, sin parche disponible y explotado de forma activa en un appliance que protege el correo de miles de organizaciones es una situación seria por cualquier métrica. Las organizaciones que mejor la superarán serán las que aplicaron la mitigación de inmediato, comprobaron los indicadores de compromiso y ya tenían una segunda capa de autenticación a nivel de dominio en vigor, de modo que un único componente comprometido no se tradujera en libertad total para suplantar su dominio.
Las amenazas de correo no se organizan según tu ciclo de parches. Excello Mail te da visibilidad continua sobre tu postura de DMARC, SPF y DKIM, para que detectes anomalías en tus datos de autenticación en el momento en que aparecen. Regístrate gratis en Excello Mail y sabe exactamente lo que tu dominio le está diciendo al mundo hoy.