Cloudy with a Chance of Shells: Analyzing CVE-2026-24858

We all love Single Sign-On (SSO). It’s the lubricant of the modern web. Instead of remembering forty different passwords for your forty different firewalls, you just click 'Login with FortiCloud', nod at the prompt, and you're in. It’s slick, it’s integrated, and in this case, it was a death trap.

Under the hood, this relies on a trust relationship between the Service Provider (SP)—your FortiGate firewall—and the Identity Provider (IdP)—FortiCloud. When a user tries to log in, the firewall redirects them to the cloud. The cloud verifies the user's password and MFA, then hands them a cryptographically signed token to take back to the firewall. The firewall validates the signature and lets the user in.

But here is the billion-dollar question: Does the firewall check who the token belongs to, or just that the token is valid? If I walk into a bank with a valid check signed by the bank president, but it's written to 'John Smith', and my name is 'Evil Hacker', the teller should probably stop me. CVE-2026-24858 is what happens when the teller stops reading after seeing the signature.

The root cause of CVE-2026-24858 is a classic logic flaw technically classified as CWE-288 (Authentication Bypass Using an Alternate Path). Specifically, it is a multi-tenancy isolation failure. Fortinet devices allow you to register them to a specific FortiCloud account (Asset Management). When SSO is enabled, the device expects an incoming authentication assertion from FortiCloud.

The vulnerability lies in the verification logic on the endpoint (the device itself). When the attacker presents a valid SSO token obtained from their own FortiCloud account, the victim device correctly verifies that the token was signed by Fortinet's legitimate key authority. However, the code failed to cross-reference the account_id or tenant_id inside that token against the device's registered owner.

Imagine you have a key to your house (House A) and your neighbor has a key to their house (House B). Both keys were made by the same locksmith. This vulnerability is the lock on House B accepting your key simply because it recognizes the locksmith's craftsmanship, completely ignoring the fact that the key cuts don't match the cylinder. The device assumed that if FortiCloud signed it, it must be intended for this device. That assumption was fatal.

While the FortiOS source code is proprietary, reverse engineering the binary logic reveals the flow. The vulnerable handler logic likely resembled the pseudocode below. Note the absence of the critical ownership check in the 'Before' state.

Vulnerable Logic (Reconstructed):

// pseudo-code of the vulnerable SSO handler
void handle_sso_callback(sso_token_t *token) {
    // 1. Verify the token signature (Passes, because it's a real token)
    if (!verify_signature(token, FORTICLOUD_PUBLIC_KEY)) {
        return HTTP_403;
    }
 
    // 2. Extract user info
    char *username = token->user_email;
    
    // CRITICAL FLAW: The code assumes the token is for THIS device
    // just because the signature is valid.
    
    // 3. Grant Admin Access
    session_create(username, ROLE_SUPER_ADMIN);
    return HTTP_200;
}

Fixed Logic: By analyzing the behavior of the patched versions (7.4.11+, 7.6.6+), we can see the introduction of a cross-check against the local configuration.

// pseudo-code of the patched SSO handler
void handle_sso_callback(sso_token_t *token) {
    if (!verify_signature(token, FORTICLOUD_PUBLIC_KEY)) {
        return HTTP_403;
    }
 
    // THE FIX: Compare token tenant against local registration
    char *local_owner_id = get_system_config()->forticloud_account_id;
    
    if (strcmp(token->tenant_id, local_owner_id) != 0) {
        log_security_event("SSO Tenant Mismatch Attempt");
        return HTTP_403; // GTFO
    }
 
    session_create(token->user_email, ROLE_SUPER_ADMIN);
    return HTTP_200;
}

The patch adds the missing authorization step. It forces the device to ask: "Is this token actually meant for me?"

Exploiting this requires zero coding skills and a budget of $0. The barrier to entry is terrifyingly low. Here is how a threat actor (or a researcher verifying the flaw) executes the attack chain:

1. Preparation: The attacker creates a legitimate, free FortiCloud account. They register a virtual FortiGate (VM) to this account to legitimize their session.
2. Token Generation: The attacker logs into their own device via FortiCloud SSO. They intercept the HTTP request using a proxy like Burp Suite or Caido. They capture the POST request containing the SAML assertion or OIDC token sent from the cloud to their device.
3. Target Acquisition: A quick Shodan query for port:443 "FortiGate" or "FortiManager" reveals millions of exposed targets. The attacker filters for devices that redirect to the FortiCloud login page (indicating SSO is enabled).
4. Replay & Bypass: The attacker sends the captured token (from Step 2) to the victim's device SSO callback URL (e.g., /ocs/login/).
5. pwned: The victim device receives the token, sees it is validly signed by Fortinet, and logs the attacker in as a Super Admin.

Because the vulnerability is in the logic, WAFs looking for SQL injection or XSS payloads will sleep right through this. The payload is a perfectly valid, RFC-compliant authentication token. It just happens to be the wrong key for the lock.

This is a CVSS 9.8 for a reason. Gaining administrative access to a FortiGate firewall is effectively "Game Over" for the network perimeter. The firewall is the choke point for all traffic.

Once authenticated, an attacker can:

• Establish Persistence: Create local admin users to maintain access even after the SSO bug is patched.
• VPN Hijacking: Modify SSL-VPN settings to intercept credentials or allow unauthenticated access to the internal network.
• Traffic Mirroring: Set up packet capture to sniff sensitive internal data passing through the gateway.
• Ransomware Deployment: Since this vulnerability also affects FortiManager (the centralized management console), an attacker could push a malicious configuration or script to thousands of managed firewalls simultaneously, bricking an entire enterprise in seconds.

CISA added this to the KEV (Known Exploited Vulnerabilities) catalog on day zero. Ransomware groups love edge devices because they don't run EDR software. You can't install CrowdStrike on a FortiGate firmware, making this the perfect shadow beachhead.

If you are running FortiOS 7.0 through 7.6, you are likely vulnerable. The immediate remediation is to upgrade to the fixed versions (e.g., FortiOS 7.4.11 or 7.6.6). But let's be real: upgrading a firewall cluster on a Friday afternoon is a resume-generating event.

The Workaround: If you cannot patch immediately, you must disable FortiCloud SSO. This kills the attack vector dead because the device will stop processing the cloud tokens entirely.

Run this on your FortiGate CLI:

config system central-management
    set forticloud-sso disable
end

For FortiManager and FortiAnalyzer, navigate to the GUI settings and uncheck "Allow FortiCloud SSO". Do this now. Do not wait for the change control meeting next week. The internet is already being scanned.