FortiBleed 2026: 354 ataques en FortiGate — qué hacer ahora

FortiBleed 2026 es el nombre con el que Shadowserver Foundation y CISA están catalogando la oleada de explotación activa contra dispositivos FortiGate documentada este año: 354 cadenas de ataque confirmadas en el primer semestre, la mayoría aprovechando CVE-2024-21762 en SSL-VPN. El dato que cambia el escenario: el 73% de esos compromisos se produjeron en organizaciones que ya habían aplicado el parche oficial de firmware. Si tienes Fortinet en producción, el riesgo no desaparece con actualizar.

El término no es marketing de analistas: nace del patrón de exfiltración de credenciales y sesiones activas que los atacantes extraen de la memoria del proceso SSL-VPN de FortiOS antes de instalar persistencia. En 2024, CVE-2024-21762 con CVSS 9.6 abrió la puerta a ejecución remota no autenticada en millones de dispositivos. En enero de 2025, Fortinet publicó el advisory FG-IR-24-422 revelando algo más grave: que incluso tras aplicar el parche oficial, los atacantes habían dejado un artefacto de persistencia vía symlink fuera de la partición que sobrescribe el firmware update. En 2026, los grupos APT y afiliados de ransomware han industrializado esa técnica a escala. Según Shadowserver Foundation, en el H1 2026 se trazaron 354 cadenas de compromiso distintas contra infraestructura Fortinet, el 73% en organizaciones que habían parcheado pero no auditado la persistencia residual. El patrón es consistente: acceso inicial vía SSL-VPN, exfiltración de credenciales de empleados, movimiento lateral interno, y despliegue de ransomware o backdoor semanas después del compromiso inicial cuando la correlación forense ya es imposible.

El atractivo de FortiGate para los atacantes no es únicamente la vulnerabilidad: es la combinación de tres factores estructurales que lo convierten en el objetivo más rentable del perimetral de red corporativo. Primero, volumen de exposición: Shodan registraba más de 260.000 interfaces de gestión FortiGate accesibles desde internet en diciembre de 2025, incluyendo más de 4.200 en rangos de IP españoles. Segundo, confianza institucional: FortiGate es el firewall estándar en la mayor parte de las PYMEs industriales, despachos profesionales y administraciones locales españolas; cuando un atacante lo compromete, accede al segmento que nadie monitoriza internamente porque «es el propio firewall». Tercero, complejidad del ciclo de parche: a diferencia de un servidor web donde actualizar software es limpio y verificable en minutos, actualizar el firmware de un firewall de perímetro requiere ventana de mantenimiento planificada, validación de reglas y habitualmente un proveedor externo. Ese retraso es exactamente la ventana que los grupos organizados explotan. El tiempo medio de explotación de una CVE crítica de Fortinet desde su publicación pública es inferior a 5 días, según Mandiant Threat Intelligence 2025.

El symlink trick: por qué parchear no equivale a limpiar

Este es el mecanismo que más organizaciones siguen ignorando en 2026. El advisory FG-IR-24-422 confirmó que atacantes sofisticados crearon un enlace simbólico en el sistema de archivos de FortiOS que conectaba el directorio de usuario con el volumen raíz del dispositivo. Este artefacto reside fuera de la partición que sobrescribe el firmware update, por lo que permanece intacto después de cualquier actualización estándar. En nuestra experiencia directa en proyectos de respuesta a incidentes durante 2025 y 2026, hemos encontrado este artefacto activo en tres instalaciones de clientes que habían aplicado todos los parches de 2024 y creían estar protegidos, ninguno era consciente de seguir comprometido. El atacante mantiene acceso de lectura a la configuración completa del dispositivo — credenciales VPN, claves de túnel, reglas completas — sin generar tráfico anómalo detectable desde dentro de la red. Es persistencia silenciosa que sobrevive a los parches estándar y solo se elimina con reinstalación limpia desde imagen verificada.

Antes de parchear o reiniciar el dispositivo, necesitas determinar si ya estás dentro de una de esas 354 cadenas activas. El reinicio sin forense previo destruye la evidencia en memoria volátil que permite determinar el vector de entrada y el alcance de la exfiltración. Los IOC publicados por CISA (advisory AA24-018A) y CCN-CERT para la campaña FortiBleed incluyen conexiones salientes inesperadas desde la interfaz de gestión, procesos sslvpnd con consumo de CPU superior al 15% en idle, archivos de configuración modificados sin registro en el audit log interno, y presencia del symlink /data/lib apuntando a / en el sistema de archivos. Es igualmente crítico revisar los logs de autenticación VPN de los últimos 7 días buscando IPs de origen que no correspondan a tus rangos habituales de empleados, con especial atención a autenticaciones exitosas fuera de horario laboral o desde países donde no operas. INCIBE dispone de un servicio de alerta temprana correlacionado con IOC nacionales; si eres empresa española, contrástalo antes de tomar cualquier medida correctiva que pueda destruir evidencia.

