CISA incluye en KEV el fallo de FortiOS usado para instalar PEERSTITCH

CISA incorporó el 16 de octubre de 2026 a su catálogo KEV la vulnerabilidad CVE-2025-61624 de FortiOS, FortiPAM, FortiProxy y FortiSwitchManager, el path traversal con el que el grupo CL-STA-0954 pasó a root en los FortiGate de una operadora e instaló el implante PEERSTITCH. El plazo para las agencias federales de EE. UU. vence hoy, 19 de octubre, e incluye un triaje forense del equipo, y Fortinet suma con esta su novena entrada de 2026 en el catálogo.

Qué ha pasado

La agencia estadounidense publicó el viernes 16 de octubre de 2026 una alerta con dos nuevas entradas en su catálogo de vulnerabilidades explotadas (KEV). Una es CVE-2025-61624, un path traversal en la línea de comandos de varios productos de Fortinet. La otra es CVE-2026-102764, el fallo de BeyondTrust Remote Support que se explotaba como zero-day desde agosto. CISA justifica la inclusión con su fórmula habitual, «These types of vulnerabilities are a frequent attack vector for malicious cyber actors» (este tipo de vulnerabilidades son un vector de ataque frecuente para los actores maliciosos).

El fallo de Fortinet no es nuevo. El fabricante lo publicó el 14 de abril de 2026 en el aviso FG-IR-26-122 y ya entonces lo marcó como explotado, aunque sin contar dónde. La respuesta llegó el 14 de octubre, cuando Unit 42 describió la intrusión en un proveedor gestionado de telecomunicaciones que el blog contó al día siguiente. En aquella noticia dijimos que CVE-2025-61624 no figuraba en KEV a 14 de octubre. Dos días después CISA lo corrigió, y por eso esta pieza actualiza aquella.

Lo que cambia con la entrada en el catálogo es el reloj. CISA asigna a CVE-2025-61624 un plazo de corrección de tres días, hasta el 19 de octubre de 2026, y la marca con la obligación de triaje forense, la quinta entrada de Fortinet con esa etiqueta desde que la directiva BOD 26-04 la creó en junio. Palo Alto Networks, en la valoración que recoge SecurityWeek, sostiene que el hallazgo del implante «demonstrates the increasing technical maturity of edge-device malware» (demuestra la creciente madurez técnica del malware para dispositivos de borde).

Detalles técnicos

Fortinet y NVD no coinciden en la puntuación. El fabricante da un 6,0 con vector local (AV:L) porque el fallo se explota desde la consola de administración, y NVD lo sube a 6,5 con vector de red (AV:N) porque esa consola se alcanza por red. La diferencia está solo en ese componente del vector, y el resto (privilegios altos, sin interacción, impacto alto en integridad y disponibilidad) es idéntico. Fortinet publica también una puntuación temporal de 5,4, que es la cifra que algunos medios han repetido como si fuera la base. NVD actualizó el registro el 17 de octubre con la fecha de inclusión en KEV y el plazo del 19 de octubre.

El mecanismo lo explicó Unit 42 en su informe del 14 de octubre. El nombre de un objeto auto-script de FortiOS no se sanea, así que un administrador con permisos de lectura y escritura puede nombrarlo con secuencias ../ y el motor de auto-scripts escribe el cuerpo del script en cualquier ruta del sistema de ficheros, como root. En la intrusión de la operadora el grupo lo usó dos veces, primero para dejar caer el cargador del implante con el objeto ../../../../setup y después para escribir la configuración del canal de mando y control. El registro de FortiOS que publica Unit 42 muestra esa segunda explotación, con el objeto ../../tmp/apache2/conf/md-acme.conf y un script que carga el módulo mod_md de Apache, apunta la autoridad de certificación ACME a 23.240.77.233 por el puerto 8084, mapea el reto DNS-01 al binario /bin/node y fuerza la renovación continua con MDRenewMode always.

