CVE-2026-35616 en FortiClient EMS, cómo funciona el bypass de autenticación y qué hacer ahora

CVE-2026-35616 es una vulnerabilidad de FortiClient EMS activamente explotada en una parte de la pila que los defensores ya deberían tratar como infraestructura de alto valor. Fortinet dice que el problema afecta a FortiClient EMS 7.4.5 a 7.4.6, que 7.2 no se ve afectada, que FortiClient Cloud y FortiSASE ya han sido remediados por parte del proveedor, y que 7.4.7 contiene la solución permanente. NVD también muestra la falla en el catálogo de Vulnerabilidades Explotadas Conocidas de CISA, con una fecha límite de remediación federal del 9 de abril de 2026. (Laboratorios FortiGuard)

Ese breve resumen ya te dice por qué esto no es un problema de "parchéalo cuando acabe el fin de semana". FortiClient EMS no es sólo un panel de control. Es el plano de control para la política de punto final, la configuración de acceso remoto, la gestión de clientes vinculada a la telemetría y la administración continua de los sistemas conectados a FortiClient. Una vulnerabilidad en este caso recae en una superficie de gestión con influencia sobre un gran número de puntos finales, no en un nodo de utilidad desechable con poca autoridad aguas abajo. (docs.fortinet.com)

Los escritos públicos describen el problema en un lenguaje ligeramente diferente. Fortinet y la entrada NVD describen un defecto de control de acceso inadecuado que puede permitir a un atacante no autenticado ejecutar código o comandos no autorizados a través de solicitudes falsificadas. El análisis técnico independiente va más allá y muestra por qué muchos investigadores lo están tratando como un compromiso práctico de preautenticación del plano de gestión EMS: la aplicación confiaba en cabeceras HTTP falsificables como si fueran señales de certificado de cliente TLS de confianza, y la propia lógica de validación de la cadena de certificados realizaba comprobaciones de cadenas sin verificación de firma X.509 real. (nvd.nist.gov)

CVE-2026-35616 de un vistazo

El expediente público confirmado es lo suficientemente compacto como para resumirlo antes de profundizar en él.

Artículo	Estado actual confirmado
Vulnerabilidad	CVE-2026-35616
Producto	FortiClient EMS
Versiones afectadas	7.4.5 a 7.4.6
No afectados	7.2 rama
Estado de la nube	FortiClient Cloud reparado por Fortinet, ninguna acción por parte del cliente; FortiSASE reparado por Fortinet, ninguna acción por parte del cliente.
Estado de explotación	Fortinet dice que ha observado la explotación en la naturaleza
Estado de la revisión	Correcciones publicadas para 7.4.5 y 7.4.6
Fijación permanente	Incluido en 7.4.7
Estado de KEV	En CISA KEV
Fecha límite CISA	9 de abril de 2026

Esta tabla se ha extraído del aviso de Fortinet y de las notas de la versión, junto con la entrada vinculada a NVD KEV. (Laboratorios FortiGuard)

Hay otra razón para leer más allá del resumen del titular. Los metadatos públicos no están perfectamente ordenados. El resumen del aviso de Fortinet dice que el problema ha sido explotado en la naturaleza, sin embargo, el bloque de metadatos del aviso todavía muestra "Known Exploited No". El aviso también muestra un valor CVSS de 9,1, mientras que la página NVD muestra actualmente el vector CNA de Fortinet como 9,8 crítico. Este desajuste no hace que el problema sea menos urgente. Sí subraya una lección operativa recurrente: cuando se está desarrollando un día cero, los detalles que más importan son las versiones afectadas, los supuestos de exposición, las mitigaciones disponibles y si se confirma la explotación activa. En este caso, esos puntos ya están lo suficientemente claros como para justificar una acción inmediata. (Laboratorios FortiGuard)

El informe de WatchTowr añade un punto más que es importante para los defensores: sus sensores Attacker Eye observaron la explotación el 31 de marzo de 2026, antes del aviso público de Fortinet del 4 de abril. Esto significa que algunos entornos pueden haber estado expuestos durante días antes incluso de que comenzara la actividad de aplicación de parches en las organizaciones afectadas. Si su instancia EMS fue accesible durante esa ventana, la mentalidad correcta es la respuesta a incidentes con remediación, no la gestión de parches con curiosidad. (watchTowr)

Por qué un compromiso de FortiClient EMS es más grave que un fallo de gestión normal

La documentación del proveedor es útil aquí porque define el radio de explosión en términos operativos sencillos. FortiClient EMS es el sistema de gestión centralizado para múltiples puntos finales, proporciona visibilidad de la red, asigna políticas de seguridad, despliega FortiClient de forma remota, actualiza los perfiles de usuario independientemente de su ubicación, administra las conexiones de los puntos finales y gestiona el estado de los puntos finales y la información de firmas. Eso ya es suficiente para sacar la discusión de la estrecha categoría de "un mal error Web en un appliance". (docs.fortinet.com)

La superficie de perfiles bajo control de EMS tampoco es trivial. La propia guía de administración de Fortinet muestra perfiles de punto final para Acceso Remoto, Destinos ZTNA, Filtro Web, Filtro de Vídeo, Exploración de Vulnerabilidades, Protección contra Malware, Sandbox, Cortafuegos y Configuración del Sistema. En otras palabras, la plataforma se encuentra en medio de la postura de acceso remoto, el comportamiento de control de contenido, la política de malware, la configuración del cortafuegos y la configuración del sistema de punto final. Un compromiso del servidor de gestión no es sólo un compromiso del servidor. También es un problema de integridad de políticas. (docs.fortinet.com)