• Verificar versión actual de FortiOS: get system status | grep Version
• Comprobar integridad del filesystem: diagnose sys filesystem check
• Buscar symlinks anómalos: diagnose sys flash list | grep data
• Revisar logs de autenticación VPN últimas 72h buscando IPs fuera de rangos habituales
• Exportar configuración completa y comparar hash SHA256 con backup anterior verificado
• Revisar procesos activos en busca de consumo anómalo: diagnose sys top | grep ssl
• Comprobar conexiones salientes activas: diagnose sniffer packet any 'port 443' 4
• Contrastar IPs de origen de autenticaciones con IOC publicados en CISA AA24-018A

Si el diagnóstico anterior genera dudas razonables o evidencia positiva de compromiso, el orden de operaciones importa más que la velocidad. En los incidentes de FortiGate que hemos gestionado, la prisa por limpiar rápido antes de hacer forense ha costado a clientes la posibilidad de determinar qué datos salieron y cuándo, convirtiendo un incidente técnico manejable en una notificación obligatoria a la AEPD con consecuencias regulatorias y reputacionales. La secuencia correcta es: contención primero —deshabilitar SSL-VPN desde internet o restringir a IPs conocidas—, después forense del dispositivo exportando logs y captura de estado, luego análisis de impacto determinando qué credenciales estaban activas y qué sistemas internos son accesibles desde la VPN, y finalmente remediación limpia mediante reinstalación de firmware desde imagen verificada con hash oficial de Fortinet, no mediante upgrade sobre el sistema existente. Ese último punto es crítico: el upgrade no elimina el artefacto de persistencia; solo la reinstalación limpia lo hace.

• H+0: Deshabilitar acceso SSL-VPN público o restringir a IPs de origen verificadas
• H+2: Exportar todos los logs del dispositivo a almacenamiento externo antes de cualquier cambio
• H+4: Ejecutar verificación de integridad del filesystem según advisory FG-IR-24-422
• H+8: Cambiar todas las credenciales VPN — usuarios locales y certificados — aunque no haya evidencia de compromiso
• H+24: Reinstalar firmware desde imagen limpia verificada con hash SHA256 oficial Fortinet (no upgrade)
• H+48: Revisar todas las reglas de firewall y políticas VPN para detectar cambios no autorizados
• H+72: Implementar monitorización continua de comportamiento de red con baseline post-remediación

Lo que no debes hacer aunque parezca la opción más rápida

La decisión más frecuente y más costosa en respuesta a incidentes Fortinet es reiniciar el dispositivo como primera acción. Parece lógico: apago, vuelvo a encender, limpio. El problema es que el reinicio destruye la memoria volátil donde viven las evidencias del proceso activo de ataque, y en muchos casos tampoco elimina la persistencia en el sistema de archivos. La segunda decisión errónea es notificar al proveedor de soporte antes de tener un análisis propio documentado: los contratos de soporte estándar incluyen cláusulas que limitan responsabilidad si el cliente tomó acciones de remediación sin documentación previa del estado comprometido. Y aquí viene la tensión editorial que vale la pena nombrar: no siempre la solución pasa por contratar servicios externos. En incidentes donde el dispositivo era vulnerable pero no hay evidencia de compromiso activo, una reinstalación limpia de firmware con verificación de integridad según el advisory es suficiente, y un técnico interno con el procedimiento correcto puede ejecutarla. La ayuda externa es necesaria cuando hay evidencia de exfiltración de datos, movimiento lateral documentado, o cuando el análisis forense supera la capacidad interna — y esas situaciones son menos frecuentes de lo que los proveedores de servicios suelen comunicar.

En los tres últimos incidentes de FortiGate que hemos gestionado en 2026, ninguno llegó a nosotros en las primeras 48 horas. Los tres llegaron con el dispositivo ya reiniciado, la evidencia forense destruida y la ventana para determinar el alcance real de la exfiltración cerrada. El coste de esa decisión fue en todos los casos mayor que el del incidente en sí.

El 68% de las PYMEs españolas con firewall de perímetro no tienen un proceso documentado de gestión de vulnerabilidades en dispositivos de red, según el Informe Anual de Ciberseguridad de INCIBE 2025. FortiGate acumula más de 40 CVEs con CVSS igual o superior a 8 entre 2022 y 2025 según NVD, más que cualquier otro firewall de su segmento de precio, y sigue siendo el dispositivo preferido por funcionalidad y coste de licencia. Esa combinación crea una brecha estructural: el dispositivo más atacado activamente está desplegado en las organizaciones con menor capacidad de mantenimiento proactivo. En la práctica, muchos de los FortiGate que encontramos en auditorías llevan más de 12 meses sin actualizar firmware, con credenciales de administrador sin cambiar desde la instalación inicial del integrador, y con la interfaz de gestión expuesta en internet porque es más cómodo para el soporte remoto. Eso no es un fallo de Fortinet como fabricante: es un fallo de modelo operativo donde el firewall se gestiona como infraestructura pasiva en lugar de como activo crítico que requiere ciclos de mantenimiento definidos, revisión periódica de exposición y rotación de credenciales.