Ciberseguridad · Aviso

Fortinet FortiGate / FortiOS (SSL VPN y gestión) · Credenciales de VPN filtradas y usadas en ataques

CISA y Fortinet piden actuar de inmediato tras «FortiBleed», un listado filtrado de credenciales de unos 74.000 cortafuegos y pasarelas VPN de Fortinet que ya se está usando para intentar entrar en equipos expuestos a Internet.

Publicado 11 noviembre 2026 Lectura 8 min Ref. Sin CVE CVSS — Estado Explotación activa

Resumen

«FortiBleed» no es una vulnerabilidad nueva ni tiene CVE: es la aparición pública de un listado con nombres de usuario, correos y contraseñas en texto plano asociados a unos 74.000 dispositivos Fortinet (cortafuegos FortiGate y pasarelas VPN) accesibles desde Internet. Parte de esas credenciales se ha verificado como válida y los atacantes ya las están empleando para intentar iniciar sesión en los equipos expuestos. El origen exacto de los datos no está confirmado. La respuesta no pasa por un parche, sino por cerrar sesiones, rotar contraseñas, activar doble factor y dejar de exponer a Internet las interfaces de gestión.

Materias: Ciberseguridad, Filtración de credenciales, VPN y acceso remoto, Protección de infraestructuras, RGPD y notificación de brechas

La Agencia de Ciberseguridad y de Seguridad de las Infraestructuras de Estados Unidos (CISA, por sus siglas en inglés) ha pedido a las organizaciones que usan Fortinet que refuercen sus dispositivos de inmediato. El motivo es «FortiBleed», el nombre con el que se conoce un listado filtrado de credenciales vinculado a unos 74.000 cortafuegos y pasarelas de VPN expuestos a Internet. No se trata de un fallo técnico nuevo, sino de llaves de acceso (usuarios y contraseñas) que han quedado al descubierto y que los atacantes ya están probando contra los equipos accesibles desde la red.

Descripción

Qué es FortiBleed

Un cortafuegos (o firewall) es el equipo que filtra el tráfico entre Internet y la red interna de una organización; una VPN (red privada virtual) es el canal cifrado por el que los empleados se conectan a esa red desde fuera. Fortinet es uno de los mayores fabricantes de estos equipos, con su línea FortiGate y el sistema operativo FortiOS que los gobierna; el SSL VPN es precisamente la función que publica ese acceso remoto a través del navegador.

«FortiBleed» no es una vulnerabilidad ni lleva asignado ningún identificador CVE. Es la publicación de un conjunto de credenciales robadas: nombres de usuario, direcciones de correo y contraseñas en texto plano (es decir, sin cifrar ni proteger con ningún algoritmo) relacionadas con dispositivos Fortinet concretos. El investigador que lo detectó, Volodymyr «Bob» Diachenko, encontró un servidor controlado por atacantes que contenía datos de acceso para 73.932 direcciones (URLs) de cortafuegos en todo el mundo, cifra que CISA redondea a «aproximadamente 74.000 dispositivos».

A quién afecta

El alcance es global y transversal: según el análisis de Hudson Rock recogido por la prensa especializada, el listado abarca 21.632 dominios únicos repartidos por 194 países, con entidades de la administración pública, infraestructuras críticas y grandes empresas entre las citadas. El riesgo real, sin embargo, se concentra en un perfil muy concreto: organizaciones que exponen a Internet el SSL VPN o la interfaz de administración de su FortiGate. Si esas interfaces no son accesibles desde la red pública, el aprovechamiento de las credenciales filtradas se vuelve mucho más difícil.

Qué versiones afecta

Al no tratarse de un fallo de software, no hay una lista de versiones «vulnerables» frente a «corregidas». El problema es independiente de la versión: afecta a cualquier FortiGate cuyas credenciales figuren en la filtración o que mantenga contraseñas débiles y sin segundo factor en interfaces expuestas. Lo que sí depende de la versión es la capacidad de protegerse: Fortinet recomienda actualizar a las últimas versiones de las ramas 7.4, 7.6 u 8.0, que permiten almacenar las contraseñas de administrador con el algoritmo de derivación de claves PBKDF2 (un método que dificulta mucho recuperar la contraseña original si el fichero vuelve a filtrarse), frente a los esquemas heredados más débiles.

Mecánica

Cómo se usa la filtración

La idea central es sencilla: un atacante que tiene la llave no necesita forzar la cerradura. Con credenciales válidas en la mano, el acceso se intenta directamente con las técnicas habituales basadas en credenciales:

Credential stuffing (reutilización de credenciales): probar de forma automatizada los usuarios y contraseñas filtrados, aprovechando que muchas no se han cambiado.
Password spraying: ensayar unas pocas contraseñas comunes contra muchas cuentas para no disparar los bloqueos.
Fuerza bruta: probar combinaciones de forma masiva, sobre todo contra equipos con contraseñas débiles y sin doble factor.

El investigador Diachenko describe una operación a gran escala y afirma haber observado alrededor de 1.160 millones de intentos de acceso contra más de 320.000 objetivos FortiGate, junto con el robo de credenciales y su posible uso para «saltar» a la red interna y a los controladores de dominio de Active Directory (el directorio que gestiona usuarios y permisos en entornos Windows). Conviene subrayar que esas cifras y detalles proceden del análisis del investigador y no han sido verificados de forma independiente en su totalidad.