El modelo de despliegue y actualización aumenta esa ventaja. Fortinet documenta que una vez que FortiClient y EMS establecen una conexión de telemetría, EMS puede enviar actualizaciones de FortiClient a los terminales. La misma documentación también describe múltiples rutas de inscripción y despliegue, incluyendo paquetes de despliegue, flujos MDM y onboarding basado en invitación. Una vez que un sistema se ha convertido en la política de confianza y la autoridad de actualización para una gran flota de puntos finales, el compromiso de ese sistema tiene un significado operativo muy diferente al compromiso de una aplicación interna independiente. (docs.fortinet.com)

La API importa por la misma razón. La documentación de Fortinet afirma que la API FortiClient EMS permite operaciones de configuración en EMS. Por este motivo, un desvío de autenticación de la capa API es tan grave, incluso antes de que nadie discuta sobre la etiqueta exacta que debe asignarse al impacto posterior al desvío. Si se puede acceder a la API de gestión y se pueden suplantar o eludir controles de confianza, el atacante no se limita a leer datos. El atacante está entrando en un sistema diseñado para configurar otros sistemas. (docs.fortinet.com)

Un detalle operativo más hace que la cuestión de la exposición sea dolorosamente concreta. Fortinet documenta una función de "Acceso HTTPS remoto" que, cuando está activada, permite a los administradores utilizar un navegador y HTTPS para iniciar sesión en EMS. En la misma página se indica que los administradores pueden desactivar esta función y limitar el acceso al propio servidor. Esto significa dos cosas a la vez: en primer lugar, existe una ruta compatible para la administración remota basada en navegador; en segundo lugar, si la interfaz es ampliamente accesible es una opción de despliegue que afecta directamente al riesgo en el mundo real. (docs.fortinet.com)

Lo que Fortinet ha confirmado y lo que la información pública sigue sin confirmar

El aviso de Fortinet es directo en los puntos principales. Describe CVE-2026-35616 como una vulnerabilidad de control de acceso inadecuado en FortiClient EMS que puede permitir a un atacante no autenticado ejecutar código o comandos no autorizados a través de solicitudes manipuladas. Dice Fortinet ha observado la explotación en la naturaleza. Dice que las versiones 7.4.5 a 7.4.6 están afectadas, que la 7.2 no lo está, que FortiClient Cloud y FortiSASE fueron corregidas por el proveedor, y que la 7.4.7 incluye la corrección mientras que la revisión publicada es suficiente mientras tanto. Estos son los hechos a los que hay que atenerse. (Laboratorios FortiGuard)

La entrada NVD se alinea con las versiones afectadas, la naturaleza no autenticada, la clasificación CWE-284 y la descripción básica del impacto. Lo que es más importante para la priorización, la página NVD muestra el problema en el KEV de CISA, con la fecha añadida como 6 de abril de 2026 y la fecha de vencimiento como 9 de abril de 2026. En la práctica, el estado KEV es más valioso que un argumento CVSS marginal porque te dice que el problema ha cruzado el umbral de "teóricamente grave" a "activamente relevante para atacantes reales". (nvd.nist.gov)

Lo que el registro público todavía puede oscurecer es cómo los defensores deben interpretar el efecto. Algunos artículos simplifican la cuestión en "Fortinet auth bypass". Otros lo simplifican en "RCE no autenticado". La lectura más precisa es la siguiente: la redacción oficial del proveedor dice código o comandos no autorizados a través de peticiones falsificadas, mientras que el trabajo independiente de ingeniería inversa muestra una ruta de acceso a la API autenticada a través de señales de autenticación de certificados falsificadas y una validación defectuosa de la cadena de certificados. En un producto diseñado para configurar la política de punto final y los controles de seguridad relacionados, eso ya es suficiente para ser tratado como un compromiso importante del plano de gestión. El hecho de que llame al estado final ejecución de comandos, ejecución remota de código o compromiso de API privilegiada no debería cambiar su prioridad de respuesta. (Laboratorios FortiGuard)

Otro error sutil en la discusión inicial fue tratar cada despliegue de "FortiClient EMS" como igualmente en riesgo. Eso no es lo que dijo Fortinet. EMS 7.4.5 y 7.4.6 son las versiones afectadas. FortiClient Cloud y FortiSASE fueron remediados por parte del proveedor y no requieren la acción del cliente para este problema, de acuerdo con el aviso. Esa distinción es importante porque los avisos internos apresurados a menudo aplanan los nombres de las familias de productos en una sola frase de pánico y luego envían a los equipos a la caza en los lugares equivocados. (Laboratorios FortiGuard)

Cómo funciona CVE-2026-35616 en FortiClient EMS

La explicación técnica pública más sólida hasta el momento procede del parche y el análisis de código de Bishop Fox, y hace que la vulnerabilidad deje de ser un vago aviso para convertirse en una lección de arquitectura específica. FortiClient EMS utiliza Apache con mod_ssl delante de una aplicación Django. En un diseño normal de cliente-certificado TLS, Apache rellena variables de entorno WSGI de confianza como SSL_CLIENT_VERIFY y SSL_CLIENT_CERTy la aplicación lee esos valores de confianza. El problema aquí era que el middleware de Django también aceptaba valores equivalentes de cabeceras HTTP controladas por el usuario. (Obispo Fox)

