CVE-2026-24858: FortiCloud SSO authentication bypass explained

CVE-2026-24858 is a critical authentication bypass in FortiCloud Single Sign-On. Fortinet assigned CVSS 3.1 9.4, confirmed exploitation and documented intruders downloading device configuration and creating local administrator accounts. The incident illustrates how trust in an external identity channel can become an entry path into an edge appliance.

Affected releases listed by the vendor span FortiOS, FortiManager, FortiAnalyzer, FortiProxy, FortiSwitchManager and FortiWeb. That does not mean every installation was automatically exploitable. Administrative login through FortiCloud SSO had to be enabled. The feature is not on by factory default, but could be enabled during FortiCare registration unless the operator disabled the relevant option.

Attack model and factual boundaries

Fortinet classifies the flaw as authentication through an alternate channel. An attacker needed their own FortiCloud account and registered device, but defective validation allowed that identity to be accepted by a different vulnerable target with SSO enabled. This is not administrator password theft or credential stuffing. The failure is an incorrect binding between a cloud identity and the target appliance.

Fortinet identified and blocked two malicious FortiCloud accounts on 22 January 2026. It disabled the SSO service from the cloud side on 26 January and restored it on 27 January with vulnerable versions blocked from logging in. That response constrained the active route, but did not replace appliance patching or investigation. A configuration downloaded before the block may expose network topology, accounts, password material, keys, VPN objects and other data useful for a second attack stage.

The advisory says custom deployments using their own identity provider were not affected by this specific issue. It also excludes FortiManager Cloud, FortiAnalyzer Cloud and FortiGate Cloud. An assessment must therefore document the actual login flow rather than draw conclusions from the Fortinet product name alone.

Determine whether SSO was enabled

Inventory every instance, including HA standby members, labs and decommissioning nodes still reachable through DNS or NAT. Record the product, exact build, management mode, administrative exposure and FortiCloud SSO state. Compare each build with the fixed-release tables in FG-IR-26-060.

Do not close the review because the team believes the panel was limited to management addresses. Reconstruct effective paths through reverse proxies, VIPs, local-in policy, management VDOMs, tunnels and provider networks. Security incidents frequently exploit the gap between intended architecture and effective reachability.

Review FortiCare onboarding history as well. SSO may have been enabled during registration and later forgotten. A current GUI screenshot is not durable evidence. Preserve timestamped configuration and logs with their source so another reviewer can reproduce the conclusion.

Persistence accounts and evidence

Fortinet advised customers to look for unexpected administrator names including audit, backup, itadmin, secadmin, support, backupadmin, deploy, remoteadmin, security, svcadmin, system and adccount. This is not a complete signature. An operator can choose another name, modify an existing account or retain access through a key, token, automation object or external manager.

The investigation should establish:

• whether FortiCloud administrator logins came from unexpected sources;
• whether a local administrator was created, altered or re-enabled;
• whether a full configuration or unusual backup was downloaded;
• whether firewall policy, VPN objects, certificates, scripts or automation stitches changed;
• whether the appliance initiated new outbound connections;
• whether logging was cleared, shortened or reconfigured.

Local logs may be altered after compromise. Correlate them with FortiAnalyzer, SIEM, remote syslog, NetFlow and upstream telemetry. The absence of a local event is not proof that no intrusion occurred.

Response sequence

1. Preserve configuration, logs and device state before making changes.
2. Restrict administration to a dedicated network or bastion and disable FortiCloud SSO when unnecessary.
3. Install a fixed build from the PSIRT table and verify every HA member is actually running it.
4. Remove unknown accounts only after evidence collection. Review legitimate accounts, roles, trusted hosts, keys and tokens too.
5. If configuration could have been downloaded, treat embedded secrets as exposed and rotate them in a controlled order.
6. Compare configuration with a known-good baseline; rebuild using the vendor-supported method where compromise is confirmed.
7. Monitor reuse of old credentials and return attempts associated with the incident.

Do not restore an old backup blindly. It can reintroduce a vulnerable configuration, unauthorised account or already exposed secrets. Migrate only reviewed configuration into the fixed release.

Why the cloud-side kill switch did not close the incident

The central block was a fast and valuable vendor response, but it cannot reverse actions completed before 26 January. Once an attacker has created an administrator, downloaded configuration or obtained VPN material, they may return through another channel. Separate three questions in the report: does the original vector still work, was the appliance reachable and did any post-authentication action occur?

The flaw is also a reminder that administrative identity belongs in the edge attack surface. Federation and SSO reduce password sprawl, but add a trust relationship that needs monitoring. Include it in your vulnerability-management process, Zero Trust review and incident-response exercises. For independent exposure and configuration validation, contact BreachRoad.

---

Primary sources: Fortinet PSIRT FG-IR-26-060, CISA KEV.