On December 9, 2025, Fortinet PSIRT published FG-IR-25-647 describing CVE-2025-59718 and the related CVE-2025-59719, paired authentication bypass vulnerabilities in the FortiCloud Single Sign-On flow used by FortiOS, FortiWeb, FortiProxy, and FortiSwitchManager. Both score 9.1 CVSS v3.1. CISA added CVE-2025-59718 to the Known Exploited Vulnerabilities catalog one week later on December 16, with a federal remediation deadline of January 6, 2026. Active exploitation began in the days following the advisory, and Arctic Wolf observed attacker tradecraft that immediately downloaded the system configuration file after admin login — a behavior that mirrors the 2024 FortiGate CVE-2024-55591 campaign. If your fleet has FortiCloud SSO enabled and the SAML assertion path is reachable, you must assume credential exposure and respond accordingly.
What is the bug?
The FortiCloud SSO feature lets a single FortiCloud identity log in to multiple Fortinet appliances by federating SAML assertions through Fortinet's identity provider. The bug is in how the appliance validates the inbound SAML response: a crafted SAML message bypasses the signature and audience checks, allowing an unauthenticated attacker to forge an assertion that the appliance treats as a valid login for the admin user.
Specifically, the SAML validator in the affected FortiOS builds performs the signature check on a parsed XML document and then re-extracts the username from the raw, unsigned XML — a textbook XML Signature Wrapping (XSW) attack. The attacker wraps a fake <saml:Assertion> containing admin around the real signed assertion. The signature still verifies on the legitimate inner element, but the application logic reads the outer <saml:Subject><saml:NameID> element, which says admin. The result is a successful login as the device administrator without ever knowing a password.
The bug class is CWE-347 (improper verification of cryptographic signature) layered on CWE-91 (XML injection). The same class of bug shipped in the Microsoft Identity Federation Service and in OneLogin in past years, but rarely in such a directly exploitable form on internet-facing edge gear.
How is it exploited?
Public proof-of-concept code became available within seventy-two hours of the Fortinet advisory. The attack flow is:
- Identify a FortiGate or FortiWeb with FortiCloud SSO enabled. The login page renders a "Login with FortiCloud" button.
- Send a crafted SAML response to the assertion consumer endpoint (typically
/saml/login/consumeon the appliance). - The appliance accepts the assertion and issues a session cookie scoped to the admin user.
A representative request body (XML simplified for clarity):
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<!-- Attacker-injected outer assertion -->
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
<saml:Subject>
<saml:NameID>admin</saml:NameID>
</saml:Subject>
<!-- Legitimate signed assertion preserved here -->
<saml:Assertion>
<ds:Signature>...valid signature over inner assertion...</ds:Signature>
<saml:Subject>
<saml:NameID>guest@example.com</saml:NameID>
</saml:Subject>
</saml:Assertion>
</saml:Assertion>
</samlp:Response>
In observed attacks, once the session is established the operator immediately calls the configuration export API to retrieve sys_config.conf, which contains hashed local credentials, the LDAP bind password, IPsec pre-shared keys, and the device's HA membership secrets. The attacker uses this to plant a persistent admin account, push a firewall rule allowing inbound SSH from their infrastructure, and remove their session log entries before disconnecting.
Who is affected?
The advisory enumerates broad coverage:
- FortiOS 7.6.0 through 7.6.2, 7.4.0 through 7.4.6, 7.2 (all branches)
- FortiProxy 7.6.0 through 7.6.2, 7.4 (all branches), 7.2 (all branches)
- FortiWeb 7.6.0 through 7.6.4, 7.4 (all branches)
- FortiSwitchManager 7.2 (all branches)
Fixed in FortiOS 7.6.3, 7.4.7; FortiProxy 7.6.3; FortiWeb 7.6.5. Older 7.0 and 6.x trains do not implement FortiCloud SSO and are not affected.
The exposure requires FortiCloud SSO to be enabled. Many enterprises do enable it because it simplifies multi-device management, but a non-trivial fraction have it disabled and are not exposed. The check on FortiOS:
config system saml
show
end
If status enable appears, the feature is on. Note that even disabled SAML may leave the assertion consumer endpoint reachable in some FortiWeb builds — Fortinet's mitigation guidance is to apply the patch regardless.
What does patching require?
Patching is a firmware upgrade with a reload, which on FortiGate clusters can be done with HA failover to avoid traffic disruption. Fortinet specifically recommends post-patch credential hygiene: every administrator account, every API key, every IPsec PSK, and every LDAP bind password that was present in the config before December 9 must be assumed exposed and rotated. Any organization with indicators of compromise should treat their entire FortiCloud-linked fleet as compromised, not just the specific device they detected on.
Workaround until patching: disable FortiCloud SSO entirely.
config system saml
set status disable
end
This breaks federated login but does not affect local admin or RADIUS authentication.
How do you detect exploitation?
The most reliable indicator is an unexpected admin login from a SAML source without a preceding redirect from FortiCloud. The appliance logs SAML events to system event log; look for the sequence:
date=2025-12-10 time=14:22:11 logid="0100032125" type=event subtype=system level=notice
vd=root user="admin" ui="https(<ATTACKER_IP>)" action="login" status="success"
reason="saml" msg="Administrator admin logged in via SAML"
Cross-reference the source IP against your geofence and FortiCloud's published egress ranges. Any SAML login from an IP outside Fortinet's CDN ranges (208.91.112.0/22 and adjacent) is suspicious.
A sigma rule:
title: FortiGate SAML Admin Login from Untrusted IP
logsource:
product: fortinet
service: fortigate-event
detection:
selection:
logid: '0100032125'
action: 'login'
reason: 'saml'
user: 'admin'
filter:
src_ip|cidr:
- 208.91.112.0/22
- 173.243.128.0/20
condition: selection and not filter
level: critical
Also audit the configuration revision history (diagnose sys config-revision list) for unauthorized changes around December 9-16, 2025, when in-the-wild exploitation peaked.
How Safeguard Helps
Safeguard cross-references every Fortinet appliance in your asset inventory against PSIRT advisories and the live CISA KEV feed. When CVE-2025-59718 was added on December 16, 2025, every FortiGate, FortiWeb, and FortiProxy in our customers' tenants was flagged within minutes with the exact firmware build that needed upgrading. Reachability analysis isolates the appliances where FortiCloud SSO is enabled and the SAML endpoint is internet-reachable — typically the highest-risk subset — and Griffin AI correlates that with KEV exploitation telemetry to elevate priority. For tenant-wide post-compromise hygiene, Safeguard's secret-rotation runbook covers admin passwords, API tokens, LDAP bind credentials, and IPsec PSKs, mapping each rotated secret to the systems that consume it so on-call engineers do not miss a downstream service.