Fortinet dijo el miércoles que había observado un “abuso reciente” de una vulnerabilidad de cinco años en FortiOS SSL VPN en estado salvaje bajo ciertas configuraciones.
La falla de seguridad en cuestión es CVE-2020-12812 (Puntuación CVSS: 5.2), una vulnerabilidad de autenticación errónea en SSL VPN en FortiOS que podría permitir a un usuario iniciar sesión correctamente sin que se le solicite el segundo factor de autenticación si se cambia el caso del nombre de usuario.
“Esto ocurre cuando la autenticación de dos factores está habilitada en la configuración de Usuario local y ese tipo de autenticación de usuario está configurado en un método de autenticación remota (por ejemplo, LDAP)”, señaló Fortinet en julio de 2020. “El problema existe debido a una distinción entre mayúsculas y minúsculas inconsistente en la autenticación local y remota”.
Desde entonces, la vulnerabilidad ha sido explotada activamente por múltiples actores de amenazas, y el gobierno de EE. UU. también la incluye como una de las muchas vulnerabilidades utilizadas como arma en ataques a dispositivos de tipo perimetral en 2021.

En un nuevo aviso con fecha del 24 de diciembre de 2025, Fortinet señaló que se requiere la siguiente configuración para activar con éxito CVE-2020-12812:
- Entradas de usuarios locales en FortiGate con 2FA, apuntando a LDAP
- Los mismos usuarios deben ser miembros de un grupo en el servidor LDAP.
- Al menos un grupo LDAP al que pertenecen los usuarios de dos factores debe configurarse en FortiGate y el grupo debe usarse en una política de autenticación, que puede incluir, por ejemplo, usuarios administrativos, SSL o VPN IPSEC.
Si se cumplen estos requisitos, la vulnerabilidad hace que los usuarios de LDAP con 2FA configurado omitan la capa de seguridad y en su lugar se autentiquen directamente en LDAP. Nuevamente, esto se debe a que FortiGate distingue entre mayúsculas y minúsculas para los nombres de usuario, mientras que el directorio LDAP no.
“Si el usuario inicia sesión con 'Jsmith', 'jSmith', 'JSmith', 'jsmiTh' o cualquier cosa que NO coincida con el caso exacto de 'jsmith', FortiGate no comparará el inicio de sesión con el usuario local”, explicó Fortinet. “Esta configuración hace que FortiGate considere otras opciones de autenticación. FortiGate verifica otras políticas de autenticación de firewall configuradas”.
“Después de que falla la coincidencia con jsmith, FortiGate encuentra el grupo secundario configurado 'Auth-Group' y desde allí el servidor LDAP. Siempre que las credenciales sean correctas, la autenticación es exitosa, independientemente de la configuración dentro de la política de usuario local (2FA y cuentas deshabilitadas)”.
Esto permite que la vulnerabilidad autentique usuarios administradores o VPN sin 2FA. Fortinet lanzó FortiOS 6.0.10, 6.2.4 y 6.4.1 en julio de 2020 para solucionar este comportamiento. Las organizaciones que no hayan implementado estas versiones pueden ejecutar el siguiente comando en todas las cuentas locales para evitar el problema de omisión de autenticación:
Deshabilitar la distinción entre mayúsculas y minúsculas para los nombres de usuario
Se recomienda a los clientes que utilicen las versiones 6.0.13, 6.2.10, 6.4.7, 7.0.1 o posteriores de FortiOS ejecutar el siguiente comando:
Configurar para deshabilitar la sensibilidad del nombre de usuario

“Cuando la sensibilidad del nombre de usuario está deshabilitada, FortiGate trata a jsmith, JSmith, JSMITH y todas las combinaciones posibles como idénticas y, por lo tanto, evita la conmutación por error a otras configuraciones de grupo LDAP mal configuradas”, dijo la compañía.
Como mitigación adicional, es útil considerar eliminar el grupo LDAP secundario si no es necesario, ya que esto elimina toda la línea de ataque ya que la autenticación a través del grupo LDAP no es posible y el usuario no podrá autenticarse si el nombre de usuario no coincide con una entrada local.
Sin embargo, la guía recientemente publicada no especifica el tipo de ataques que explotaron la vulnerabilidad ni si alguno de esos incidentes tuvo éxito. Fortinet también recomendó a los clientes afectados que se comuniquen con el equipo de soporte y restablezcan sus credenciales si encuentran evidencia de que el administrador o los usuarios de VPN fueron autenticados sin 2FA.