El primer error crítico fue la puerta de autenticación. De acuerdo con la descompilación de Bishop Fox, el código trataba una solicitud como portadora de certificado si la entidad de confianza SSL_CLIENT_VERIFY variable era ÉXITO o el mapa de Django HTTP_X_SSL_CLIENT_VERIFY valor era ÉXITO. Ese segundo valor es directamente controlable por cualquier cliente que envíe la cabecera HTTP X-SSL-CLIENT-VERIFY. En otras palabras, una señal que sólo debería haber existido dentro de un límite de confianza entre proxy y aplicación fue aceptada desde el mundo exterior. (Obispo Fox)

El segundo error crítico fue aún más perjudicial. La lógica de procesamiento de certificados de la aplicación daba prioridad a HTTP_X_SSL_CLIENT_CERTque no es más que la representación en Django de un fichero X-SSL-CLIENT-CERT sobre las variables de confianza de Apache que se suponía que llevaban el material real del certificado del cliente. Una vez que la primera comprobación permitía que la petición cruzara la puerta, los datos del certificado en sí también podían proceder de una cabecera falsificable. Esto no es sólo un "bypass de autenticación" en abstracto. Es un colapso del límite de confianza entre el proxy inverso y la lógica de la aplicación. (Obispo Fox)

Luego está el problema de la validación de la cadena de certificados. Bishop Fox descubrió que validar_cadena_certificado() sólo comparó las cadenas de nombres distinguidos de asunto y emisor con las CA raíz de Fortinet incrustadas. No realizó una verificación de firma criptográfica X.509. Esto significa que el código no probaba realmente una relación de firma real a través de la cadena. Sólo comprobaba si los nombres parecían correctos. En términos de seguridad, esa es la diferencia entre verificar una cadena de confianza y reconocer un disfraz. (Obispo Fox)

Por este motivo, la causa principal debe considerarse como dos fallos de diseño independientes que se produjeron al mismo tiempo. El primer fallo fue confiar en cabeceras HTTP externas que imitaban metadatos TLS internos. El segundo fallo fue tratar la estructura de la cadena de certificados como suficiente, sin verificar la firma. Cualquiera de las dos soluciones habría elevado el listón. Juntas, su ausencia convirtió la autenticación de dispositivos basada en certificados en algo que un atacante remoto no autenticado podría falsificar desde el lado equivocado del límite de confianza. (Obispo Fox)

El análisis de remediación de Bishop Fox también ayuda a explicar qué es y qué no es el hotfix de Fortinet. Según ese análisis, el hotfix añade Apache RequestHeader no establecido para eliminar cabeceras falsificables como X-SSL-CLIENT-VERIFY y X-SSL-CLIENT-CERT antes de que lleguen a Django. Es una medida de emergencia efectiva porque restaura el límite proxy/aplicación. Pero Bishop Fox también señala que la validación de la cadena de certificados sólo por cadenas se mantuvo hasta la corrección a nivel de código en 7.4.7. Esta distinción es importante porque indica a los defensores lo que están confiando en que se consiga. Esta distinción es importante porque indica a los defensores lo que confían en que se consiga con la revisión. Es un control necesario y práctico. No es lo mismo que un rediseño limpio de los supuestos de validación de certificados de la aplicación. (Obispo Fox)

Por qué un bypass de autenticación se convierte aquí en un problema del servidor y de la flota

Cuando una vulnerabilidad aterriza en un servidor de gestión, la pregunta correcta no es sólo "¿Puede entrar el atacante?". La siguiente pregunta es "¿Qué autoridad tiene ese sistema sobre todo lo demás?". FortiClient EMS tiene mucha autoridad. Puede definir la política de puntos finales, actualizar perfiles, gestionar ajustes relacionados con el acceso remoto, administrar conexiones de clientes y actuar a través de una API que realiza operaciones de configuración. Eso convierte una superficie de gestión vulnerable en un potencial multiplicador de fuerza. (docs.fortinet.com)

La redacción de watchTowr es útil para los defensores porque traduce ese apalancamiento abstracto en preocupaciones operativas: políticas de seguridad de puntos finales, perfiles de configuración de VPN, reglas de cortafuegos de aplicaciones, cuentas de administrador y controles de acceso, y configuraciones de cumplimiento de puntos finales. Ninguno de estos aspectos es secundario. Si un atacante puede influir en ellos después de comprometer EMS, el resultado puede parecerse menos a un incidente de un solo servidor y más a un evento del plano de control que propaga la desconfianza en toda la flota. (watchTowr)

Esta es también la razón por la que el debate terminológico sobre "RCE versus auth bypass" no es donde los respondedores serios deberían pasar el tiempo. La propia redacción de Fortinet dice que el fallo puede permitir código o comandos no autorizados. WatchTowr considera explícitamente que el problema permite la ejecución remota de código no autenticado, y un análisis independiente muestra una ruta de acceso a la API autenticada mediante la falsificación de señales que la aplicación nunca debería aceptar de los clientes. En términos prácticos de riesgo empresarial, todas estas descripciones apuntan en la misma dirección: una instancia de EMS accesible remotamente en una sucursal afectada es una exposición de nivel de crisis. (Laboratorios FortiGuard)

