Inyección SQL crítica en Fortinet FortiClientEMS: análisis y mitigación

Informatec Digital » Recursos » Inyección SQL crítica en Fortinet FortiClientEMS: análisis y mitigación

La seguridad de las plataformas de gestión de endpoints se ha convertido en un punto crítico para muchas empresas, y el último ejemplo claro lo estamos viendo con Fortinet y su solución FortiClient Endpoint Management Server (EMS). En los últimos meses se ha destapado una vulnerabilidad de inyección SQL catalogada como crítica que afecta a una versión muy concreta del producto y que está generando bastante ruido en la comunidad de ciberseguridad.

En este artículo vamos a desgranar con calma qué está pasando con la inyección SQL crítica en Fortinet, cómo funciona el fallo CVE-2026-21643, qué impacto real tiene sobre las organizaciones, cómo se está explotando en la práctica y, sobre todo, qué medidas urgentes y a medio plazo deberías aplicar si gestionas infraestructuras basadas en FortiClientEMS o productos similares.

Contexto de la vulnerabilidad CVE-2026-21643 en FortiClientEMS

La vulnerabilidad CVE-2026-21643 se ha catalogado como crítica, con una puntuación CVSS que oscila entre 9.1 y 9.8 según distintas fuentes, lo que la sitúa prácticamente en el máximo nivel de gravedad. El fallo reside en FortiClient Endpoint Management Server (EMS), la plataforma que las empresas utilizan para desplegar y administrar agentes FortiClient en sus flotas de equipos de usuario.

En concreto, el problema afecta a FortiClientEMS versión 7.4.4 de la rama 7.4 cuando el modo multi-tenant (funcionalidad de “Sites”) está activado. Las versiones 8.0 y 7.2, así como las instancias FortiEMS Cloud, no se ven afectadas por este bug, por lo que Fortinet ha centrado todas las recomendaciones de mitigación en los entornos que aún utilizan la 7.4.4 on‑premise.

Esta inyección SQL se produce por una neutralización incorrecta de elementos especiales en sentencias SQL, clasificada bajo CWE-89. En la práctica, permite a un atacante remoto no autenticado enviar peticiones HTTP especialmente manipuladas y conseguir que el servidor ejecute comandos SQL arbitrarios, lo que puede terminar en ejecución remota de código (RCE) con los privilegios del usuario de la base de datos.

Los avisos de seguridad de Fortinet señalan que el fallo se encuentra en el componente GUI de FortiClientEMS, es decir, en la parte web que los administradores utilizan para gestionar y monitorizar endpoints. Esto implica que cualquier instancia con la interfaz accesible desde Internet se convierte en un objetivo muy jugoso para los atacantes.

Cómo se origina la inyección SQL crítica en Fortinet

La raíz del problema está ligada a una refactorización importante del middleware en FortiClientEMS 7.4.4. Durante esta revisión del código, los desarrolladores cambiaron la forma en la que la aplicación gestiona las conexiones a la base de datos PostgreSQL y el enrutamiento de tenants, introduciendo sin querer un fallo en el archivo de conexión.

En esta nueva lógica, el servidor pasa directamente el header HTTP Site a una consulta search_path de PostgreSQL. El objetivo era seleccionar el esquema correspondiente a cada tenant en función de este encabezado, pero el gran problema es que el middleware no realiza una validación ni sanitización correctas de ese valor.

Como consecuencia, un atacante puede romper el formato de cadena previsto y colar su propia carga maliciosa en la sentencia SQL, inyectando comandos arbitrarios que la base de datos ejecutará con los altos privilegios que tiene configurados el usuario de servicio dentro de la máquina virtual de Fortinet.

El riesgo se dispara todavía más porque este middleware vulnerable se ejecuta antes de cualquier verificación de autenticación. Es decir, no hace falta iniciar sesión ni disponer de credenciales: basta con enviar una petición HTTPS manipulada con el header Site modificado para intentar explotar el fallo.

Este patrón encaja perfectamente con un escenario CVSS 3.1 de AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, donde el ataque llega vía red, tiene baja complejidad, no requiere privilegios previos ni interacción del usuario y compromete de forma completa la confidencialidad, integridad y disponibilidad del sistema afectado.

Vector de ataque: endpoint /api/v1/init_consts y cabecera Site

Investigadores de seguridad, como el equipo de Bishop Fox, han explicado que el vector de ataque más práctico se encuentra en el endpoint accesible públicamente /api/v1/init_consts, una ruta de la API de FortiClientEMS utilizada durante la inicialización de la interfaz.

Los atacantes pueden usar primero este endpoint para comprobar si el modo multi-tenant está activado. Si descubren que la funcionalidad de Sites está habilitada, pasan a inyectar payloads SQL a través de la cabecera HTTP Site, aprovechando que el valor se pasa sin limpieza a la sentencia search_path.

