Tiempo de lectura: 15 minutos

A fecha del 10 de septiembre de 2026, una vulnerabilidad conocida y parcheada desde enero ha adquirido una nueva dimensión operativa: PivotC2. SOCRadar Threat Research Unit (STRU) asegura haber identificado explotación activa de CVE-2025-25249 contra dispositivos FortiGate para desplegar PivotC2, un RAT (Remote Access Trojan) desarrollado específicamente para la post-explotación de FortiOS. La herramienta permite mantener acceso remoto, extraer configuraciones y credenciales, crear túneles hacia redes internas y utilizar el firewall comprometido como punto de pivote.

La investigación, publicada el 8 de septiembre de 2026, sitúa el inicio de la actividad al menos en julio y cifra en más de 30.000 las direcciones FortiGate incluidas en los archivos de objetivos analizados, con 178 sesiones de dispositivos que SOCRadar considera comprometidos e infectados con PivotC2. Estas cifras proceden exclusivamente de la investigación de SOCRadar y no deben interpretarse como un censo de víctimas confirmado por Fortinet.

No es una nueva vulnerabilidad de Fortinet

El elemento nuevo no es CVE-2025-25249. Fortinet publicó la vulnerabilidad el 13 de enero de 2026 y distribuyó versiones corregidas meses antes de que SOCRadar sitúe las primeras intrusiones observadas. La novedad es la aparición de un exploit aparentemente operativo y de una plataforma de post-explotación diseñada específicamente para convertir un FortiGate comprometido en una puerta de entrada hacia la red interna.

A fecha de cierre de este análisis, la investigación pública detallada sobre PivotC2 procede de SOCRadar. La sección pública de blogs PSIRT de Fortinet consultada el 9 de septiembre no contiene todavía un análisis específico de esta campaña. Por este motivo, la explotación, victimología, infraestructura C2 y atribución descritas en este artículo deben entenderse como hallazgos de SOCRadar, mientras que la existencia de CVE-2025-25249, las versiones afectadas y las mitigaciones se apoyan en información del fabricante y organismos como INCIBE-CERT.

Ficha técnica de CVE-2025-25249

Campo	Información
CVE	CVE-2025-25249
CWE	CWE-122 — Heap-Based Buffer Overflow
Severidad	Alta
CVSS v3.1 base	8,1/10
Vector	CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Autenticación	No requerida
Interacción del usuario	No requerida
Componente	cw_acd
Protocolo implicado	CAPWAP
Servicio de control	UDP/5246
Impacto	Ejecución no autorizada de código o comandos
Aviso del fabricante	FG-IR-25-084
Publicación original	13 de enero de 2026

INCIBE-CERT describe el fallo como un desbordamiento de búfer en memoria dinámica —heap— que permite a un atacante remoto enviar paquetes específicamente manipulados y ejecutar código o comandos sin disponer previamente de credenciales. La complejidad de ataque se considera alta, una característica relevante porque existen mitigaciones de memoria que el exploit debe superar.

Versiones afectadas

Los rangos publicados para FortiOS son los siguientes:

FortiSwitchManager también está afectado entre las versiones 7.0.0–7.0.5 y 7.2.0–7.2.6, corregidas respectivamente en 7.0.6 y 7.2.7. El registro de vulnerabilidad incluye igualmente determinadas versiones de FortiSASE.

Las notas oficiales de Fortinet confirman expresamente que FortiOS 7.0.18, 7.2.12, 7.4.9 y 7.6.4 ya no son vulnerables a CVE-2025-25249.

cw_acd y CAPWAP: dónde se encuentra la superficie de ataque

El fallo reside en cw_acd, un proceso de FortiOS relacionado con CAPWAP (Control and Provisioning of Wireless Access Points). CAPWAP permite que un controlador gestione de forma centralizada puntos de acceso inalámbricos y utiliza UDP/5246 para el canal de control. En FortiOS, habilitar una conexión de Security Fabric sobre una interfaz mediante allowaccess fabric activa funcionalidad asociada a FortiTelemetry y CAPWAP.

