FortiMail: el parche salió el 2, el aviso lo dijo el 7, y la mitigación sigue puesta

El 1 de octubre Fortinet publicó un aviso de los que no admiten agenda: un fallo de 9,8 en FortiMail, explotable sin credenciales, ya explotado y sin versión corregida disponible. Lo único que había sobre la mesa era apagar una función. Las notas de la versión corregida de la rama 7.6 llevan fecha del 2 de octubre; el aviso no se actualizó para decirlo hasta el 7. Quien vigilaba el expediente, que es lo que recomienda todo el mundo, tuvo el parche publicado cinco días antes de enterarse. Y la segunda mitad del trabajo —volver a encender lo que se apagó— no suele estar escrita en ninguna parte.

Las dos fechas del mismo aviso

El expediente es FG-IR-26-175, publicado el 1 de octubre de 2026 y actualizado el 7. La vulnerabilidad es CVE-2026-104286 y Fortinet la describe así, literalmente: «An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests». En castellano llano: cualquiera que alcance el servicio web del aparato puede escribir ficheros donde no debe, sin iniciar sesión. Puntuación, 9,8 sobre 10.

Dos detalles que conviene no saltarse. El primero: lo encontró el propio equipo de seguridad de producto de Fortinet —el crédito es para Gwendal Guégniaud— y aun así el fabricante reconoce que ya estaba siendo explotado. El segundo: CISA lo metió en su catálogo de vulnerabilidades explotadas el mismo 1 de octubre, con fecha límite del 4 para la administración federal civil estadounidense. Tú no eres una agencia federal civil estadounidense, pero ese catálogo es el mejor termómetro público que existe de «esto se está usando ahora mismo».

El 1 de octubre esos tres números —8.0.2, 7.6.7 y 7.4.9— ya estaban escritos en el aviso, con la advertencia de que todavía no se habían publicado. Un expediente puede nombrar la versión que te salvará antes de que se pueda descargar.

Y ocurre también al revés, que es el dato que estructura este post. El registro de cambios de las notas de versión de FortiMail dice 2026-10-02 — Initial release of the FortiMail 7.6.7 Release Notes (compilación 858), y la 8.0.2 lleva fecha del 3 de octubre (compilación 263). El aviso no se actualizó para reconocerlas hasta el día 7. Cinco días y cuatro días de desfase, respectivamente, entre que el parche se puede descargar y que el expediente que vigilas lo dice. Si tu condición para retirar una mitigación es «cuando el aviso diga que hay parche», tu reloj va por detrás del de Fortinet.

La solución provisional apaga una función de negocio

Lo que Fortinet ofreció mientras no había parche está en el propio expediente: «Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')», o por línea de órdenes config system encryption ibe → set status disable → end. Como alternativas, quitar el acceso desde internet a la interfaz de webmail —o limitarlo solo a la red privada de confianza— o bloquear en un WAF las peticiones POST a /ibe que contengan ../.

IBE es el cifrado basado en identidad, y la documentación de FortiMail explica para qué sirve sin que haya que interpretar nada. Cuando un correo saliente encaja con una política de cifrado, el aparato lo cifra solo. Al destinatario le llega un aviso con un adjunto HTML que contiene instrucciones y enlaces; si es la primera vez, se registra en el FortiMail; si no, inicia sesión y lo lee allí, y el mensaje se descifra al abrirlo. No instala nada ni genera claves. Dicho en términos de oficina: es la vía por la que una empresa manda documentación confidencial a alguien que no está en su dominio. Una oferta, un informe, una nómina, un contrato.

Hay dos cosas que no vamos a afirmar porque la documentación pública no las resuelve y no nos vamos a inventar la respuesta. Una: qué ocurre con los avisos ya enviados cuyo destinatario todavía no había entrado al portal. Dos: qué hace el aparato con un correo que encaja con una política de cifrado mientras el servicio IBE está apagado —si lo deja pasar en claro, si lo rechaza o si lo retiene—. Las dos dependen de tu versión y de tu configuración, y las dos son la primera comprobación que haríamos en tu equipo. Si apagaste IBE la semana pasada y no has mirado esto, míralo hoy.

Las otras dos mitigaciones tampoco son gratis. Cortar el acceso desde internet al webmail apaga, de paso, el webmail que quizá use alguien. Y una regla de WAF que bloquea ../ dentro de un POST a /ibe es una conjetura razonable sobre la forma del ataque que se conoce hoy: aguanta un fin de semana y poco más.

Apagar lo decide uno; encender no lo decide nadie

Apagar es una acción de una sola persona, con prisa y sin debate: un 9,8 explotado no se discute en comité. Encender exige cuatro cosas que, una semana después, ya no están en la cabeza de nadie: saber qué se apagó exactamente, saber por qué, comprobar que la condición que lo justificaba ya no se cumple, y que alguien verifique que lo que vuelve funciona de verdad. Cuatro requisitos y cero dueños. Por eso la mitigación se queda puesta.