Este endpoint tiene varios problemas de diseño: por un lado, no cuenta con mecanismos de rate limiting ni defensas específicas contra fuerza bruta; por otro, devuelve directamente en el cuerpo de la respuesta los mensajes de error generados por PostgreSQL. Esto facilita enormemente la vida al atacante.

Al recibir esos errores de forma tan explícita, un actor malicioso puede llevar a cabo técnicas de extracción basada en errores en una sola petición, sin necesidad de recurrir a inyecciones basadas en tiempo, mucho más lentas. De este modo, la enumeración de tablas, columnas y datos sensibles puede ser extremadamente rápida.

Si la explotación tiene éxito, el atacante llega a un escenario de compromiso total de la base de datos de gestión de endpoints. Dado que el usuario de la base corre con privilegios de superusuario de PostgreSQL, no solo puede exfiltrar información, sino también escalar hasta la ejecución remota de código en el sistema operativo subyacente.

Impacto real sobre la organización y los endpoints gestionados

El impacto de esta vulnerabilidad va mucho más allá de una simple filtración de datos. La capacidad de ejecutar SQL arbitrario sobre la base de datos de FortiClientEMS permite a los atacantes robar contraseñas de administradores, certificados digitales e inventarios completos de dispositivos conectados a la plataforma.

Con ese nivel de acceso, un actor de amenazas puede modificar políticas de seguridad y distribuir configuraciones maliciosas a todos los endpoints gestionados. Esto abre la puerta a escenarios complejos en los que los propios agentes de seguridad de la organización se convierten en un vector de ataque hacia la red interna.

Además, el compromiso de la base de datos de gestión también afecta a la confidencialidad de los datos almacenados (por ejemplo, información sobre usuarios, equipos, políticas y certificados), a la integridad (alteración de reglas, plantillas y asignaciones) y a la disponibilidad (posible borrado de datos o sabotaje del servidor de administración).

Esta amenaza encaja con la tendencia cada vez más habitual de ataques contra dispositivos de borde y sistemas de gestión, muy valorados por los ciberdelincuentes porque funcionan como concentradores de información y control sobre grandes volúmenes de endpoints.

Por todo lo anterior, Fortinet ha clasificado esta vulnerabilidad como crítica y las agencias y firmas de seguridad recomiendan tratar cualquier instancia FortiClientEMS 7.4.4 expuesta como un activo de máximo riesgo hasta que se demuestre lo contrario.

Explotación activa y superficie de exposición

Aunque en un primer momento algunos reportes indicaban que no se había detectado explotación activa, investigadores de la firma Defused confirmaron ataques reales aprovechando la CVE-2026-21643 tan solo cuatro días antes de que se hiciera público el fallo.

Datos recopilados por organizaciones como Shadowserver muestran que unas 2.000 instancias de FortiClientEMS estaban expuestas directamente a Internet en el momento del monitoreo. Estados Unidos lideraba la estadística con alrededor de 756 servidores vulnerables, seguido de Europa con más de 680. Shodan también detectaba más de 1.000 interfaces web de FortiClientEMS accesibles públicamente, muchas probablemente sin parchear.

El registro oficial de NIST para CVE-2026-21643 respalda esta gravedad extrema, mostrando un vector AV:N/AC:L/PR:N/UI:N con impacto alto en C, I y A. Esto implica que cualquier servidor FortiClientEMS 7.4.4 cuya interfaz web esté abierta hacia Internet puede ser tomado por completo sin que el atacante necesite credenciales ni tenga que convencer a ningún usuario para que haga clic en nada.

Defused reportó estas explotaciones el 28 de marzo, señalando además que, pese a ello, la vulnerabilidad todavía no figuraba en el catálogo KEV (Known Exploited Vulnerabilities) de CISA ni en otras listas públicas de fallos explotados de forma activa, algo que suele ocurrir en estas ventanas iniciales de explotación.

Por otro lado, Fortinet había publicado ya el parche correctivo en febrero con la versión 7.4.5, lo que deja claro el patrón recurrente en ciberseguridad: existe una brecha temporal importante entre la disponibilidad del fix y su despliegue real en producción, periodo durante el cual los atacantes aprovechan para comprometer sistemas que siguen sin actualizar.

Indicadores de compromiso y señales de ataque

Para los administradores que gestionan FortiClientEMS, es clave conocer qué pistas deja un posible intento de explotación. Entre los principales indicadores de compromiso (IoC) se encuentran los siguientes:

En primer lugar, destacan los tiempos de respuesta inusualmente largos, de entre 5 y más de 20 segundos, en los endpoints /api/v1/auth/signin o /api/v1/init_consts, según se observa en los logs de acceso de Apache u otro servidor web que haya delante.

También es una señal de alerta ver respuestas HTTP 500 repetidas desde la misma dirección IP contra el endpoint /api/v1/init_consts. Este patrón puede indicar que un atacante está ajustando sus cargas de inyección SQL mediante ensayo y error hasta conseguir una que funcione y no genere errores.