Esto introduce una distinción importante. Que una versión de FortiOS sea vulnerable no significa automáticamente que cualquier FortiGate pueda ser explotado desde Internet. El atacante necesita alcanzar la superficie correspondiente. Por ello, Fortinet recomendó como mitigación retirar fabric de interfaces donde no resulte necesario o restringir mediante políticas local-in el tráfico CAPWAP UDP/5246–5249 a dispositivos expresamente autorizados.

– Cómo funciona la explotación observada

SOCRadar recuperó y analizó un framework denominado fortirun.bin. Según los investigadores, se trata de un paquete autoextraíble que contiene un entorno Python y módulos específicos para explotar CAPWAP. El exploit recuperado incluye perfiles para 13 modelos FortiGate y dos FortiAP ejecutando determinadas compilaciones de FortiOS 7.4.0 a 7.4.8.

Este dato no debe confundirse con el alcance de CVE-2025-25249. La vulnerabilidad afecta a más ramas de FortiOS; lo que está limitado a esos modelos y compilaciones es la versión concreta del exploit analizado por SOCRadar.

La cadena puede resumirse técnicamente en cinco etapas.

1. Identificación del dispositivo

El exploit comienza enviando solicitudes CAPWAP Discovery y utiliza la respuesta para identificar parámetros como la revisión de hardware y la versión de FortiOS.

SOCRadar afirma además que las respuestas proporcionan información que permite calcular direcciones utilizadas posteriormente por el exploit. Esta capacidad reduce la eficacia de ASLR (Address Space Layout Randomization), una mitigación destinada a aleatorizar las ubicaciones de memoria y dificultar ataques de corrupción de memoria.

2. Preparación del heap

El siguiente paso utiliza mensajes CAPWAP para provocar un patrón predecible de asignaciones de memoria, una técnica denominada heap grooming.

El objetivo es organizar los bloques del heap de manera que un búfer controlado por el atacante quede situado junto a las estructuras internas que se pretenden corromper. El proceso cw_acd utiliza una lista doblemente enlazada para gestionar determinadas asignaciones de memoria.

3. Desbordamiento y corrupción de memoria

Una vez preparado el heap, el exploit utiliza un mensaje CAPWAP Image Data manipulado. Según el análisis de SOCRadar, una discrepancia entre el tamaño declarado y los datos realmente copiados provoca un desbordamiento de 16 bytes más allá del búfer esperado.

Esos bytes sobrescriben punteros de la estructura que administra la lista de memoria libre, proporcionando al atacante una base para transformar la corrupción en una operación de escritura sobre una dirección elegida.

4. Secuestro del flujo de ejecución

El exploit aprovecha la corrupción de los punteros de la lista para construir una primitiva de tipo write-what-where: esencialmente, la capacidad de escribir un valor controlado en una posición de memoria seleccionada.

Para superar protecciones como W^X/DEP, la investigación describe posteriormente el uso de Return-Oriented Programming (ROP) y código ya presente en el proceso. El resultado final permite redirigir el flujo de ejecución hacia funciones existentes del sistema.

5. Node.js como primer punto de ejecución

La cadena termina utilizando el runtime Node.js ya presente en FortiOS para iniciar una conexión inversa hacia la infraestructura del atacante.

Este detalle resulta particularmente relevante desde el punto de vista forense: la existencia de un proceso node por sí sola no demuestra compromiso, porque Node.js forma parte legítimamente de determinados componentes de FortiOS. La investigación debe correlacionar procesos, conexiones, argumentos y otros indicadores.

De la RCE a PivotC2

Tras obtener ejecución, el atacante utiliza un pequeño stager JavaScript para descargar una segunda etapa, descodificarla, almacenarla temporalmente y ejecutar PivotC2. SOCRadar identificó /tmp/.i.js como uno de los artefactos utilizados durante esta fase.

La versión recuperada, PivotC2 0.2.3, es un RAT basado en Node.js construido específicamente para la post-explotación de FortiGate. Su cliente inicia desde el firewall una conexión TLS saliente hacia el servidor de mando y control. Sobre esa única sesión, el protocolo multiplexa diferentes canales para ejecutar comandos y mover datos.