Hace una semana escribimos sobre el hueco de entrada: casi ninguna política de parcheo tiene redactado el caso «no hay parche», y propusimos una excepción por escrito que caduca sola a los siete días naturales para que a nadie se le quede abierta. Esa cláusula obliga a volver a mirar, pero no dice qué hay que mirar el día que toca. Ese es el hueco de salida: llega la fecha, el parche ya existe, y nadie ha dejado escrito qué se apagó ni cómo se comprueba que ha vuelto. El hueco de entrada se nota enseguida, porque alguien pregunta qué hacemos. Este no se nota nunca, porque no duele: el sistema está seguro, el ticket está cerrado y una función apagada no genera alertas. Genera un correo que no llega.

Y no es un problema de gente descuidada. En el estudio de referencia sobre grandes servicios de internet, el error de operador fue la primera causa de caídas en dos de los tres servicios analizados, y los errores de configuración la mayor categoría dentro de ese error (Oppenheimer, Ganapathi y Patterson, USENIX 2003). Una mitigación de urgencia es, por definición, un cambio de configuración hecho a mano, con prisa y fuera de la ventana habitual: la categoría que más averías provoca y la que menos rastro deja.

La ficha de mitigación temporal: seis líneas

No proponemos una herramienta ni un proceso con nombre propio. Proponemos seis líneas que se escriben el mismo día, en el ticket que ya tienes abierto, antes de cerrarlo. Van rellenas con este caso para que se vea que no es un formulario vacío.

• Qué se ha apagado, con la orden exacta. «Servicio IBE del FortiMail, config system encryption ibe → set status disable → end, el 1-10-2026 a las 18:40, por [nombre].» La orden exacta importa porque deshacerla no siempre es la misma orden al revés.
• Qué deja de funcionar y quién lo nota. «El destinatario externo no puede leer correo cifrado. Lo notan comercial y administración; no lo nota el servicio de soporte.» Si esta línea no se puede escribir es que nadie sabe para qué servía la función, y eso ya es un hallazgo.
• Por qué, con el identificador. «FG-IR-26-175 / CVE-2026-104286, 9,8, explotado, sin versión corregida el día del cambio.» Sin identificador, dentro de tres meses esto es una casilla desactivada sin motivo aparente, y nadie se atreve a tocarla.
• La condición exacta que la retira. «Cuando esta unidad corra la versión corregida de su rama o superior: 8.0.2, 7.6.7 o 7.4.9.» Una condición que se comprueba mirando el aparato. «Cuando salga el parche» no sirve, y este caso enseña por qué: el parche salió cinco días antes de que el aviso lo dijera.
• Quién la retira y quién verifica. Dos nombres distintos. Y verificar es mandar un correo que dispare la política de cifrado a una dirección externa de prueba y leerlo desde fuera, con el móvil si hace falta.
• Fecha de revisión, se cumpla o no la condición. La misma cadencia que la excepción de riesgo que propusimos la semana pasada: siete días naturales. Si el parche todavía no ha salido, la ficha se vuelve a mirar igual, aunque solo sea para confirmar por escrito que el apaño sigue siendo el mal menor.

La ficha tiene que vivir donde alguien mira: el inventario, un ticket que sigue abierto, una lista de excepciones que se revisa cada mes. En un chat de grupo no vive; se hunde en dos días y nadie vuelve a leerla.

Dos cosas que el parche no cierra

La primera, si tu FortiMail está en la rama 7.2: el aviso te manda a otra rama. «Upgrade to branch 7.4 or above», dice. Eso es un cambio de versión mayor en el aparato por el que pasa todo tu correo, con las pruebas que eso exige. Mientras tanto la mitigación es lo único que tienes, y la ficha de arriba pasa a ser la única explicación escrita de por qué tu correo cifrado lleva semanas apagado.

La segunda: si tu aparato estuvo accesible, el parche cierra la puerta pero no deshace lo que entró. Esto es una vulnerabilidad de escritura de ficheros, y lo que deja detrás es un fichero, no una sesión que caduque sola. Fortinet publicó indicadores de compromiso, y publicó bastante más de lo que suele verse: dos direcciones IP (79.141.169.187 y 45.129.0.192), entradas concretas del registro de eventos del sistema —una orden de cron lanzada como root, cierres de sesión de administrador y el alta de una cuenta de archivado apuntando a esa misma IP— y errores del registro de cifrado al descifrar IBE. Conviene saber cuál de esas cosas dura. Las IP, poco: cambiar de IP le cuesta a un atacante mucho menos que a ti revisar un sistema de ficheros. Las entradas de registro aguantan más, y son por donde empezaríamos. Ninguna de las dos es un certificado de limpieza; de eso escribimos largo en su día: parchear no es limpiar.

Lo que haríamos nosotros, y lo que no

Lo que haríamos esta semana:

• Subir a 8.0.2, 7.6.7 o 7.4.9 según la rama, y comprobar la versión en el aparato, no en el ticket.
• Retirar la mitigación con la prueba de extremo a extremo descrita arriba y dejar constancia de quién la hizo y cuándo.
• Preguntar a comercial, a administración y a quien mande documentación a terceros si han notado algo raro entre el 1 y hoy. Esa conversación suele dar más que cualquier registro.
• Si el aparato estuvo accesible desde internet, revisar ficheros y tareas programadas antes de darlo por limpio.
• Escribir la ficha de las otras mitigaciones que lleváis puestas. Siempre hay más de una, y casi nunca están en el mismo sitio.

Lo que no haríamos:

• Dejar la regla de WAF como solución definitiva. Era un apaño con fecha, y la fecha ya pasó.
• Dar por retirada una mitigación porque la casilla esté marcada. La prueba es un correo que llega y se lee.
• Volver a apagar IBE sin avisar antes a quien manda lo confidencial. Treinta segundos de aviso ahorran tres días de «no me ha llegado».
• Usar este caso para cargar contra el fabricante. Encontró el fallo en casa, publicó la solución provisional el mismo día y la corrección a los seis. Eso es hacerlo razonablemente bien; el hueco del que habla este post es nuestro, no suyo.

El fallo y la avería

En esto llevamos años insistiendo y no va a cambiar: el fallo es inevitable, la avería es una decisión de diseño. El fallo, aquí, fue el CVE, y no lo decidiste tú. La avería —una empresa que lleva días sin poder mandar documentación cifrada a sus clientes y que no sabe que no puede— sí la decides tú, el día en que apagas algo sin escribir quién lo vuelve a encender. Misma vulnerabilidad, dos resultados opuestos. Lo que los separa cabe en seis líneas de un ticket.

Fuentes y método (verificado el 9 de octubre de 2026): el texto literal de la vulnerabilidad (CWE-22 y CWE-158, escritura de ficheros sin autenticar vía HTTP/HTTPS), la puntuación 9,8, las ramas afectadas (8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8 y 7.2.0-7.2.9), las versiones corregidas 8.0.2, 7.6.7 y 7.4.9, la indicación «Upgrade to branch 7.4 or above» para la rama 7.2, el texto de la solución provisional («Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')» y las órdenes de consola), las alternativas de quitar acceso al webmail y bloquear POST a /ibe con «../», los indicadores de compromiso (las dos direcciones IP, las entradas del registro de eventos del sistema y los errores del registro de cifrado) el crédito del hallazgo a Gwendal Guégniaud del equipo de seguridad de producto de Fortinet (apartado «Acknowledgement»), y las fechas de publicación (1-oct-2026) y actualización (7-oct-2026) proceden del aviso FG-IR-26-175 del PSIRT de Fortinet. Que en la publicación inicial las versiones corregidas estaban nombradas pero no disponibles, la fórmula «reported to be exploited in the wild» sin más detalle y la inclusión en el catálogo de vulnerabilidades explotadas de CISA el 1 de octubre con fecha límite federal del 4 están en la cobertura de Help Net Security del 2-oct-2026. El funcionamiento de IBE —cifrado disparado por política, aviso al destinatario con adjunto HTML con instrucciones y enlaces, registro la primera vez, inicio de sesión las siguientes, descifrado al abrir y sin instalar software ni generar claves— procede de la documentación de administración de FortiMail. El dato sobre la causa principal de caídas en grandes servicios es de Oppenheimer, Ganapathi y Patterson, «Why Do Internet Services Fail, and What Can Be Done About It?», USENIX 2003. Lo que no sabemos: no hemos podido determinar, con documentación pública, qué ocurre con los avisos IBE ya enviados cuyo destinatario no ha entrado al portal, ni qué hace el aparato con un mensaje que encaja con una política de cifrado mientras IBE está apagado; el post lo declara como pregunta abierta y no lo afirma en ningún sentido. Tampoco sabemos cuántas organizaciones aplicaron la solución provisional ni cuántas lo han retirado ya: la afirmación de que «la mitigación sigue puesta» es nuestra lectura del patrón, no un dato medido. No hemos verificado de forma independiente la explotación activa: nos apoyamos en lo que declaran Fortinet y CISA. Las fechas de las versiones corregidas (notas de versión de FortiMail 7.6.7 del 2 de octubre de 2026, compilación 858, y 8.0.2 del 3 de octubre, compilación 263) proceden del registro de cambios de la documentación de Fortinet; la fecha de actualización del aviso (7 de octubre) procede del propio FG-IR-26-175, y el desfase entre ambas cosas es aritmética nuestra sobre esas dos fuentes. De la 7.4.9 hemos confirmado la compilación (630) pero no su fecha de publicación, así que no la damos. Los cinco días de la portada miden ese desfase documental y NO cuánto tiempo estuvo apagado ningún sistema concreto. Fotografía de portada: Process Water Building, TRA-605, detailed view of six valve handwheels in wall niche, Historic American Engineering Record (HAER ID-33-G-64), Library of Congress, dominio público, vía Wikimedia Commons.