The decision was as swift as it was uncommon: Fortinet temporarily disabled FortiCloud Single Sign-On (SSO) after confirming active exploitation of a zero-day flaw impacting several of its most deployed products. The vulnerability, identified by the vendor as FG-IR-26-060 and registered as CVE-2026-24858, permits an attacker with a FortiCloud account and a registered device to log into devices linked to other accounts, as long as FortiCloud SSO is enabled on those devices.
This incident highlights a deeper issue that security teams are increasingly concerned about: the convenience of cloud management and SSO can become a critical attack surface when authentication effectively turns into a “VIP pass” for managing infrastructure. The flaw is classified as authentication bypass via alternate route or channel (CWE-288), a known vulnerability type, but especially sensitive when combined with administrative access.
What makes this 0-day different: it’s not an isolated bug, but a pattern
According to Fortinet’s published analysis, the incident bears similarities to the December 2025 wave linked to SSO bypasses (CVE-2025-59718 and CVE-2025-59719), but with a key difference: in January, cases were detected where unauthorized access occurred against devices already updated to the latest available version at the time of attack, pointing to a new exploitation pathway.
The company also clarified a point that initially raised concern: although there was initial fear of broader impact on SAML implementations, it was ultimately confirmed that the incident affects FortiCloud SSO and not third-party SAML Identity Providers (IdPs) or FortiAuthenticator. This distinction is important for assessing risk in federated identity environments, where not all SSO setups are equal.
Timeline: malicious accounts, SSO shutdown, and reactivation with “version blocking”
The response accelerated within days:
- January 22–23, 2026: Fortinet disabled the FortiCloud accounts used in the attacks, according to their public “timeline”.
- January 26, 2026: the vendor shut down FortiCloud SSO to curb abuse.
- January 27, 2026: the service was restored, but with a change equivalent to an operational firewall: FortiCloud SSO stopped accepting logins from devices running vulnerable versions, prompting organizations to update if they wanted to maintain that authentication flow.
Meanwhile, CISA issued an alert about ongoing exploitation, and according to NVD records, on January 27, 2026, the CVE was added to the KEV catalog with a remediation deadline of January 30, 2026 for federal agencies, a clear sign of urgency.
Affected products and versions: patch by branch, not a single “button”
Technical advisories describe a broad scope, especially when FortiCloud SSO is enabled. In practice, the “trouble” for operations stems from the fact that upgrading depends on the installed branch.
According to INCIBE’s alert, recommended upgrade paths include, among others:
- FortiOS: update to 7.6.6 or higher; 7.4.11 or higher; 7.2.13 or higher; 7.0.19 or higher.
- FortiManager: 7.6.6+, 7.4.10+, 7.2.13+, 7.0.16+.
- FortiAnalyzer: 7.6.6+, 7.4.10+, 7.2.12+, 7.0.16+.
- FortiProxy: 7.6.6+, 7.4.13+; for branches 7.2/7.0, migration to a fixed version is recommended.
Furthermore, NVD (NIST) records also indicate the impact on FortiWeb across multiple branches (8.0.0–8.0.3, 7.6.0–7.6.6, 7.4.0–7.4.11), reinforcing the idea of a cross-cutting issue within the ecosystem when cloud authentication is involved.
Indicators of compromise: the attack leaves traces, but may appear “legitimate”
One of the more troubling aspects of this incident is that the initial trace can be mistaken for valid access: an SSO login followed by administrative actions.
Fortinet provided specific indicators: two accounts observed during login attempts, multiple IP addresses (including some protected by Cloudflare), and a repeated pattern of creating local admin accounts for persistence. They also shared log examples showing event identifiers for “admin login successful” and “object attribute configured,” typical when a new administrator is added.
Operational risk is not limited to device control: some reports describe actors downloading configurations after access, a serious scenario since the “map” of rules, VPNs, segmentation, routes, and authentication mechanisms could be exposed. Media outlets have reported automated campaigns and a high number of endpoints potentially affected.
What IT and security teams should prioritize
In a tech environment, the key message is simple: this isn’t about “patching when a hole appears”. It’s about reducing attack surface and stopping the vector as soon as possible because we’re dealing with administrative authentication.
Follow public recommendations, including:
- Check if FortiCloud SSO is enabled on perimeter and management devices. If not essential, temporarily disable it while planning the update.
- Update by branch to patched versions (or migrate if the branch lacks a direct fix), prioritizing exposed assets or those accessible over the internet.
- Review administrative accounts (both local and remote) for unexpected high privileges, profile changes, and SSO logins at unusual times.
- Restrict management access (e.g., with “local-in” policies, trusted IP lists, and reducing exposed services), an “old-fashioned” but still crucial practice when centralized identity management fails.
- If compromise is detected: rotate credentials, audit integrations (VPN/LDAP), and validate configuration integrity before trusting the device.
The lesson for 2026: cloud identity is critical infrastructure
This case extends beyond Fortinet: when a vendor makes cloud SSO a “frictionless” experience, the sector accelerates… but also concentrates risk. And when a bypass occurs, the incident becomes systemic: it’s not just affecting a machine, but a mode of operation.
The response—shutting down provider-level SSO and re-enabling it with version blocks—illustrates how the line between security, continuity, and control is shifting. For many organizations, the immediate challenge is technical (patching and auditing). The strategic challenge is different: designing operations that can continue functioning even when the “brain” of cloud authentication is temporarily compromised.
Frequently Asked Questions
How can I verify if FortiCloud SSO is enabled, and why is it critical in CVE-2026-24858?
Because the exploited vulnerability activates when administrative login via FortiCloud SSO is enabled. Advisories recommend explicitly reviewing this setting, as it might remain enabled during registration if the related option isn’t unchecked.
What FortiOS versions should be considered “minimum” to mitigate FG-IR-26-060?
It depends on the branch: public guidance points to releases like 7.6.6, 7.4.11, 7.2.13, or 7.0.19 (or higher), along with equivalent versions for FortiManager and FortiAnalyzer.
What log signals might indicate SSO abuse and creation of admin accounts for persistence?
Fortinet has published indicators and log examples related to SSO login attempts and local admin additions. The practical recommendation is to correlate “SSO login” + “admin account creation” + “configuration export/download”.
Why did CISA raise the urgency, and what do the KEV catalog dates imply?
NVD records show that the CVE was added to KEV on January 27, 2026, with a remediation deadline of January 30, 2026, for federal entities. This indicates actual exploitation and a high mitigation priority.
Source: Fortinet disables FortiCloud SSO