Entre sus capacidades se encuentran:

• ejecución de comandos y shells interactivos;
• lectura, escritura, carga y descarga de archivos;
• enumeración de interfaces, procesos y conexiones;
• resolución DNS y escaneo de redes;
• proxy SOCKS5 y HTTP;
• local y remote port forwarding;
• recolección de configuraciones de FortiGate;
• extracción de información sobre las redes internas;
• mantenimiento de la conexión con el C2 mediante reconexiones y heartbeat.

Estas funciones convierten al firewall en algo más peligroso que un simple host comprometido. PivotC2 puede utilizar el FortiGate como punto de pivote hacia redes que desde Internet no son directamente alcanzables.

El objetivo principal: configuraciones y credenciales

Una de las funciones más relevantes de PivotC2 es harvest. La herramienta analizada intenta recopilar diferentes artefactos de configuración de FortiOS:

/data/config/sys_global.conf.gz
/data/config/global_system_interface.gz
/data/config/sys_vd_root+root.conf.gz
/data/etc/fsv_sync.dat

Según SOCRadar, estos archivos proporcionan información global del sistema, interfaces, configuración de VDOM y material necesario para procesar determinados secretos almacenados por el dispositivo.

Los investigadores sostienen que las herramientas recuperadas estaban preparadas para obtener credenciales y secretos como PSK de VPN IPsec, credenciales SSL-VPN, claves Wi-Fi, credenciales de cuentas administrativas y secretos utilizados para LDAP.

Este comportamiento cambia sustancialmente la respuesta al incidente. Si un atacante ha tenido capacidad para ejecutar PivotC2, actualizar FortiOS evita que CVE-2025-25249 vuelva a utilizarse contra el dispositivo, pero no invalida los secretos que ya hayan podido ser extraídos.

Un modo automático para convertir el firewall en un pivote

SOCRadar describe además un modo --auto que reduce la intervención necesaria por parte del operador. Cuando un nuevo dispositivo se conecta al C2, el framework puede iniciar automáticamente la recopilación de configuraciones, extracción de credenciales, identificación de subredes internas y posterior reconocimiento de servicios.

La capacidad de proxy y port forwarding permite después encaminar herramientas externas a través del FortiGate comprometido. Desde la perspectiva de segmentación de red, esta es una de las consecuencias más graves: un equipo de seguridad situado en el perímetro puede convertirse en una plataforma de acceso a varios segmentos internos.

Los números, más de 30.000 objetivos, pero no 30.000 compromisos

La victimología debe tratarse con precisión. SOCRadar afirma haber encontrado más de 30.000 direcciones IP FortiGate en archivos utilizados como lista de objetivos. Eso no significa que 30.000 dispositivos hayan sido vulnerados.

Dentro del material analizado, los investigadores identificaron 178 sesiones que consideran infecciones confirmadas con PivotC2. Estados Unidos concentraría el mayor número, seguido de Chile, Colombia y Reino Unido. Estos números pertenecen a la telemetría y a los archivos analizados por SOCRadar; Fortinet no ha publicado, hasta el momento de este análisis, una cifra independiente equivalente.

SOCRadar también reconstruyó dos intrusiones contra organizaciones estadounidenses en las que, según su investigación, la actividad progresó desde el FortiGate hacia la red interna. Los investigadores observaron reconocimiento, túneles, obtención de credenciales de navegadores, movimiento lateral y exfiltración de archivos PST de Exchange hacia almacenamiento S3 controlado por los atacantes.

Indicadores de compromiso de PivotC2

SOCRadar publicó varios IOC relacionados con la campaña.

Infraestructura de red de PivotC2 a fecha de 10/09/2026

IP	Tipo	Asociación
46.151.29.58	IPv4	Nodo PivotC2
146.103.99.177	IPv4	Nodo PivotC2
45.138.16.182:9130	IPv4/puerto	Bridge asociado a obfs4proxy/Tor
89.217.174.207:9001	IPv4/puerto	Bridge asociado a obfs4proxy/Tor

