Parchear no es limpiar: FortiOS y la barra de más

El 27 de julio, CISA añadió a su catálogo de vulnerabilidades explotadas un fallo de FortiOS que casi nadie tenía en su lista, con una fecha pegada: 10 de agosto. CVE-2025-68686 no abre ninguna puerta nueva: reabre la que Fortinet creyó cerrar en abril de 2025, y lo hace con una barra de más en la ruta. Si tienes un FortiGate que estuvo publicado en Internet con SSL-VPN entre 2022 y 2024, este aviso no va de actualizar. Va de averiguar qué se llevó alguien, y desde cuándo.

Todo empieza en una carpeta de idiomas

En abril de 2025, el equipo de seguridad de Fortinet publicó algo que se lee raro la primera vez. Alguien que había entrado en equipos FortiGate aprovechando tres vulnerabilidades ya conocidas y ya parcheadas —las de los avisos FG-IR-22-398, FG-IR-23-097 y FG-IR-24-015— dejaba detrás un enlace simbólico que conectaba el sistema de ficheros de usuario con el raíz, y lo dejaba precisamente en la carpeta desde la que el portal SSL-VPN sirve los ficheros de idioma. Esa carpeta es pública: no hace falta iniciar sesión para pedir un fichero de idioma. A partir de ahí, cualquiera que supiera la ruta tenía acceso de solo lectura a ficheros del sistema, «que pueden incluir configuraciones», en palabras del propio aviso. Solo lectura, sí; ya veremos por qué eso no consuela tanto como parece.

La frase que importa del aviso de Fortinet es la siguiente: «aunque el equipo del cliente se hubiera actualizado con versiones de FortiOS que corregían las vulnerabilidades originales, este enlace simbólico puede haber quedado ahí». Parcheaste, cerraste la entrada, y la copia de la llave se quedó fuera. La Shadowserver Foundation contó 16.620 equipos comprometidos a 16 de abril de 2025, después de un primer recuento de unos 14.000. Fortinet sacó una firma de antivirus/IPS que borra el enlace y unas versiones de FortiOS que además impiden que el portal sirva enlaces así, y pidió a sus clientes algo que se dice fácil y se hace muy poco: tratar toda la configuración como potencialmente comprometida.

Sin malware, sin implante, sin binario extraño y sin conexión a un centro de mando que un NetFlow pueda pillar: un fichero que apunta a otro sitio, una función legítima del sistema de ficheros usada donde no toca. Por eso durante meses nadie lo vio. No había nada raro que ver.

El parche era una comparación de cadenas

El investigador Peter Gabaldón, de ITRESIT, en lugar de dar el parche por bueno, lo abrió. La comprobación nueva se apoyaba en la función strstr buscando el texto /lang/custom dentro de la ruta pedida. Si el texto estaba, se validaba a dónde apuntaba el enlace y se bloqueaba lo que no tocara. Si no estaba, la petición seguía su camino. El problema es que el sistema de ficheros y la ruta escrita no son la misma cosa.

.../lang/custom/...    strstr("/lang/custom") -> coincide      -> se valida el enlace -> bloqueado
.../lang//custom/...   strstr("/lang/custom") -> no coincide   -> no se valida nada  -> 200 OK
# para el sistema de ficheros las dos rutas son el mismo directorio;
# para una comparación de texto son dos cadenas distintas.

Una barra de más. Este no es un despiste exótico: es el patrón que falla en seguridad web desde siempre, el de validar el texto que llega por el cable en lugar de validar el objeto al que ese texto acaba resolviendo. Es la familia del salto de directorio, de las listas negras de un WAF y de la mitad de los sustos que nos llevamos los que escribimos código. La lección es de arquitectura y cabe en una línea: se valida después de normalizar, o se valida el destino real —¿a dónde apunta este enlace?— y no la cadena.

