El equipo cuyo trabajo es detonar malware

Una sandbox existe para ser atacada. Usted compra FortiSandbox para que los archivos sospechosos se abran en un sitio que no es su red, para observarlos mientras se portan mal y emitir un juicio. Por diseño se sitúa justo en el punto por el que llega lo que no merece confianza. Eso es lo que convierte una inyección de comandos sin autenticación en su interfaz web en una categoría de problema distinta del mismo fallo en un servidor corriente.

CVE-2026-25089 es exactamente eso. Afecta a la interfaz web de FortiSandbox, FortiSandbox Cloud y FortiSandbox PaaS, y permite que un atacante sin autenticar ejecute comandos no autorizados mediante peticiones HTTP especialmente construidas. Tiene una puntuación CVSS de 9.1. Fortinet la publicó y la parcheó el 9 de junio de 2026.

A mediados de junio empezó la explotación, a mediados de julio se enteró el catálogo

La explotación de tres fallos de FortiSandbox se observó en entornos reales durante el fin de semana del 14 al 16 de junio, y el seguimiento independiente registró la explotación de CVE-2026-39808 ya el 12 de junio. La prensa técnica lo contó entonces: Help Net Security el 16 de junio, Qualys al día siguiente, junto con The Hacker News y SecurityWeek. Dos de los tres, CVE-2026-39808 y CVE-2026-39813, ya habían sido divulgados por Fortinet en abril. El tercero, CVE-2026-25089, se había parcheado el 9 de junio, días antes de que empezaran los ataques.

El 16 de julio de 2026 CISA publicó la versión 2026.07.16 del catálogo y añadió tres entradas. Dos son los fallos de FortiSandbox, CVE-2026-25089 y CVE-2026-39808. La tercera es un fallo de deserialización de Microsoft SharePoint, CVE-2026-58644.

Cuente los días. Explotación confirmada, reportada públicamente y en entornos reales a mediados de junio. Entrada en el catálogo federal el 16 de julio. Unos treinta días separan ambas cosas, en un equipo accesible desde internet con un fallo de ejecución remota de código sin autenticación, y durante esos treinta días la información no era secreta. Estaba en los avisos del fabricante y en la prensa técnica.

El tercero sigue sin aparecer

En aquella oleada de junio se reportaron tres CVE de FortiSandbox como explotados. Dos se catalogaron el 16 de julio. CVE-2026-39813, un fallo de path traversal en la API JRPC de FortiSandbox que permite eludir la autenticación, no está en el catálogo.

Esta es la parte que debería cambiar cómo se usa el catálogo, y no solo con qué rapidez. Una entrada en el KEV es una señal positiva y fuerte: si algo figura ahí, se está explotando y usted debe actuar. La ausencia de una entrada es una señal mucho más débil de lo que suponen la mayoría de los programas de parcheo. CVE-2026-39813 se reportó como explotado junto a los dos que sí se listaron, en la misma oleada y en la misma familia de producto, y no llegó al catálogo. Quien parchea lo que CISA lista y aplaza lo que CISA no lista acaba de aplazar un fallo que los atacantes usaron en junio.

Un reloj de tres días sobre un equipo bajo control de cambios

Las tres entradas añadidas el 16 de julio llevan una fecha límite de corrección del 19 de julio de 2026. Tres días.

Para un operador europeo el plazo federal en sí no es vinculante, y resulta tentador archivarlo como un detalle administrativo estadounidense. Es más útil leerlo como una medida de gravedad. Una fecha límite a tres días es la manera que tiene el catálogo de decir que no espera que usted aguarde a la siguiente ventana. Lo incómodo es el choque con la realidad: un appliance de sandbox suele estar bajo control de cambios precisamente porque inspecciona tráfico de producción, y tres días no son una ventana de cambio en la mayoría de las organizaciones. Esa tensión es el verdadero problema operativo, y no se resuelve leyendo el plazo con más atención.

Bajo NIS2 la exposición no es el plazo estadounidense sino el deber ordinario de diligencia, y un fallo de ejecución remota de código sin autenticación en un equipo de seguridad, explotado en entornos reales durante un mes y con parche del fabricante disponible, es algo difícil de explicar como riesgo aceptado.

Recablee el disparador

La instrucción es pequeña y concreta. Si su proceso de vulnerabilidades arranca cuando algo aparece en el KEV, arranca con cerca de un mes de retraso y además se deja elementos fuera. No es una crítica al catálogo, que hace lo que dice: registra lo que se sabe explotado, cuando las pruebas alcanzan el umbral. Es una crítica al uso de un canal de confirmación como sistema de alerta temprana.

Haga tres cosas. Suscríbase directamente a los avisos PSIRT de cada fabricante cuyos equipos terminan tráfico no confiable, porque Fortinet publicó esto en junio mientras el catálogo hablaba en julio. Dé a los equipos de seguridad expuestos a internet su propio carril de parcheo con un reloj más corto que el resto de la infraestructura, ya que son a la vez los activos más expuestos y los más sujetos a control de cambios que usted posee. Y revise su parque de FortiSandbox frente a los tres CVE de junio, no frente a los dos catalogados.

Leer a continuación: Un edificio inutilizado cuesta más que un rescate  |  Sus semillas MFA salieron antes del parche