Artefactos principales de PivotC2 a fecha de 10/09/2026

SHA-256	Archivo
2d338ffc8cc80293575c6800c059e33eb41e967907c20ba7687b2231c50837db	fortirun.bin
cc7f0660d56405cbdff157033d3e35305f063e62efaff6501d11e6a34e7bd151	payload.js
eb4d8aab4e687839c5478a7a3819b0a7a857555ed50fc159c026e99764a0c8a0	payload2.js
fe7da807a2b37a2bbd8c27830a9acc0d86ad8128f38489c493873c7e410c0408	payload_new.js

La investigación incluye hashes adicionales correspondientes a clientes PivotC2 y herramientas posteriores utilizadas en sistemas Windows.

La ausencia de estos IOC no demuestra que un FortiGate esté limpio. La infraestructura C2 puede cambiar, los artefactos pueden eliminarse y PivotC2 incluye una función destinada precisamente a borrar determinados rastros de la infección. A fecha del 10 de septiembre de 2026 esos son los IOC descubiertos.

-Guía práctica para administradores de FortiGate

1. Identificar versión y exposición

El primer paso es comprobar qué firmware ejecuta el dispositivo:

get system status

Fortinet utiliza este comando para mostrar, entre otros datos, versión y compilación de firmware instalada.

Después debe revisarse qué servicios están habilitados en las interfaces, revisar:

get system interface physical
show system interface

El objetivo no es únicamente responder «¿Estoy ejecutando una versión vulnerable?», sino también:

• ¿Existe fabric en alguna interfaz WAN o no confiable?
• ¿CAPWAP puede ser alcanzado desde Internet?
• ¿Qué interfaces permiten HTTPS, SSH u otros accesos administrativos?
• ¿Existe una red de gestión separada?
• ¿Los administradores tienen trusted hosts configurados?

2. Actualizar FortiOS siguiendo la ruta indicada por Fortinet

Los dispositivos dentro de los rangos vulnerables deben migrar, como mínimo, a una versión que contenga la corrección:

6.4  → 6.4.17+
7.0  → 7.0.18+
7.2  → 7.2.12+
7.4  → 7.4.9+
7.6  → 7.6.4+

En entornos en producción no hay que actualizar los equipos directamente de una version a otra sin antes mirar el Upgrade Path que da Fortinet. Esta es una herramienta que nos dan para poner nuestro equipo, la version actual de este y el objetivo de version a actualizar. Una vez puestos los datos, nos indican la ruta de actualización que hay que seguir. Recomiendo seguir al pie de la letra la ruta de actualización.

Fortinet confirma en las notas de parche que las ramas que tienen version 7.0.18, 7.2.12, 7.4.9 y 7.6.4 corrigen CVE-2025-25249.

3. Eliminar fabric de interfaces donde no sea necesario

Fortinet proporcionó como mitigación retirar el acceso fabric de interfaces que no necesiten prestar ese servicio.

Por ejemplo, una configuración como:

config system interface
    edit "port1"
        set allowaccess fabric ssh https
    next
end

puede convertirse, si fabric no es necesario:

config system interface
    edit "port1"
        set allowaccess ssh https
    next
end

El ejemplo procede de la mitigación asociada al aviso FG-IR-25-084. Antes de aplicarlo debe sustituirse port1 por la interfaz real y conservar únicamente los servicios administrativos que sean realmente necesarios.

En interfaces públicas, una postura más restrictiva consiste en no habilitar administración directa desde Internet siempre que la arquitectura lo permita.

4. Si CAPWAP es necesario, limitar quién puede acceder

Cuando Security Fabric o CAPWAP sea necesario, Fortinet propone utilizar políticas local-in para permitir los puertos UDP/5246–5249 únicamente desde dispositivos autorizados y denegar el resto.

El esquema es:

CAPWAP autorizado
        ↓
UDP 5246-5249
        ↓
[ FortiGate ]
        ↑
RESTO DE ORÍGENES
      BLOQUEADOS