La cronología que publica el propio investigador merece leerse despacio. Encontró el salto el 26 de abril de 2025, o sea el mismo mes del aviso original y analizando el parche recién salido. Lo reportó al equipo de seguridad de Fortinet el 9 de octubre de 2025. El parche corregido salió el 10 de febrero de 2026 y la divulgación pública, al día siguiente. Y CISA no lo puso en el catálogo de vulnerabilidades explotadas hasta el 27 de julio de 2026. Quince meses entre que alguien vio el agujero y que la cosa se convirtió en una fecha límite. Y conviene ser preciso con lo que eso significa: aquellas versiones de abril de 2025 también borraban el enlace y añadían una firma de antivirus para quitarlo, así que muchos equipos quedaron limpios. Lo que no funcionaba durante esos quince meses era la barrera: allí donde el enlace seguía puesto —o volvía a ponerse—, el portal lo servía igual a quien pidiera la ruta con una barra de más.

El mismo investigador escaneó 3.503 FortiGate expuestos en Internet y encontró 144 todavía comprometidos (un 4,11%), mientras que 787 llevaban ya el firmware con la comprobación de integridad. Es una muestra tomada por una persona, no un censo, y conviene leerla como tal. Pero cuatro de cada cien no es una anécdota.

La letra pequeña: si estás en 7.2, 7.0 o 6.4, no hay parche para ti

La tabla del aviso FG-IR-25-934 dice esto: afectadas las versiones 7.6.0 a 7.6.1 (se corrige subiendo a 7.6.2 o superior) y 7.4.0 a 7.4.6 (a 7.4.7 o superior). Y para las ramas 7.2, 7.0 y 6.4, «todas las versiones», con una solución que en la tabla ocupa una línea: migrate to a fixed release. Traducido: en esas ramas no hay parche. Hay que saltar de rama.

Un salto de rama es ventana de mantenimiento, revisar qué funciones cambian de comportamiento al otro lado, comprobar que los túneles y las políticas siguen haciendo lo mismo y, a veces, descubrir que el modelo que tienes no llega a la rama que necesitas. Nada de eso se hace un martes a las seis. Y hay mucha gente en 7.2 a propósito, por estabilidad, porque le funciona y porque cada salto le ha traído algún susto. Es una decisión defendible: quedarse en una rama madura en vez de perseguir la última suele salir bien. Lo que casi nunca se escribe al lado de esa decisión es su fecha de caducidad. Este aviso es esa fecha.

Hay un detalle que conviene poner encima de la mesa porque cambia la lectura. La corrección de abril de 2025 sí llegó a esas ramas: las versiones que Fortinet publicó entonces fueron 7.6.2, 7.4.7, 7.2.11, 7.0.17 y 6.4.16. La del bypass, no. Quien en su día actualizó a 7.2.11 —hizo justo lo que le pidieron— lleva desde febrero de 2026 con el portal capaz de servir el enlace si allí hubiera uno, y sin una versión de su rama a la que ir.

Antes de planificar nada, tres cosas se pueden mirar hoy mismo y sin tocar la configuración: qué versión exacta corre cada equipo (la tabla del aviso decide, no la sensación de estar al día); si la firma de antivirus/IPS que Fortinet publicó en abril de 2025 para detectar y borrar el enlace está aplicada y al día; y si el portal SSL-VPN es alcanzable desde Internet o solo desde donde debería. Son tres datos, no tres opiniones, y con ellos ya se puede ordenar el trabajo. Lo que no se deduce del número de versión es si aquel equipo llegó a tener el enlace puesto: eso se pregunta al soporte del fabricante con el fichero de diagnóstico delante.

El mito: «ya lo hemos actualizado»

Nada de esto va ya de Fortinet. Actualizar es una acción; estar limpio es una conclusión. La primera se hace en una ventana de media hora y se apunta en el parte de trabajo. La segunda necesita pruebas, y las pruebas cuestan horas de alguien mirando registros. Cuando un equipo perimetral aparece en un aviso, casi todas las organizaciones hacen la acción y se ahorran la conclusión, porque la acción se puede enseñar en un comité y la conclusión no tiene casilla en ningún cuadro de mando.

Lo llamativo es que las dos fuentes oficiales de este caso dicen justo lo contrario. Fortinet pide tratar toda la configuración como potencialmente comprometida. Y la ficha del KEV de CISA, en el apartado de acción requerida, no se queda en «aplique el parche»: remite explícitamente a sus requisitos de triaje forense. El catálogo no te está pidiendo que actualices. Te está pidiendo que mires.