Ese fichero es el que mantiene abierto el canal con el atacante. Cada renovación de certificado ejecuta Node.js con los parámetros que manda el servidor remoto, y el shell inverso sale por SSH sin que el implante abra puertos propios. El diagrama de flujo de Unit 42 resume la secuencia completa de PEERSTITCH en seis pasos, desde el auto-script que descarga cinco componentes de 23.240.77.233 por el puerto 8085 hasta la limpieza final en la que el inyector lldprx borra los ficheros de etapa y termina.

Entre medias, el inyector se engancha con ptrace a los demonios miglogd e iked, reserva un buffer de 16 KB con permisos de lectura, escritura y ejecución mediante una llamada mmap directa y enlaza los dos procesos a través de /proc/PID/mem. Unit 42 recomienda cinco comprobaciones para cazarlo, que ya recogimos en la noticia anterior, y tres de ellas se pueden lanzar desde la CLI de FortiOS con estos comandos.

# Versión instalada (debe ser 7.6.5, 7.4.10 o superior)
get system status

# Objetos auto-script con secuencias de salto de directorio
show full-configuration system auto-script | grep "\.\./"

# Caídas con señal 11 en los demonios que parchea PEERSTITCH
diagnose debug crashlog read | grep -i "signal 11"

Las otras dos comprobaciones exigen acceso al sistema de ficheros del equipo. Son la búsqueda de regiones anónimas de 16.384 bytes con permisos rwxp en /proc/<pid>/maps de miglogd e iked, y la verificación de la integridad del segmento de código de esos demonios en los desplazamientos base+0x106F7B8, base+0x1072E20 y base+0x109A570, donde el implante escribe sus parches.

A quién afecta

A cualquier organización con FortiOS 7.6.0 a 7.6.4, 7.4.0 a 7.4.9 o cualquier versión de las ramas 7.2, 7.0 y 6.4, y a quien use FortiPAM 1.7.0 o anterior, FortiProxy 7.6.0 a 7.6.4 o 7.4.0 a 7.4.11 y FortiSwitchManager 7.2.0 a 7.2.7 o 7.0.0 a 7.0.6. El aviso de Fortinet exige que el atacante tenga ya un perfil de administrador con permisos de lectura y escritura, así que el fallo no sirve para entrar. Sirve para escalar. Eso es lo que hizo CL-STA-0954, que llegó a las consolas con credenciales de VPN SSL y de administración robadas del FortiManager de la víctima, y lo mismo podría hacer quien compre accesos a FortiGate en el mercado que alimenta la campaña FortiBleed.

El alcance va más allá del perímetro clásico. Siemens incluyó CVE-2025-61624 el 12 de mayo de 2026 en la revisión 1.1 de su aviso SSA-975644, porque su plataforma industrial RUGGEDCOM APE1808 ejecuta el firewall de Fortinet y hereda el fallo en todas las versiones anteriores a la 7.4.10. Es un recordatorio de que el parque de FortiOS incluye equipos de subestaciones y plantas que rara vez entran en los ciclos de parcheo de TI.

En España no hemos localizado un aviso de INCIBE-CERT dedicado a CVE-2025-61624, ni en abril ni tras la inclusión en KEV. El CERT nacional sí publicó el 8 de octubre el aviso INCIBE-2026-717 sobre el otro fallo de Fortinet que entró en el catálogo este mes, el path traversal CVE-2026-104286 de FortiMail, en el que afirma que «Fortinet y CISA han confirmado la explotación activa de CVE-2026-104286». No hay recuento público de equipos FortiOS expuestos en España en el momento de escribir esta noticia, así que no damos cifra.

Lo que sí se puede medir es el ritmo. Con la entrada del 16 de octubre, Fortinet acumula 32 vulnerabilidades en KEV, 9 de ellas incorporadas en 2026, el año con más altas del fabricante desde que el catálogo existe. El gráfico recoge la serie completa, contada sobre el fichero JSON que CISA publicó el 16 de octubre.

Las nueve entradas de 2026 dibujan el mapa de productos que los atacantes trabajan. FortiClient EMS, FortiSandbox, FortiMail y ahora FortiOS, FortiPAM, FortiProxy y FortiSwitchManager, todos con plazo de tres días salvo CVE-2025-68686, que recibió catorce.