La lección más profunda se refiere a los planos de gestión en general. Los equipos de seguridad a menudo modelan el riesgo como si los puntos finales fueran los sistemas de alto valor y las consolas de gestión sólo fueran envoltorios administrativos alrededor de ellos. Ese modelo se rompe en cuanto la consola de gestión se convierte en el mecanismo de configuración, cumplimiento, acceso remoto, despliegue y aplicación de la postura. En un sistema como EMS, el plano de gestión no es adyacente a la flota de terminales. Está aguas arriba. (docs.fortinet.com)

Qué hay que comprobar primero si ejecuta FortiClient EMS

Empiece por responder a las preguntas más sencillas con pruebas, no con suposiciones. ¿Ejecuta FortiClient EMS autogestionado o FortiClient Cloud o FortiSASE? Si ejecuta EMS autogestionado, ¿qué versión exacta tiene instalada? ¿Está habilitada la administración remota HTTPS? ¿Era la interfaz accesible desde Internet o desde amplios segmentos internos donde un atacante podría llegar de forma plausible después de un punto de apoyo? Estas preguntas importan más en la primera hora que cualquier caza especulativa de un exploit público pulido. (Laboratorios FortiGuard)

Su triaje de versiones debe ser exacto, no aproximado. Si el entorno está en 7.4.5 o 7.4.6 y no se ha aplicado el hotfix, trate el servidor como expuesto si es accesible. Si el entorno está en 7.2, este CVE no es el problema que está resolviendo. Si el entorno está en 7.4.4, se encuentra en una posición diferente pero aún grave porque CVE-2026-21643 afectó a esa rama y también se observó explotado en la naturaleza. El riesgo de FortiClient EMS ahora mismo es específico de la versión, y comprimir vulnerabilidades adyacentes en un mensaje borroso es cómo los equipos toman malas decisiones de cambio bajo presión. (Laboratorios FortiGuard)

La siguiente prioridad es la clasificación de la exposición. Los propios documentos de Fortinet muestran que la administración remota HTTPS puede habilitarse para el acceso basado en navegador. La guía de mitigación de Bishop Fox es explícita en cuanto a que la vulnerabilidad requiere acceso HTTPS directo a la interfaz web de EMS en el puerto 443. Eso no significa "sólo Internet público". Significa que cualquier ruta que permita a un atacante llegar a esa interfaz importa. Una interfaz accesible externamente es el peor caso obvio, pero una ruta interna plana desde una estación de trabajo comprometida a EMS tampoco es un riesgo aceptable. (docs.fortinet.com)

Después, separe la corrección de la respuesta a incidentes, pero ejecútelas en paralelo. Remediar significa corregir en caliente o pasar a la versión 7.4.7. La respuesta a incidentes significa preservar los registros, comprobar la desviación de la configuración, revisar los cambios administrativos y decidir si la integridad del servidor sigue siendo digna de confianza. La gestión de parches cierra el agujero. No le dice si alguien utilizó el agujero antes de que usted llegara. La cronología de watchTowr hace que esa distinción sea inevitable porque la explotación se observó antes de la divulgación por parte del proveedor. (watchTowr)

Parchear CVE-2026-35616 sin crear nuevos problemas

La guía de emergencia de Fortinet es directa: aplicar el hotfix en 7.4.5 o 7.4.6 ahora, o pasar a 7.4.7, que contiene la corrección permanente. La página de problemas resueltos de 7.4.6 identifica CVE-2026-35616 como solucionado en FortiClient EMS 7.4.6 GA hotfix 1, build 7.4.6.2170.1277073y las notas de la versión 7.4.7 muestran que la CVE ya no afecta a esa versión. Para las versiones 7.4.5 y 7.4.6, Fortinet publicó instrucciones de instalación del hotfix, nombres de paquetes de ejemplo y valores SHA-256 por separado. (docs.fortinet.com)

Los documentos del proveedor muestran el mismo patrón operativo para ambas ramas afectadas: descargar el paquete de hotfix correcto del Soporte de Fortinet, verificar la suma de comprobación SHA-256, aplicarlo con emscliA continuación, enumere los hotfixes instalados y confirme que el estado es aplicado. Las sumas de comprobación de ejemplo de Fortinet en las páginas de revisiones de las notas de la versión son las siguientes 9f7d4f2c63176c5e766de8d0d6b0977af0b5795362d31ce6da72fcceb025d0c1 para el ejemplo del paquete hotfix 7.4.5 y 3e76dc2b712a2988afd50459022f28e3fbda9a0a29f7f31674026620040cf2f5 para el ejemplo del paquete hotfix 7.4.6. (docs.fortinet.com)

# Aplique el hotfix del proveedor en el servidor EMS afectado
sudo emscli execute hotfix --apply ./

# Verificar que el estado del hotfix es aplicado
sudo emscli execute hotfix --list

El nombre exacto del archivo debe coincidir con el paquete específico de la rama que obtuvo del Soporte de Fortinet y verificado con la suma de comprobación publicada. Las instrucciones de hotfix 7.4.5 y 7.4.6 de Fortinet muestran lo siguiente emscli flujo y uso --list para confirmar el estado aplicado. (docs.fortinet.com)