Además, en los logs de errores de PostgreSQL conviene buscar consultas search_path con comillas simples, punto y coma o palabras clave SQL como SELECT, INSERT o UPDATE fuera del contexto esperado. Este tipo de rastro suele apuntar directamente a un intento de manipulación del header Site.

Como medida de respuesta, cualquier servidor FortiClientEMS 7.4.4 que haya estado expuesto a Internet sin las actualizaciones adecuadas debe tratarse como potencialmente comprometido. Esto implica aislarlo de la red, realizar un análisis forense detallado (base de datos, sistema operativo y logs) y plantear una reconstrucción controlada del entorno si se encuentran evidencias de intrusión.

Mitigación inmediata y solución oficial de Fortinet

La principal medida de mitigación es clara: actualizar FortiClientEMS 7.4.4 a la versión 7.4.5 o superior lo antes posible. Fortinet solucionó el fallo sustituyendo la interpolación de cadenas en la query por un manejo correcto de identificadores parametrizados y escapando de forma segura la entrada procedente del header Site.

Las versiones 8.0 y 7.2, así como FortiEMS Cloud, no requieren acciones adicionales, ya que no están afectadas por esta vulnerabilidad concreta. Aun así, no está de más revisar su exposición a Internet y sus configuraciones de acceso, porque la superficie de ataque de las consolas de administración siempre debe ser mínima.

Para aquellos equipos que, por motivos operativos, no puedan aplicar el parche de forma inmediata, algunos investigadores recomiendan una mitigación temporal: desactivar la funcionalidad multi-tenant “Sites”. Esta acción evita que se ejecute la ruta de código vulnerable ligada al header Site, reduciendo notablemente las opciones de explotación.

De igual modo, es esencial restringir el acceso web a la interfaz de gestión de EMS solo a redes internas de confianza. Lo ideal es colocar la consola detrás de una VPN o de un mecanismo de acceso cero confianza, y nunca dejarla expuesta directamente a Internet salvo casos muy excepcionales y debidamente protegidos.

Como complemento, se aconseja revisar y endurecer las reglas de firewall y cualquier WAF que tengamos delante de FortiClientEMS, aplicando filtros que bloqueen patrones típicos de inyección SQL en cabeceras HTTP, especialmente en el header Site, y monitorizando de cerca cualquier petición anómala a la API.

Buenas prácticas de seguridad más allá del parche

Más allá de aplicar el parche y las mitigaciones específicas, este incidente deja claro que la gestión de vulnerabilidades debe ser un proceso continuo y no solo una reacción puntual ante un advisory de un fabricante. Las organizaciones que dependen de plataformas de gestión de endpoints y soluciones de seguridad de red deberían reforzar su estrategia en varios frentes.

Por un lado, es imprescindible contar con un inventario actualizado de activos y versiones, de forma que cuando se publica una CVE crítica sea posible identificar en minutos qué sistemas son vulnerables y priorizar su actualización según el nivel de exposición y criticidad.

Por otro, conviene apostar por pruebas de penetración periódicas y revisiones de arquitectura que validen no solo la robustez del producto en sí, sino también cómo está desplegado: segmentación de redes, separación de planos de gestión, restricciones de acceso, monitorización centralizada de logs y detección de comportamientos anómalos.

En el plano del desarrollo, este caso vuelve a demostrar la importancia de aplicar prácticas de desarrollo seguro y pruebas de regresión cada vez que se hace una refactorización profunda del middleware o de componentes críticos. Una mejora de rendimiento o escalabilidad no puede ir acompañada de un retroceso en mecanismos tan básicos como la sanitización de entradas.

Empresas especializadas en ciberseguridad y desarrollo seguro ofrecen servicios de auditoría de código, pentesting y consultoría orientados precisamente a detectar estos vectores antes de que lleguen a producción. En entornos donde se combinan infraestructura on‑premise, cloud y dispositivos de borde, apoyarse en expertos externos suele marcar la diferencia.

Por último, a nivel de gobierno y negocio, resulta muy útil contar con cuadros de mando e inteligencia de negocio que permitan visualizar el estado de las vulnerabilidades, la exposición de las interfaces de administración y el impacto potencial de un fallo crítico sobre los procesos de la organización. Este enfoque facilita priorizar inversiones y justificar medidas preventivas que, a priori, pueden parecer costosas, pero que ahorran muchos problemas a medio plazo.

La combinación de un fallo de diseño grave, una superficie de exposición amplia y la demora habitual en la aplicación de parches convierte a CVE-2026-21643 en un caso de libro sobre cómo no se debe subestimar la protección de las consolas de gestión. Cualquier organización que utilice FortiClientEMS o soluciones similares debería tomar este incidente como un toque de atención para revisar su postura de seguridad, acelerar sus ciclos de actualización y reforzar las defensas alrededor de sus plataformas de administración antes de que otro cero-day o una nueva inyección SQL vuelva a ponerlas contra las cuerdas.

Artículo relacionado:

Inyección SQL: Qué es, cómo funciona, ejemplos y claves para proteger tus datos