Las políticas local-in son especialmente relevantes porque regulan tráfico cuyo destino es el propio FortiGate, a diferencia de una política firewall convencional que controla principalmente tráfico que atraviesa el dispositivo.

Por tanto, proteger CAPWAP únicamente mediante reglas pensadas para tráfico reenviado puede no responder al problema correcto.

5. Revisar sesiones hacia los C2 conocidos

Antes de reiniciar o limpiar un dispositivo sospechoso, resulta recomendable preservar evidencias y revisar conexiones existentes.

SOCRadar proporciona dos IP principales asociadas a PivotC2. La documentación actual de Fortinet utiliza dst como filtro de dirección de destino:

diagnose sys session filter clear
diagnose sys session filter dst 146.103.99.177
diagnose sys session list
diagnose sys session filter clear

y:

diagnose sys session filter dst 46.151.29.58
diagnose sys session list
diagnose sys session filter clear

El uso de dst está documentado actualmente por Fortinet para filtrar la tabla de sesiones.

Conviene limpiar el filtro entre búsquedas para evitar interpretar resultados condicionados por una consulta anterior.

6. Buscar artefactos de PivotC2

La investigación de SOCRadar propone comprobar el fichero temporal utilizado por el stager:

fnsysctl ls -la /tmp/.i.js
fnsysctl ls -la /tmp/

También puede revisarse la actividad de Node.js:

diagnose sys process list | grep node

Sin embargo, un proceso Node.js no constituye por sí solo un IOC, porque FortiOS utiliza legítimamente este runtime. Debe correlacionarse con conexiones anómalas, argumentos, ficheros, marcas temporales y registros del dispositivo.

7. Auditar la configuración completa

Si el FortiGate estuvo expuesto durante el periodo en que SOCRadar afirma haber observado explotación, la revisión debería extenderse más allá de la versión de firmware.

Entre los elementos de interés se encuentran:

• cuentas administrativas desconocidas;
• cambios en permisos;
• configuraciones VPN nuevas o modificadas;
• cambios en LDAP/RADIUS;
• certificados;
• PSK de túneles IPsec;
• reglas de firewall;
• políticas local-in;
• nuevas rutas;
• cambios de DNS;
• interfaces y redes añadidas;
• conexiones administrativas desde IP desconocidas.

Fortinet recomienda, ante sospechas de compromiso, comparar la configuración actual con una copia conocida como legítima y prestar atención a cuentas, usuarios VPN y modificaciones no autorizadas.

8. Fortalecer el plano de administración

Fortinet desaconseja exponer los servicios administrativos directamente sobre una interfaz WAN. Su guía de hardening recomienda utilizar una interfaz de administración confiable o una conexión VPN y, cuando sea posible, una red de gestión fuera de banda.

Si el acceso remoto directo resulta inevitable, deberían combinarse varias capas:

Trusted Hosts

Cada administrador puede limitarse a direcciones IP o subredes concretas. FortiOS permite definir hasta diez trusted hosts por cuenta administrativa.

Local-in policies

Permiten controlar granularmente qué orígenes pueden alcanzar servicios pertenecientes al propio FortiGate.

MFA

Debe utilizarse para administradores y accesos VPN siempre que resulte compatible con el entorno. Fortinet volvió a recomendar expresamente MFA durante la campaña FortiBleed.

Red de gestión separada

Los equipos de administración deberían llegar al firewall mediante una red dedicada, VPN administrativa o infraestructura fuera de banda, en lugar de publicar directamente HTTPS o SSH sobre Internet.

9. Centralizar los registros fuera del firewall

Una de las dificultades de investigar dispositivos perimetrales comprometidos es que el atacante puede operar sobre el mismo sistema que genera parte de las evidencias.

FortiOS diferencia entre tráfico forward y tráfico local-in/local-out. Este último es particularmente relevante para detectar conexiones destinadas al propio firewall o generadas por él. Fortinet permite registrar este tráfico y utilizar las políticas local-in para obtener mayor visibilidad forense.