No convierta esto en una excusa para un salto de actualización descuidado. La documentación de las versiones 7.4.6 y 7.4.7 de Fortinet también registra problemas relacionados con la actualización que son relevantes para la planificación de emergencias. La página de problemas resueltos de la versión 7.4.7 dice que después de actualizar de 7.4.4 o 7.4.5 a 7.4.6, algunos entornos vieron problemas con la configuración de RADIUS para el inicio de sesión del administrador, los conectores de tejido OAuth 2 y la copia de seguridad programada en el servidor remoto. La documentación de actualización a 7.4.6 señala el mismo problema e indica que algunos entornos 7.4.4 o 7.4.5 deben instalar primero un paquete hotfix antes de intentar la actualización a 7.4.6. Bajo presión de emergencia, los equipos a menudo simplifican demasiado esto en "simplemente actualice a la última rama inmediatamente". Esa puede seguir siendo la respuesta correcta, pero no si rompe los controles en los que confías para administrar o recuperar la plataforma. (docs.fortinet.com)

La pauta de funcionamiento más segura suele ser directa. Si está en 7.4.5 o 7.4.6, aplique inmediatamente el hotfix publicado para detener la exposición activa. A continuación, planifique una migración controlada a 7.4.7 una vez que el entorno sea estable y se haya completado la validación posterior al hotfix. Si su equipo necesita una sola frase a partir de la cual trabajar, es esta: hotfix para estar seguro, luego actualizar para estar limpio. (Laboratorios FortiGuard)

Cómo validar el hotfix y cazar exploits

Lo mejor de una revisión de un proveedor no es que exista. Es que se puede verificar si cambió el comportamiento en el lugar que importaba. La lógica de escaneo no destructivo de Bishop Fox es útil porque se centra en el comportamiento en lugar de intentar un exploit completo. En su análisis, un objetivo sin parchear devuelve una respuesta diferente cuando un spoofed X-SSL-CLIENT-VERIFY: ÉXITO que cuando está ausente, porque la cabecera falsificada llega a Django y cambia el flujo de control. Después de la revisión, Apache elimina la cabecera falsa antes de que llegue a la aplicación, y las respuestas coinciden. (Obispo Fox)

Esto es importante porque se alinea con el diseño del hotfix. El objetivo de la mitigación de emergencia es restaurar el límite de confianza proxy/aplicación mediante la eliminación de las cabeceras falsificables. Por lo tanto, la validación debe demostrar que las cabeceras de autenticación de certificados proporcionadas por el usuario ya no afectan al comportamiento del servidor. Si su equipo utiliza una comprobación segura en sistemas propios, la pregunta no es "¿Podemos convertir esto en un arma?". La pregunta es: "¿Puede una cabecera falsificada cambiar la ruta del código?". Ese es el objetivo de validación correcto para el parche que Fortinet ha enviado. (Obispo Fox)

También hay aquí una lección más amplia sobre el flujo de trabajo. En la respuesta a vulnerabilidades de emergencia, lo difícil no suele ser redactar un resumen. Es preservar una cadena de pruebas fiable desde la identificación de la exposición hasta la validación de la corrección. El escrito público de Penligent sobre los informes de pentest de IA señala exactamente ese punto: un informe sólo es útil si puede sobrevivir a una nueva prueba, y las pruebas importan más que la prosa pulida. Esa norma encaja casi a la perfección con CVE-2026-35616. Tanto si se valida manualmente como con un flujo de trabajo más automatizado, lo que cuenta es un registro reproducible del antes y el después. (penligent.ai)

El mismo principio aparece en el escrito público de Penligent sobre pentesting de IA verificado, que define un flujo de trabajo útil no como "el modelo cree que ha encontrado algo", sino como un proceso acotado y reproducible que conserva el estado y demuestra las afirmaciones con artefactos inspeccionables. Para incidentes en el plano de la gestión como este, ese es el hábito correcto: mantener unidos el historial de cambios, el resultado de la validación y el estado de la corrección. Las conclusiones rápidas sin pruebas reproducibles son la forma en que los equipos se convencen a sí mismos de una falsa confianza. (penligent.ai)

El registro público es escaso en cuanto a los IOC proporcionados por los proveedores, por lo que la detección debe basarse en hipótesis más que en firmas. WatchTowr señala explícitamente que Fortinet no había publicado indicadores de compromiso en el periodo de tiempo de su informe y recomienda, en su lugar, la revisión de registros y la auditoría de configuraciones. Esto debería empujar a los defensores hacia dos categorías de comprobaciones: pruebas de que se han falsificado cabeceras relacionadas con certificados o de que se ha producido un comportamiento anómalo de la API, y pruebas de que las políticas controladas por EMS o los objetos administrativos han cambiado de una forma que el equipo no puede explicar. (watchTowr)

He aquí dos sencillos patrones de búsqueda de registros que corresponden claramente a la causa raíz revelada. Son ejemplos, no reglas proporcionadas por el proveedor, por lo que los nombres de los campos deberán coincidir con su entorno.

# Ejemplo 1, busque cabeceras de certificado-auth falsificadas que lleguen a su nivel web
index=web OR index=proxy
(host="" OR dest="")
("X-SSL-CLIENT-VERIFY" O "X-SSL-CLIENT-CERT")
| stats count min(_time) as first_seen max(_time) as last_seen by src_ip, uri_path, http_status

# Ejemplo 2, busque anomalías repentinas en el estado de la API de EMS en torno a flujos autentificados
index=web OR index=proxy
(host="" OR dest="")
uri_path="/api/*"
(http_status=401 OR http_status=500)
| timechart span=15m count by http_status