Qué hacer

Si administras FortiOS, FortiPAM, FortiProxy o FortiSwitchManager, por orden de urgencia.

1. Actualiza FortiOS a 7.6.5 o 7.4.10, FortiPAM a 1.7.1, FortiProxy a 7.6.5 o 7.4.12 y FortiSwitchManager a 7.2.8 o 7.0.7, o versiones posteriores, siguiendo la ruta de actualización que marca Fortinet. Las ramas 7.2, 7.0 y 6.4 de FortiOS, 7.2 y 7.0 de FortiProxy y 1.0 a 1.6 de FortiPAM no tienen parche y hay que migrarlas. FortiPAM 1.8 no está afectado.
2. Si no puedes actualizar hoy, comprueba que la base de datos FMWP de FortiGuard está al menos en la versión 25.120, que incluye el parche virtual FG-VD-59270.0day para este fallo, y revisa que la administración de los equipos no esté expuesta a Internet.
3. Haz el triaje antes de parchear si el equipo lleva expuesto desde abril. Es lo que CISA exige a sus agencias en la guía de implantación de BOD 26-04, recoger primero los datos volátiles y después aplicar el parche, porque actualizar un FortiGate con PEERSTITCH en memoria destruye la evidencia.
4. Lanza los comandos del apartado anterior en cada equipo y busca en los registros de FortiOS entradas con cfgpath system.auto-script cuyo cfgobj contenga ../, como las dos que publica Unit 42.
5. Si el FortiGate depende de un FortiManager, revisa ese FortiManager con los indicadores de FortiJump y da por filtradas las credenciales y las claves que custodia hasta rotarlas, porque esa fue la puerta de entrada en el caso de la operadora.
6. Si confirmas el implante, aísla el equipo sin apagarlo, conserva la memoria y notifica a INCIBE-CERT si eres empresa o ciudadano y al CCN-CERT si perteneces al sector público. Reconstruye después desde un firmware limpio y rota todas las credenciales que pasaron por el equipo.

Para quien gestione muchos equipos, el propio fichero JSON del catálogo permite vigilar las altas de Fortinet sin depender de avisos de terceros. Este comando devuelve las entradas del fabricante ordenadas por fecha de inclusión.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[] | select(.vendorProject == "Fortinet")
           | [.dateAdded, .cveID, .product, .dueDate, .forensicTriage] | @tsv' \
  | sort

Análisis

La inclusión en KEV de un fallo de CVSS 6,0 cuenta más de lo que dice la puntuación. CVE-2025-61624 exige ser administrador, así que en una matriz clásica de priorización quedaría por detrás de cualquier fallo sin autenticar. CISA lo ha metido en el catálogo con el plazo más corto que contempla y con triaje forense obligatorio, y lo ha hecho dos días después de que Unit 42 mostrase para qué servía en manos de un grupo con solapamientos estatales. La lección para quien gestiona el parque es que el fallo que importa no es el que tiene la puntuación más alta, es el que completa la cadena que el atacante ya tiene a medias, y en el perímetro esa cadena suele empezar por credenciales robadas.

La directiva BOD 26-04, que CISA publicó el 10 de junio de 2026 en sustitución de BOD 22-01, es el otro cambio de fondo. La tabla de plazos que acompaña a la directiva cruza cuatro variables (exposición pública, presencia en KEV, explotación automatizable e impacto técnico) y reserva los tres días con triaje forense para las combinaciones en las que el atacante obtiene control total. Desde entonces 139 de las 264 entradas de 2026 han recibido plazo de tres días, y en octubre lo han tenido las 18.

Ninguna norma española obliga a ese ritmo, pero el Esquema Nacional de Seguridad y la gestión de parches que exige NIS2 a los sectores esenciales apuntan en la misma dirección, y el catálogo KEV se ha convertido en la referencia práctica para decidir qué se corrige primero. Lo hemos visto este mismo mes con PAN-OS y con BeyondTrust, y ahora con FortiOS.