En entornos empresariales, los registros deben exportarse a FortiAnalyzer, SIEM o una infraestructura syslog externa. De este modo, el atacante con acceso al FortiGate tiene más dificultades para eliminar toda la evidencia histórica.

¿Qué hacer si aparece un IOC?

Aquí existe una diferencia fundamental entre vulnerable y comprometido.

Un FortiGate vulnerable pero sin indicios de explotación necesita actualizarse y reducir su superficie expuesta.

Un FortiGate en el que aparezcan conexiones a infraestructura C2, /tmp/.i.js u otras evidencias coherentes con PivotC2 debe abordarse como un posible incidente de seguridad.

SOCRadar es explícito al respecto: instalar el parche no elimina PivotC2 si el exploit y Post-explotacion ya está ejecutándose, ni revoca credenciales que previamente hayan sido extraídas.

Antes de destruir evidencias deberían preservarse registros, diagnósticos y configuraciones. Fortinet recomienda precisamente conservar logs, copias de configuración y salidas de diagnóstico antes de formatear o recargar un dispositivo que se considere comprometido.

La respuesta debería seguir una secuencia similar a:

1. Aislar el FortiGate de conexiones no necesarias conservando, cuando sea posible, acceso administrativo controlado.
2. Preservar logs, configuración y evidencias antes de reiniciar o limpiar.
3. Determinar si existen indicadores compatibles con PivotC2.
4. Examinar equipos internos a los que el firewall pudiera haber servido de pivote.
5. Si se confirma el compromiso, realizar una instalación limpia de FortiOS desde una imagen verificada.
6. Restaurar únicamente una configuración conocida como legítima o reconstruirla manualmente.
7. Actualizar a una versión corregida siguiendo el upgrade path soportado.
8. Rotar todos los secretos potencialmente expuestos.
9. Mantener monitorización reforzada sobre la infraestructura interna.

Fortinet contempla el reformateo y la instalación limpia en sus recomendaciones para determinados escenarios de compromiso, así como la restauración desde una copia conocida como segura y la renovación de credenciales y certificados.

La rotación de credenciales no es opcional si se confirma PivotC2

La capacidad de PivotC2 para recolectar configuraciones convierte este punto en una de las medidas más importantes.

Si existe evidencia fiable de ejecución del malware, deberían considerarse potencialmente expuestos, según corresponda al entorno:

• contraseñas administrativas;
• cuentas locales;
• credenciales SSL-VPN;
• PSK de IPsec;
• secretos de LDAP;
• secretos RADIUS;
• claves Wi-Fi;
• certificados y claves privadas accesibles;
• otras credenciales presentes en configuraciones exportadas o servicios relacionados.

SOCRadar recomienda asumir la exfiltración completa de la configuración cuando aparecen artefactos de PivotC2. Fortinet, en sus propias guías de recuperación de dispositivos comprometidos, recomienda igualmente renovar administradores, usuarios locales y VPN, secretos RADIUS, PSK de IPsec, certificados y credenciales LDAP cuando se produce acceso no autorizado a la configuración.

El análisis no termina en FortiGate

PivotC2 está construido precisamente para acceder a otros sistemas como medio de pivoting y post-explotacion del FortiGate.

SOCRadar observó en dos intrusiones reconocimiento de Active Directory, proxies internos, túneles SSH, habilitación de RDP, extracción de credenciales de navegadores y exfiltración hacia almacenamiento externo.

Por ello, ante un FortiGate confirmado como comprometido, la investigación debe extenderse a los segmentos accesibles desde él y buscar actividad anómala posterior al primer acceso, incluso aunque el firewall ya haya sido reinstalado.

CIERRE, El firewall como punto de entrada a la infraestructura interna

La campaña descrita por SOCRadar muestra por qué una vulnerabilidad en un dispositivo perimetral tiene implicaciones diferentes a las de un sistema convencional. Un FortiGate puede concentrar acceso a múltiples segmentos, terminar conexiones VPN, almacenar secretos y disponer de visibilidad privilegiada sobre la arquitectura interna.