Estos patrones se derivan directamente de la causa raíz y de la observación de Bishop Fox de que el comportamiento pre-hotfix puede divergir cuando las cabeceras de certificados falsificados llegan a Django. Si su canalización de registro registra las cabeceras de solicitud o la normalización del proxy inverso, vale la pena ejecutarlos retroactivamente a través de la ventana de exposición. (Obispo Fox)

Cómo debe ser la respuesta a incidentes cuando los COI son escasos

Cuando el proveedor no le ha entregado un paquete IOC pulido, necesita construir la investigación en torno a estados de alto valor y rutas de abuso plausibles. La lista de comprobación de WatchTowr es un buen punto de partida: revisar las políticas de seguridad de los puntos finales, los perfiles de configuración de VPN, las reglas del cortafuegos de aplicaciones, las cuentas de administrador y los controles de acceso, así como las configuraciones de cumplimiento de los puntos finales en busca de cambios no autorizados. Esa lista es útil precisamente porque no se basa en una firma frágil. Se basa en para qué sería valioso un EMS comprometido. (watchTowr)

Las propias herramientas de diagnóstico de Fortinet permiten una respuesta más centrada en las pruebas de lo que muchos equipos creen. La guía de administración de EMS indica que un paquete de registros de diagnóstico puede incluir instantáneas de CPU y memoria, registros PostgreSQL, datos de rendimiento y, opcionalmente, una copia de seguridad parcial de la base de datos. La misma página dice que el paquete puede ser creado en la GUI o a través de EMSCLI usando ejecutar diagnóstico. En un caso como el de CVE-2026-35616, esto hace que el paquete de diagnóstico forme parte de su memoria muscular de triaje, no una ocurrencia tardía para abrir sólo cuando el soporte lo solicite. (docs.fortinet.com)

Esto no significa que el paquete de diagnóstico sea una respuesta forense completa. Significa que le ofrece una forma documentada de preservar el estado del lado del servidor mientras decide si la integridad es aún defendible. Si sospecha que un atacante puede haber interactuado con EMS como autoridad de configuración, preservar el estado de configuración respaldado por la base de datos y los registros relacionados desde el principio es más valioso que discutir sobre las etiquetas más tarde. La opción de copia de seguridad parcial de la base de datos es especialmente útil para preservar puntos de comparación, aunque Fortinet tiene cuidado de decir que no es un sustituto de las copias de seguridad regulares. (docs.fortinet.com)

La decisión más difícil es la que los equipos posponen demasiado: si se puede seguir confiando en el servidor después de parchearlo. La orientación de WatchTowr es contundente y razonable. Si se sospecha que el servidor está en peligro, no intente "limpiarlo in situ" a menos que pueda verificar la integridad con seguridad. Restaure a partir de una buena copia de seguridad conocida de antes de la ventana probable de compromiso, o reconstruya la instancia EMS y migre los datos. Para un plano de gestión, la recuperación de la confianza importa más que el orgullo del tiempo de actividad. El coste de mantener un controlador quizás limpio es a menudo mayor que el coste de reconstruirlo una vez. (watchTowr)

Aquí es donde la línea de tiempo importa operativamente. Si la explotación se observó el 31 de marzo y el aviso público llegó el 4 de abril, entonces la ventana retrospectiva mínima útil no es "cuando vimos por primera vez el correo electrónico del proveedor". Son los días anteriores. El enfoque correcto es anclar su registro y revisión de la configuración al primer período de exposición plausible, no a su fecha de conocimiento interno. (watchTowr)

Una matriz práctica incidente-respuesta para este CVE tiene este aspecto:

Línea de trabajo	Pregunta inmediata	Pruebas a conservar	Por qué es importante
Versión y exposición	¿Era EMS en 7.4.5 o 7.4.6 y accesible?	Registros de versión, rutas de acceso, estado del cortafuegos	Determinar si el CVE era pertinente y accesible
Remediación	¿Se ha aplicado y verificado el hotfix?	Cambiar billete, emscli --list salida, verificación de la suma de comprobación	Demostrar que la exposición está cerrada
Estado del servidor	¿Muestran los registros un comportamiento anormal de la API o un abuso del encabezado?	Registros web y proxy, paquete de diagnóstico	Pruebe la causa raíz revelada con tráfico real
Integridad del plano de control	¿Ha cambiado inesperadamente la política, el perfil o el estado del administrador?	Historial de configuración de EMS, objetos respaldados por BD, cambios de cuenta	Detectar el uso posterior al compromiso de la autoridad de EMS
Recuperación de la confianza	¿Es fiable la limpieza in situ?	Copia de seguridad, plan de reconstrucción, resultados de la validación	Decidir si restaurar o reconstruir

La matriz refleja la orientación pública y las propias capacidades de diagnóstico documentadas del producto. (watchTowr)

Fortalecimiento de FortiClient EMS tras el parche de emergencia

Los parches cierran el agujero de hoy. El endurecimiento determina si el siguiente fallo del plano de gestión se convertirá en la misma historia. El primer control es la accesibilidad de la red. La guía de mitigación de Bishop Fox dice que la vulnerabilidad requiere acceso HTTPS directo a la interfaz web de EMS en el puerto 443, y Fortinet documenta que la administración HTTPS remota es una característica configurable. Esa combinación apunta a una línea de base obvia: si los administradores no necesitan un amplio acceso basado en navegador desde fuera de rutas de gestión estrictamente controladas, no lo exponga. Limite la interfaz a redes de gestión dedicadas o rutas restringidas equivalentes. (Obispo Fox)

