FortiCloud SSO Vulnerability and Best Practices
This is a point-in-time post to discuss a recent authentication-bypass vulnerability and remediations, but it’s also a larger discussion on security best practices around administrative access to systems. Read on!
FortiCloud SSO Authentication Bypass CVEs
Fortinet disclosed multiple vulnerabilities in December and January where FortiGates with FortiCloud SSO enabled (the ability to login to FortiGates with FortiCloud credentials) were vulnerable to an authentication bypass attack. This allowed hackers to send specially crafted SAML messages to bypass the authentication prompt and obtain administrative access to multiple Fortinet solutions including FortiGate firewalls.
Since there are multiple CVEs tracking the same vulnerability, I wanted to highlight them here to mitigate confusion:
CVE-2025-59718 & CVE-2025-59719 - improper access control; internally discovered and publicly disclosed in December 2025. Combined under FortiGuard Labs release FG-IR-25-647.
CVE-2026-24858 - improper access control; a public advisory of the same vulnerabilities above disclosed in January 2026. The same as FortiGuard Labs release FG-IR-26-060 which also includes the observed IOCs.
When registering a FortiGate to FortiCare for support and entitlements using the FortiGate’s interface, you’re prompted to allow FortiCloud users to login to the FortiGate. I’ve never personally used this, nor have my customers. Most use their own SAML IdP or other identity source (LDAP, RADIUS, etc.). However, many have enabled this feature as Fortinet identified malicious activity and as of January 27, have disabled FortiCloud SSO from vulnerable versions of FortiOS as a security control.
Fortinet’s CISO posted a blog post (https://www.fortinet.com/blog/psirt-blogs/analysis-of-sso-abuse-on-fortios) highlighting the timeline of these vulnerabilities as well as exploits they’re seeing, so I won’t reiterate all of that information here but definitely recommend reading it.
Audit and Remediation
To audit if your FortiGates have FortiCloud SSO enabled, run the following command:
FortiGate # show full system global | grep admin-forticloud-sso-login
set admin-forticloud-sso-login disable
Disable means you’re not using FortiCloud SSO. I needed to perform a “show full” since “show” displays non-default configuration; since default = disable I needed to run “show full” to confirm. That command can be quickly used in a Script in FortiManager to disable it across your entire environment. I would recommend upgrading to a patched FortiOS release (see FG-IR-26-060 for recommendations) if you need FortiCloud SSO.
But more importantly, don’t enable administrative access to any of your systems on public interfaces. This is how you expand your attack surface and make yourself vulnerable as you can’t patch quickly enough (not to mention undiscovered zero days). To perform an audit of administrative access on your FortiGates, run the following command(s):
FortiGate # show system interface | grep -B3 allowaccess
edit "wan1"
set vdom "root"
set mode dhcp
set allowaccess ping
--
edit "wan2"
set vdom "root"
set mode dhcp
set allowaccess ping
--
edit "Management"
set vdom "root"
set ip 10.22.36.1 255.255.255.0
set allowaccess ping https ssh snmp http radius-acct probe-response fabric ftm speed-test
--
In the above output, I only allow ping on my Internet-facing interfaces and limit administrative access to a LAN-accessible interface.
If you’re in the position where you need to enable administrative access on Internet-facing interfaces, you can use a Local-In firewall policy to limit the source addresses able to access HTTP, HTTPS, SSH, etc. This is a firewall rule for traffic destined to the FortiGate itself for administration, routing, monitoring, etc. Here is an example to allow administrative access from a specific IP address range and deny all other access (a requirement since local-in doesn’t have an implicit deny):
config firewall local-in-policy
edit 1
set intf want1
set srcaddr "MGMT_IPs"
set dstaddr "all"
set action accept
set service HTTPS HTTP SSH
set schedule "always"
set status enable
next
edit 2
set intf "all"
set srcaddr "all"
set dstaddr "all"
set action deny
set service HTTPS HTTP SSH
set schedule "always"
set status enable
end
config log setting
set local-in-policy-log enable
end
Administrative Access Best Practices
I read the SANS NewsBites each week to stay sharp and see the latest TTPs used by attackers. Almost every week, exploits are discovered in solutions and that exploitability goes up exponentially when administrator interfaces are publicly-accessible. Using the guides above, ensure you’re removing administrative access on publicly-accessible interfaces. And if you can’t, don’t rely just on Administrator Trusted Hosts but instead use Local-In Policies to restrict access to allowed IP ranges. Most of my customers use LAN interfaces or Loopback ones to permit HTTPS, SSH, FortiManager, Fabric, etc. access.
Kudos to Fortinet for detecting the vulnerability internally and publicly disclosing it, as well as disabling authentications exploiting the bypass from vulnerable devices. But security is all our responsibilities and using the recommendations above you’ll reduce your attack surface so you can give yourselves time to remediate.
Thanks for Reading!