CVE-2025-25249 llevaba corregida meses, antes de la actividad investigada por SOCRadar, fechada desde julio del 2026. El caso vuelve a poner el foco no solo en la rapidez de aplicación de parches, sino también en el tiempo durante el que servicios innecesarios permanecen accesibles desde redes no confiables.

Para los administradores, la respuesta a PivotC2 no debe limitarse a comprobar el número de versión de FortiOS. Auditar la exposición de CAPWAP y Security Fabric, proteger el plano de administración, externalizar los registros y tratar como comprometidos los secretos de un dispositivo en el que se confirme la intrusión son medidas necesarias para evitar que un fallo en el perímetro se convierta en un compromiso serio de la red interna.

Fuentes usadas en el analisis tecnico de PivotC2 y la investigacion de SOCRadar

[1] Fortinet PSIRT — FG-IR-25-084: CVE-2025-25249
Aviso de seguridad original del fabricante. Fuente principal para la vulnerabilidad, productos afectados, versiones corregidas y mitigaciones oficiales.
Fortinet PSIRT — FG-IR-25-084

[2] CVE Program — CVE-2025-25249
Registro oficial de la vulnerabilidad en el programa CVE. Útil para contrastar descripción, CNA, referencias y metadatos.
CVE-2025-25249 — CVE.org

[3] NIST National Vulnerability Database — CVE-2025-25249
Ficha de NVD utilizada para contrastar métricas CVSS, CWE, productos afectados y posibles discrepancias de valoración.
CVE-2025-25249 — NVD

[4] INCIBE-CERT — Vulnerabilidad en Fortinet CVE-2025-25249
Fuente institucional española. Confirma CWE-122, publicación del 13 de enero de 2026, CVSS v3.1 8,1
INCIBE-CERT — CVE-2025-25249

[5] SOCRadar Threat Research Unit — “CVE-2025-25249 Exploitation Delivers PivotC2, a FortiGate Post-Exploitation RAT”
Fuente principal para toda la parte PivotC2 del artículo. Publicada el 8 de septiembre de 2026. Documenta la explotación activa, fortirun.bin, el stager, PivotC2 0.2.3, arquitectura C2, protocolo, túneles, extracción de configuraciones y credenciales, modo automático, IOC, victimología y actividad posterior al compromiso.
Investigación técnica de SOCRadar sobre PivotC2

[6] CERT-FR — Multiples vulnérabilités dans les produits Fortinet
Aviso del CERT francés que referencia directamente FG-IR-25-084 y permite corroborar de forma independiente la existencia del aviso y las actualizaciones para productos Fortinet.
CERT-FR — Aviso Fortinet de enero de 2026

Fuentes de las versiones corregidas de FortiOS

[7] Fortinet — FortiOS 7.0.18 Release Notes: Resolved Issues
Fortinet confirma que FortiOS 7.0.18 deja de ser vulnerable a CVE-2025-25249.
FortiOS 7.0.18 — Resolved Issues

[8] Fortinet — FortiOS 7.2.12 Release Notes: Resolved Issues
Confirma la corrección de CVE-2025-25249 en FortiOS 7.2.12.
FortiOS 7.2.12 — Resolved Issues

[9] Fortinet — FortiOS 7.4.9 Release Notes: Resolved Issues
Confirma la corrección en FortiOS 7.4.9.
FortiOS 7.4.9 — Resolved Issues

[10] Fortinet — FortiOS 7.6.4 Release Notes: Resolved Issues
Confirma la corrección en FortiOS 7.6.4.
FortiOS 7.6.4 — Resolved Issues

Fuentes del CAPWAP, Security Fabric y mitigación de CVE-2025-25249

[11] Fortinet — Changes in CLI defaults, FortiOS 6.2.3
Documentación oficial que explica que Fortinet consolidó FortiTelemetry y capwap en fabric dentro de system interface. Es útil para justificar técnicamente la relación entre set allowaccess fabric y la superficie CAPWAP.
Fortinet — CAPWAP/FortiTelemetry y allowaccess fabric

[12] Fortinet — FortiExtender Controller / CAPWAP access
Fortinet documenta explícitamente append allowaccess fabric para habilitar acceso CAPWAP en una interfaz.
Fortinet — Enable CAPWAP access with fabric

