Fortinet — FortiCloud SSO auth bypass exploited in the wild (CVE-2026-24858)

• Category: AI CVEs

  • What happened: Fortinet published an advisory for CVE-2026-24858, describing an authentication bypass that can allow a FortiCloud account + a registered device to log into other devices registered to other accounts when FortiCloud SSO is enabled.
  • Exploited in the wild: Fortinet says the issue was actively abused by two malicious FortiCloud accounts (which were subsequently locked out).
  • Affected surface: the vendor notes impact across multiple products (FortiOS/FortiGate and additional Fortinet platforms called out in the advisory updates).
  • Precondition matters: exploitation depends on FortiCloud SSO login being enabled on the device.
  • Vendor-side mitigation happened: Fortinet says it temporarily disabled FortiCloud SSO on the service side and later re-enabled it with restrictions for vulnerable versions (but upgrades are still required for functionality).
  • Patch status: fixed versions are available (see FortiOS release notes for your branch), with more platform releases referenced in the advisory.
  • Operational risk: even if your firewall is “patched,” SSO-to-edge coupling is an attacker’s dream if the identity boundary fails.

Why it matters

  • Identity compromise becomes device compromise: if SSO can be abused across tenants/accounts, a single malicious account can become a multi-org access path.
  • Edge admin access is high impact: authentication bypasses on perimeter devices commonly lead to full network compromise (admin creation, config changes, traffic inspection/redirection).
  • “Disable the feature” isn’t always enough: Fortinet’s guidance implies clients may still need upgrades for SSO to function safely; treat this as a patch-and-verify event, not a toggle.

What to do

  1. Upgrade promptly: move to a fixed FortiOS release for your branch (and the corresponding fixed releases for any other Fortinet products you operate).
  2. Inventory exposure: identify devices with FortiCloud SSO enabled and those reachable from the internet on admin interfaces.
  3. Hunt for signs of access: review logs for suspicious admin logins, new admin accounts, and configuration changes around the dates in the advisory timeline.
  4. Reduce admin attack surface: restrict management access (VPN/allowlisted IPs/local-in policy) and remove direct internet exposure where possible.
  5. Rotate credentials if unsure: if you suspect compromise, rotate admin credentials/API keys and restore device configs from a known-good baseline.

Sources