El segundo control es la integridad administrativa en torno a los cambios de política. FortiClient EMS no es sólo un servidor que almacena datos. Es un sistema de distribución de políticas y control de puntos finales. Esto significa que los cambios en los perfiles de los puntos finales, la configuración de acceso remoto, el comportamiento del cortafuegos y las cuentas administrativas deben poder auditarse como eventos de seguridad de primera clase. Muchos equipos registran bastante bien la autenticación y mal la configuración. En un entorno EMS, eso es al revés. Un rastro de inicio de sesión perfecto no sirve de mucho si la desviación maliciosa de las políticas es invisible. (docs.fortinet.com)

El tercer control es la disciplina de versiones. En los últimos meses se han producido dos problemas críticos no autenticados y activamente explotados en versiones adyacentes de FortiClient EMS. Esto debería cambiar la forma en que los equipos piensan sobre el ritmo de parcheado de este producto. La decisión no debería ser "actualizaremos EMS cuando haya una ventana de mantenimiento". Debería ser "EMS es un plano de gestión de alto valor y pertenece a la misma vía de revisión acelerada que los sistemas expuestos de identidad, VPN y admin-edge". El papel del producto en la administración de puntos finales justifica ese tratamiento. (watchTowr)

El cuarto control es la repetición rutinaria de las pruebas. Esta es la parte que las organizaciones se saltan cuando el localizador se calla. Un hotfix aplicado pero no verificado es mejor que nada, pero no es una respuesta acabada. Como mínimo, los equipos deben confirmar que el estado del parche es visible en EMS, que la interfaz ya no es ampliamente accesible en la medida de lo posible, y que un método de validación seguro muestra que el comportamiento de suplantación de cabecera ha desaparecido. En entornos con múltiples superficies de gestión, un flujo de trabajo de repetición de pruebas es más importante que otro paquete de diapositivas. (Obispo Fox)

CVE-2026-21643 y por qué FortiClient EMS merece ahora un modelo de riesgo diferente

CVE-2026-35616 es más importante si se entiende como parte de un patrón. El aviso de Fortinet de febrero de 2026 para CVE-2026-21643 describe una inyección SQL no autenticada en FortiClient EMS 7.4.4 que puede permitir código o comandos no autorizados a través de peticiones HTTP específicamente diseñadas. Fortinet también dijo que el problema se había observado explotado en la naturaleza, y la ruta de corrección era mover 7.4.4 a 7.4.5 o superior. Las versiones 7.2 y 8.0 no estaban afectadas. (Laboratorios FortiGuard)

Las clases técnicas son diferentes. CVE-2026-21643 era un problema de inyección SQL. CVE-2026-35616 es un control de acceso inadecuado y un fallo en el límite de confianza entre certificado y autenticación. Pero desde la perspectiva del modelo de riesgo, riman en aspectos que importan más que las etiquetas. Ambos afectaron al plano de gestión de EMS. A ambos podían acceder atacantes no autenticados a través de la red. Se confirmó la explotación de ambos. Ambos obligan a los defensores a pensar en lo que ocurre cuando el plano de control del endpoint, en lugar de los propios endpoints, se convierte en el punto de entrada del adversario. (Laboratorios FortiGuard)

El análisis de Bishop Fox de CVE-2026-35616 hace explícita la continuidad arquitectónica. Su informe dice que la misma arquitectura de middleware, el sistema de decoradores OpenApi y la capa de conexión PostgreSQL que rediseñaron para CVE-2026-21643 también fueron fundamentales en este caso. Eso no significa que los fallos sean idénticos o necesariamente encadenables. Significa que los defensores deberían dejar de tratarlos como accidentes no relacionados y empezar a tratar FortiClient EMS como un sistema cuyas rutas de control expuestas merecen un escrutinio agresivo. (Obispo Fox)

Una comparación práctica ayuda:

Categoría	CVE-2026-21643	CVE-2026-35616
Clase de vulnerabilidad	Inyección SQL no autenticada	Control de acceso inadecuado y derivación de autenticación de API
Gama de versiones afectadas	7.4.4	7.4.5 a 7.4.6
Estado de la explotación del vendedor	Observado explotado en la naturaleza	Observado explotado en la naturaleza
Ruta fija	Actualización a 7.4.5 o superior	Aplique el hotfix de la rama inmediatamente o pase a 7.4.7
Lección de defensa	No dejar 7.4.4 en pie	No asuma que la rama sucesora "arreglada" es segura sin volver a probarla

La tabla resume los avisos oficiales de Fortinet y la ruta de corrección subsiguiente para la CVE posterior. (Laboratorios FortiGuard)

Ese patrón también debería dar forma a su planificación del cambio. Imagínese la confusión dentro de una gran empresa que ejecuta versiones mixtas de EMS en distintas regiones. Un equipo sabe que la versión 7.4.4 es mala debido al SQLi, actualiza a la 7.4.5, y días después se entera de que la propia 7.4.5 está en el rango afectado por un bypass de autenticación activamente explotado. Esto no es un caso extremo académico. Es exactamente el tipo de situación en la que los equipos de seguridad, infraestructura y control de cambios empiezan a trabajar a partir de modelos mentales obsoletos. La única defensa contra eso es un inventario disciplinado de versiones y la asunción de que el plano de gestión pertenece al carril rápido para la revisión de seguridad. (Laboratorios FortiGuard)