[13] Qualys ThreatPROTECT — FortiOS and FortiSwitchManager Code Execution Vulnerability (CVE-2025-25249)
Reproduce las mitigaciones asociadas al aviso de Fortinet: retirar fabric cuando no sea necesario o restringir UDP/5246-5249 mediante una política local-in. También recoge versiones afectadas y corregidas.
Qualys — CVE-2025-25249 y mitigaciones CAPWAP

Fuentes de la guia de hardening del plano de administración

[14] Fortinet — Local-in Policy
Explica que las políticas local-in controlan el tráfico cuyo destino es el propio FortiGate, frente al tráfico que atraviesa el firewall. Es la base documental de la sección donde se restringen servicios administrativos y CAPWAP.
Fortinet — Local-in Policy

[15] Fortinet — Local-in and Local-out Logging
Referencia para la parte de análisis forense y monitorización. Fortinet diferencia el tráfico destinado al dispositivo y el generado por este del tráfico forward, y permite registrar tráfico local-in.
Fortinet — Local-in and Local-out Logging

[16] Fortinet — FortiGate Hardening
Fuente oficial para la recomendación de no publicar directamente los servicios administrativos sobre WAN, utilizar interfaces de gestión confiables, VPN y, cuando sea posible, gestión fuera de banda. También recomienda local-in policies y trusted hosts.
Fortinet — FortiGate Hardening Guide

[17] Fortinet — Administrator Account Options
Fuente para MFA y Trusted Hosts. Fortinet permite restringir una cuenta administrativa a direcciones o subredes concretas y admite hasta diez trusted hosts por administrador.
Fortinet — Administrator Account Options

Fuentes de comandos de comprobación y hunting

[18] Fortinet — Troubleshooting Methodologies
Referencia oficial para get system status, utilizado en el artículo para identificar versión de firmware y obtener información general del FortiGate.
Fortinet — Troubleshooting Methodologies

[19] Fortinet — Checking FortiOS Network Settings
Documenta show system interface <interface> y la revisión de los protocolos administrativos habilitados en cada interfaz.
Fortinet — Checking FortiOS Network Settings

[20] Fortinet — Using a Session Table / CLI Reference
Fuente para diagnose sys session list y los filtros de sesión. La documentación actual utiliza dst para filtrar por dirección IP de destino.
Fortinet — diagnose sys session CLI reference

Fuentes sobre la actualización en fortinet y recuperación

[21] Fortinet — Upgrade Path Tool
Herramienta oficial para determinar la ruta de actualización válida según modelo, versión de origen y versión objetivo.
Fortinet — Upgrade Path Tool

[22] Fortinet — Upgrade Information
Documentación oficial que explica que las rutas de actualización soportadas deben consultarse antes de migrar FortiOS.
Fortinet — FortiOS Upgrade Information

[23] Fortinet Community — Recommended steps in case of a compromised host
Referencia especialmente importante para la parte de respuesta a incidentes. Fortinet recomienda restaurar una configuración conocida como legítima o crear una limpia, cambiar credenciales administrativas y VPN, renovar secretos RADIUS/IPsec, sustituir certificados, restringir acceso administrativo, utilizar gestión fuera de banda y MFA.
Fortinet — Recuperación ante dispositivo comprometido

Fuentes para el seguimiento del ataque

[24] Fortinet PSIRT Blogs
Utilizada para comprobar si Fortinet había publicado, a fecha de cierre del análisis, un análisis específico sobre PivotC2 además del advisory original de CVE-2025-25249.
Fortinet — PSIRT Blogs

[25] CISA — Known Exploited Vulnerabilities Catalog (KEV)
Fuente oficial para comprobar si CVE-2025-25249 entra en el catálogo de vulnerabilidades explotadas conocidas por CISA. CISA define KEV como su fuente autorizada para vulnerabilidades cuya explotación en activos reales ha sido establecida conforme a sus criterios.
CISA — Known Exploited Vulnerabilities Catalog