La puntuación —5,9 de base, la que ya citamos ayer de pasada— es baja por una razón razonable: para aprovechar esto, el atacante tiene que haber entrado antes por otro sitio. En 16.620 equipos, esa condición previa dejó de ser hipótesis en abril de 2025.

Qué se pierde cuando se pierde la configuración

Aquí es donde el «solo lectura» deja de consolar. La configuración de un firewall perimetral es el mapa de la casa con las llaves pegadas con celo: usuarios locales y sus hashes, claves compartidas de los túneles IPsec, la credencial con la que el equipo consulta el directorio corporativo, certificados, direccionamiento interno, qué servicio está publicado y hacia dónde. Leerla basta. Con eso en la mano no hace falta volver a entrar por el firewall: se entra por donde entra todo el mundo, con una credencial válida, a una hora normal. Y eso, en los registros, se parece muchísimo a un empleado trabajando. Es el mismo criterio con el que miramos los zero-days de un concentrador VPN la semana pasada.

Y aquí toca decir algo que no favorece a quien vende lo que vendemos nosotros: un EDR no corre dentro de tu FortiGate. En un appliance cerrado no hay agente que instalar; el aparato es, por diseño, un punto ciego. Lo que sí se puede hacer es cambiar la premisa —esa configuración lleva desde 2025, como mínimo, fuera de tu control— y vigilar el resto: credenciales de servicio usándose a horas que no cuadran, autenticaciones de VPN desde sitios nuevos, cuentas locales del propio firewall que nadie recuerda haber creado, un salto lateral desde el equipo de alguien que nunca había tocado ese servidor. Eso sí se ve, y se ve dentro. La diferencia entre tener registros y que alguien los mire es la misma de la que hablábamos esta mañana sobre las alertas que nadie atiende: una alerta sin dueño no es una defensa, es un registro.

La pregunta que hacemos en una auditoría

No es «¿está parcheado?». Esa la contesta un inventario. La que sirve es ¿qué sabía tu firewall que ya no es un secreto? Si el equipo estuvo publicado con SSL-VPN entre 2022 y 2024, si nadie ha rotado nada desde entonces y si la respuesta a «¿quién revisó los registros aquella semana?» es un silencio, la respuesta honesta es: todo.

Un parche cierra una puerta y se puede enseñar. Limpiar es otro trabajo: más largo, más aburrido, sin nota CVSS que lo defienda en una reunión de presupuesto y sin ningún momento claro en el que puedas decir que ya está. Por eso casi nunca se hace. Y por eso, cuatro de cada cien equipos de aquella muestra seguían con el enlace puesto.

Fuentes (verificadas): alta de CVE-2025-68686 en el catálogo de vulnerabilidades explotadas el 27-07-2026, plazo del 10-08-2026, descripción y acción requerida con remisión a los requisitos de triaje forense: CISA, Known Exploited Vulnerabilities Catalog. Aviso del fabricante FG-IR-25-934, «SSL-VPN Symlink Persistence Patch Bypass» (publicado 10-02-2026, actualizado 12-03-2026): versiones afectadas y corregidas, CVSS 5,3 con métricas temporales, crédito a Peter Gabaldón (ITRESIT). Puntuación base 5,9 aportada por Fortinet como CNA: NVD. Enlace simbólico en la carpeta de ficheros de idioma del SSL-VPN, persistencia tras actualizar, CVEs de entrada, firma AV/IPS, versiones publicadas entonces (7.6.2, 7.4.7, 7.2.11, 7.0.17 y 6.4.16) y recomendación de tratar la configuración como comprometida: Fortinet PSIRT, abril de 2025. Recuento de 16.620 equipos por Piotr Kijewski (Shadowserver Foundation) a 16-04-2025: BleepingComputer. Análisis técnico del bypass con la doble barra, cronología de la divulgación y escaneo de 3.503 equipos con 144 comprometidos: Labs at ITRES, 11-02-2026. El criterio de revisión, la lectura del caso y las opiniones son nuestros.