Errores que los equipos suelen cometer en las primeras 24 horas

El primer error es tratar esto como un problema de puntuación en lugar de un problema de explotación. Tanto si se ancla en el 9,1 del aviso como si se ancla en el 9,8 del vector CNA mostrado por el NVD, el problema ya está en KEV y ya se ha observado que se ha explotado. No se gana nada debatiendo sobre decimales mientras el plano de gestión sigue expuesto. (Laboratorios FortiGuard)

El segundo error es leer sólo un campo en una página. El resumen del aviso de Fortinet dice que la explotación se observó in the wild aunque el bloque de metadatos sigue mostrando "Known Exploited No". Los equipos de seguridad que operan a partir de campos raspados sin leer el texto del aviso son especialmente vulnerables a este tipo de desajustes durante eventos de rápida evolución. (Laboratorios FortiGuard)

El tercer error es parchear y quedarse ahí. Esta es una vulnerabilidad del plano de gestión con una causa raíz documentada en cabeceras de autenticación falsificadas y una ventana de exposición conocida antes de la divulgación pública. Esa combinación debería desencadenar siempre una segunda pista: validar la corrección y revisar la autoridad de configuración que EMS mantuvo durante el periodo vulnerable. (watchTowr)

El cuarto error es agrupar todos los problemas cercanos de FortiClient EMS en una nota y un ticket de cambio. CVE-2026-21643 afecta a la versión 7.4.4. CVE-2026-35616 afecta a las versiones 7.4.5 a 7.4.6. La ruta de corrección y la urgencia difieren según la rama, y la ruta de actualización a 7.4.6 tenía sus propias advertencias operativas. El riesgo de interrupción del servicio y el riesgo de seguridad se refuerzan mutuamente. (Laboratorios FortiGuard)

El quinto error es asumir que los despliegues en la nube y autogestionados son intercambiables en el plan de respuesta. El aviso de Fortinet dice específicamente que FortiClient Cloud y FortiSASE fueron remediados por el proveedor y no requieren ninguna acción del cliente para este problema. Si gestiona tanto productos alojados por el proveedor como productos autogestionados, su comunicación de incidentes debe mantener esa distinción. (Laboratorios FortiGuard)

CVE-2026-35616 comida para llevar

La lección más importante de CVE-2026-35616 no es sólo que se ha encontrado y corregido un mal bypass de autenticación. Es que FortiClient EMS ahora pertenece claramente a la misma conversación de riesgo que otros planos de control expuestos que pueden dar forma a la confianza de la empresa, la postura del punto final y el comportamiento de acceso remoto. La propia documentación de Fortinet deja claro cuánta autoridad tiene EMS. Los últimos meses de avisos sobre FortiClient EMS dejan claro que los atacantes también entienden esa autoridad. (docs.fortinet.com)

Si ejecuta EMS autogestionado en 7.4.5 o 7.4.6, las prioridades inmediatas son simples: aplique el hotfix publicado o pase a 7.4.7, verifique el comportamiento de la corrección, conserve y revise las pruebas del lado del servidor, audite el estado de configuración de alto valor y decida honestamente si la instancia sigue siendo de confianza. Si su interfaz EMS era accesible durante la ventana de explotación, maneje la respuesta como un incidente de seguridad en el plano de control, no como un mantenimiento rutinario. (Laboratorios FortiGuard)

Lecturas complementarias y enlaces de referencia

Aviso PSIRT de Fortinet para CVE-2026-35616, versiones afectadas, declaración de explotación, guía de hotfix y estado del servicio en la nube. (Laboratorios FortiGuard)

Entrada NVD para CVE-2026-35616, incluyendo estado KEV, fecha de vencimiento, CWE y vector CNA mostrado. (nvd.nist.gov)

Instrucciones del hotfix de Fortinet 7.4.5, incluidas las sumas de comprobación y emscli flujo. (docs.fortinet.com)

Instrucciones del hotfix de Fortinet 7.4.6 y página de problemas resueltos que identifica la compilación del hotfix que corrige la CVE. (docs.fortinet.com)

La página de problemas resueltos de Fortinet 7.4.7 muestra que el problema ya no afecta a esa versión. (docs.fortinet.com)

Análisis técnico de Bishop Fox de la causa raíz, problema del encabezado de confianza, debilidad de la validación de la cadena de certificados y lógica de validación no destructiva. (Obispo Fox)

Cronograma de explotación de watchTowr y guía de respuesta a incidentes centrada en la auditoría de configuraciones y la recuperación de la confianza. (watchTowr)

Documentación de administración de FortiClient EMS que cubre la gestión centralizada de puntos finales, la administración HTTPS remota, los perfiles de puntos finales, el comportamiento de despliegue y la generación de paquetes de diagnóstico. (docs.fortinet.com)

Fortinet PSIRT advisory for CVE-2026-21643, que es un contexto útil para entender por qué EMS debe tratarse ahora como un riesgo de mayor prioridad en el plano de gestión. (Laboratorios FortiGuard)

Artículo público de Penligent sobre informes de pentest de IA y repetición de pruebas respaldada por pruebas, que es relevante para la validación posterior al parche y la elaboración de informes defendibles. (penligent.ai)

Artículo público de Penligent sobre flujos de trabajo de pentesting de IA verificados, que es relevante para la validación de remediación repetible para sistemas de gestión expuestos. (penligent.ai)