Hay una pregunta que el aviso de CISA no responde. El catálogo marca el triaje forense porque presume compromiso en los equipos expuestos, pero Unit 42 solo examinó la red del proveedor, no las de sus clientes, y Fortinet no ha publicado cuántos equipos vio explotados cuando marcó el fallo en abril. Sin esa cifra, la decisión de cada administrador es la misma que en la campaña FortiBleed, asumir que un FortiGate que lleva seis meses expuesto con un administrador alcanzable desde fuera puede estar tocado, y buscar antes de limpiar. Unit 42 lo resume en una frase que vale para FortiManager y para cualquier consola central, «the management platform is the highest-value target on the network» (la plataforma de gestión es el objetivo más valioso de la red).

Cronología

• Septiembre de 2024. Según Unit 42, CL-STA-0954 entra en el FortiManager de la operadora y exfiltra la configuración de más de 500 FortiGate.
• 23 de octubre de 2024. Fortinet publica FG-IR-24-423 (CVE-2024-47575, FortiJump) y CISA lo incorpora a KEV el mismo día.
• 14 de abril de 2026. Fortinet publica FG-IR-26-122 (CVE-2025-61624) y lo marca como explotado.
• 12 de mayo de 2026. Siemens añade CVE-2025-61624 a su aviso SSA-975644 para RUGGEDCOM APE1808.
• 10 de junio de 2026. CISA publica la directiva BOD 26-04 con plazos de 3, 14 y 60 días y triaje forense.
• 1 de octubre de 2026. CISA incluye en KEV CVE-2026-104286, el path traversal de FortiMail, con plazo hasta el 4 de octubre.
• 14 de octubre de 2026. Unit 42 publica el informe de PEERSTITCH.
• 16 de octubre de 2026. CISA incluye en KEV CVE-2025-61624 y CVE-2026-102764 con plazo hasta el 19 de octubre y triaje forense.
• 17 de octubre de 2026. NVD actualiza el registro de CVE-2025-61624 con los datos de KEV.

Preguntas frecuentes

¿Tengo que parchear en tres días aunque no sea una agencia de EE. UU.?

No por obligación legal, porque BOD 26-04 solo vincula a la administración federal civil estadounidense. CISA anima al resto de organizaciones a seguir el mismo criterio, y en la práctica los plazos de KEV son la referencia que usan aseguradoras, auditores y clientes para medir la gestión de parches. Si el equipo está expuesto y lleva meses sin actualizar, el plazo relevante es cuanto antes.

¿Qué significa que la entrada lleve triaje forense?

Que CISA presume que los equipos expuestos pueden estar ya comprometidos y pide que la agencia lo compruebe antes de dar el fallo por cerrado. Su guía propone recoger primero la memoria y los registros, aplicar el parche entre las dos y las veinticuatro horas, y tener un informe de triaje a las setenta y dos. Si el triaje encuentra compromiso, el incidente pasa al sistema de notificación de CISA.

¿Vale con el parche virtual de FortiGuard?

Sirve para ganar tiempo, no para cerrar el caso. La firma FG-VD-59270.0day de la base de datos FMWP 25.120 bloquea el patrón de explotación conocido en los equipos con el servicio activo, pero no corrige el fallo del intérprete y no protege contra variantes. Fortinet lo presenta como mitigación y la solución sigue siendo la versión corregida de cada rama.

¿Cómo sé si mi FortiGate tiene PEERSTITCH?

El implante no deja ficheros, así que la búsqueda es en memoria y en los registros. Revisa los objetos auto-script con secuencias ../, las caídas con señal 11 de miglogd, iked o syslogd y las regiones de 16 KB con permisos rwxp en el mapa de memoria de esos dos demonios. Si tienes un FortiManager, revisa antes allí los indicadores de FortiJump, porque de él salieron las credenciales que hicieron posible todo lo demás.

Quien quiera repasar cómo se endurece un firewall antes de que llegue el siguiente aviso puede empezar por nuestra guía sobre cómo optimizar la ciberseguridad del firewall, que sigue vigente en lo que toca a la exposición de las interfaces de administración.