De dónde salen los datos (y qué no está confirmado)

El punto más incierto es el origen del listado. Las fuentes coinciden en que no está claro si las credenciales se obtuvieron explotando vulnerabilidades antiguas de Fortinet, mediante un fallo nuevo o por otros métodos. Se han planteado hipótesis —INCIBE-CERT menciona con cautela que el origen «podría vincularse» a la explotación de vulnerabilidades ya parcheadas como CVE-2023-27997 (corregida en junio de 2023), y otros analistas apuntan a fallos posteriores—, pero ninguna está confirmada como vector de esta filtración. El analista Kevin Beaumont, que verificó que parte de los datos son auténticos, sostiene que probablemente procedan de configuraciones exportadas de los propios equipos. No se debe especular sobre la autoría: la operación se ha atribuido de forma preliminar a un grupo de habla rusa, pero esa atribución no está confirmada de manera independiente.

Respuesta del creador

La respuesta de Fortinet

El equipo de respuesta de incidentes de Fortinet (PSIRT) publicó el 19 de junio de 2026 un análisis en el que fija su posición con claridad. En sus palabras, «esto no es una vulnerabilidad nueva de Fortinet, y esta actividad no está relacionada con ningún incidente o aviso reciente». El fabricante atribuye lo observado a reutilización de credenciales de incidentes anteriores y técnicas de fuerza bruta contra dispositivos con mala higiene de contraseñas y sin MFA (autenticación multifactor). Fortinet afirma además haber identificado los sistemas potencialmente comprometidos y estar notificando a los clientes afectados.

La respuesta de las autoridades

CISA emitió el 18 de junio de 2026 una alerta —revisada por última vez el 22 de junio— titulada «CISA insta a reforzar los dispositivos Fortinet tras informes de exposición de credenciales», en la que dice ser conocedora de «informes globales de actores maliciosos que han atacado dispositivos Fortinet accesibles desde Internet» usando credenciales comprometidas, y pide actuar «de inmediato». En España, INCIBE-CERT publicó el 22 de junio de 2026 su propia bitácora de seguridad sobre la exposición de credenciales en dispositivos Fortinet, con recomendaciones alineadas y la advertencia de que no todas las credenciales del listado siguen siendo válidas, aunque algunas sí pueden serlo.

Parches y mitigaciones

¿Hay parche?

No, y es importante entenderlo: como no es un fallo de software, no existe un parche que «cierre» FortiBleed. La protección no consiste en actualizar y olvidar, sino en asumir que las contraseñas afectadas han quedado expuestas y cortar cualquier acceso que pudiera estar aprovechándose. Tanto CISA como Fortinet coinciden en las acciones a aplicar de inmediato.

Qué hacer hoy

Cerrar todas las sesiones. Finalizar todas las sesiones activas de SSL VPN y administrativas, para expulsar a quien ya pudiera estar dentro.
Rotar todas las contraseñas. Restablecer todas las credenciales de VPN y de administración, especialmente en los sistemas accesibles desde Internet, y aplicar políticas de contraseñas robustas.
Activar MFA resistente al phishing. Exigir autenticación multifactor en todos los accesos administrativos y remotos. «Resistente al phishing» significa usar métodos (como llaves físicas FIDO2) que no se pueden robar engañando al usuario para que teclee un código.
Endurecer el almacenamiento de credenciales. Confirmar el uso del algoritmo PBKDF2 para guardar las contraseñas de administrador y eliminar los esquemas heredados más débiles. Fortinet indica que para ello conviene actualizar a las últimas versiones de las ramas 7.4, 7.6 u 8.0.
Reducir la superficie de ataque. Dejar de exponer a Internet las interfaces de gestión del cortafuegos; restringir la administración a redes internas de confianza (mediante trusted hosts o políticas local-in) o, mejor aún, eliminar la administración desde Internet por completo.
Revisar registros y cuentas. Buscar accesos no autorizados y movimientos laterales en los logs de cortafuegos, VPN, autenticación y controladores de dominio; verificar el inventario de cuentas administrativas y eliminar usuarios sospechosos o no reconocidos (Fortinet advierte de nombres como forticloud, fortiuser o fortinet-support).

Si el equipo pudo ser la puerta de entrada

Cuando el dispositivo perimetral ha podido servir de acceso, el problema rara vez se queda en el propio cortafuegos. Conviene tratar el equipo como comprometido, seguir la guía de recuperación de Fortinet y buscar de forma proactiva indicios de compromiso en Active Directory, para detectar si el atacante dio el salto a la red interna.

Apunte jurídico

Para las organizaciones sujetas al RGPD, si se confirma que se ha accedido a datos personales a través de uno de estos equipos, se activan las obligaciones de notificación: comunicación a la autoridad de control (la AEPD en España) en un plazo máximo de 72 horas (art. 33 del RGPD) y, cuando el riesgo para los afectados sea alto, también a los propios interesados (art. 34). Documentar el incidente y las medidas adoptadas forma parte del principio de responsabilidad proactiva.