Fortinet SAML Signature Flaw CVE 2025 59718: Patch Now to Prevent Admin Bypass

CISA’s addition of a Fortinet authentication‑bypass bug to the Known Exploited Vulnerabilities (KEV) Catalog spotlights a high‑risk class of flaws: improper verification of cryptographic signatures in SAML responses. The vulnerability, tracked as CVE‑2025‑59718, affects multiple Fortinet products and — when FortiCloud Single Sign‑On (SSO) is enabled — can allow an unauthenticated attacker to bypass administrative login entirely. Federal agencies are required to remediate KEV entries by the catalog’s prescribed due dates under Binding Operational Directive 22‑01, and this listing raises urgent priorities for enterprises that run Fortinet appliances or that register management devices with FortiCare.

Background​

Fortinet disclosed critical fixes in early December addressing a cluster of SAML signature‑verification flaws across FortiOS, FortiProxy, FortiSwitchManager and FortiWeb. The root problem is a failure to correctly verify cryptographic signatures on SAML response messages used by FortiCloud SSO. Where the vulnerable SAML processing is present and FortiCloud SSO is enabled, a specially crafted SAML response can be accepted as valid and grant administrative access without credentials.
This type of defect maps to CWE‑347 — Improper Verification of Cryptographic Signature — and is not theoretical: security vendors and national CSIRTs quickly flagged the issue as critical and Fortinet published patched builds. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has now placed CVE‑2025‑59718 onto the KEV Catalog, meaning the vulnerability is considered to be exploited in the wild or otherwise poses a significant threat to the federal enterprise.

---

Why this matters: the mechanics and risk​

How the flaw works (high level)​

• SAML is an XML‑based standard for exchanging authentication and authorization data (assertions) between an identity provider (IdP) and a service provider (SP).
• IdP responses are typically signed to prove authenticity. The SP must validate that signature against the expected public key and validate other fields (issuer, audience, timestamps).
• CVE‑2025‑59718 stems from improper verification of that cryptographic signature and related SAML response handling in Fortinet’s FortiCloud SSO path.
• An attacker who can deliver a crafted SAML response to a vulnerable device — over the network, unauthenticated — may bypass the admin login flow and gain administrative access to the device’s management interface.

Realistic impact scenarios​

• Immediate administrative takeover. An exploited device gives the attacker configuration control: firewall rules, VPN credentials, logging endpoints, and policy pushes.
• Persistent backdoors and lateral movement. With admin privileges, an attacker can create local accounts, persist web shells, or change logging to cover tracks — enabling deeper network compromise.
• Supply‑chain and multi‑tenancy risk. Devices registered to a central management/registration service (FortiCare/FortiCloud) may inherit higher risk if fleet registration defaults enable SSO.
• Operational disruption. Firewalls and proxies are choke points. Compromise can interrupt services, expose logs and secrets, or enable data exfiltration.

---

Affected products and patched builds​

Multiple Fortinet products and a range of versions are affected; administrators must verify their specific builds and apply vendor patches. Key affected families include:

• FortiOS (multiple 7.x builds)
• FortiProxy (multiple 7.x builds)
• FortiSwitchManager (selected 7.x builds)
• FortiWeb (distinct but related CVE family affecting FortiWeb SAML handling)

Fortinet’s advisories and national CERTs list patched minimum versions for each product line; examples of the corrected versions (representative, verify exact build numbers in your environment) include:

• FortiOS: update to 7.6.4 or later; 7.4.9 or later; 7.2.12 or later; 7.0.18 or later
• FortiProxy: update to 7.6.4 or later; 7.4.11 or later; 7.2.15 or later; 7.0.22 or later
• FortiSwitchManager: update to 7.2.7 or later; 7.0.6 or later
• FortiWeb: separate advisory; update to the versions specified by Fortinet (e.g., 7.4.10+, 7.6.5+, 8.0.1+)

Administrators must cross‑check vendor advisories for exact patch build numbers and platform variations (hardware vs. VM images). Patches for these issues were released as part of a larger Fortinet security update cycle; treat them as high priority.

---

The KEV listing: federal obligations and operational urgency​

Binding Operational Directive 22‑01 established the KEV Catalog as a prioritized list of vulnerabilities that federal civilian agencies must remediate according to specific due dates. A KEV entry means CISA has evidence of active exploitation or a credible threat such that federal systems must be protected within the deadline specified in the catalog entry.

• Implication for federal agencies: remediate by the catalog due date or follow the agency’s COOP/mitigation procedures. Failure can represent non‑compliance with federal directives.
• Implication for private sector: while BOD 22‑01 does not legally bind private organizations, KEV listings are a strong operational signal to treat the vulnerability as exploitation likely or already active.

Note: remediation timers (the exact “due date” assigned to a KEV entry) can vary and are specified per‑CVE in the KEV Catalog. Organizations should consult the KEV Catalog entry for CVE‑2025‑59718 to confirm the formal deadline. If the catalog page does not explicitly state a due date at the moment of review, treat the vulnerability as requiring immediate action because of the ease and impact of exploitation.

---

Fortinet’s response and a subtle but critical detail​

Fortinet issued a security advisory and fixed multiple builds across product lines. Important operational notes from vendor guidance and independent analysis:

• FortiCloud SSO is not always obvious. The FortiCloud SSO login feature is not necessarily enabled by default on factory resets, but some management workflows — specifically device registration to FortiCare/FortiCloud via the device GUI — may enable the FortiCloud SSO toggle unless an administrator explicitly disables it during registration. In other words, devices that were registered to FortiCare by a human operator may have SSO enabled inadvertently.
• Severity scoring variance. Fortinet’s advisory assigned a CVSSv3 score (for internal prioritization), while multiple external trackers reported higher scores (e.g., 9.8). Differences stem from differing CVSS calculus and environment assumptions; treat the issue as critical regardless of the numeric score.
• Patches were released quickly, but not all organizations will be patched. Patch availability is necessary but not sufficient; organizations with remote or heavily tested change windows may lag and remain exposed.

---

Immediate action checklist for administrators​

1. Inventory affected devices
   • Enumerate FortiOS, FortiProxy, FortiSwitchManager, and FortiWeb devices.
   • Identify those registered with FortiCare/FortiCloud and check the FortiCloud SSO setting.
2. Patch urgently
   • Apply vendor‑provided patches that address CVE‑2025‑59718 (and CVE‑2025‑59719 for FortiWeb).
   • Use pre‑production testing where necessary but prioritize high‑risk internet‑facing and management interfaces.
3. If you cannot patch immediately, implement temporary mitigations
   • Disable Allow administrative login using FortiCloud SSO at the device registration page or via configuration.
   • Restrict management interfaces (HTTP/HTTPS/SSH) to a narrow set of trusted IPs/VPNs.
   • Block or restrict network paths to FortiCloud/FortiCare endpoints where feasible.
4. Hunt for indicators of compromise
   • Review management logs for unexpected SAML/SOAP activity or successful administrative logins that lack corresponding valid user actions.
   • Search for new admin accounts, configuration changes, unusual outbound connections from management appliances, and altered logging destinations.
5. Incident response planning
   • If compromise is suspected, treat the device as potentially controlled by an adversary: isolate from management networks, take forensic images, and examine persistent artifacts.
   • Remember that patching does not restore trust if an appliance was previously compromised; forensic validation is essential.

---

Detection and hunting guidance (technical)​

• Log targets
  • Management authentication logs (admin login events, failed/successful SSO events)
  • SAML assertion logs (if your logging configuration captures raw SAML messages)
  • Configuration change logs (new policies, user creation, routing changes)
  • System process and file integrity alerts on appliances that support such telemetry
• Hunt queries
  • Look for administrative login events with source IPs outside known administrative networks or unexpected User‑Agent strings.
  • Search for SAML response messages with unusual issuers, odd timestamps, or signature failures that were accepted.
  • Check for configuration changes outside maintenance windows and for newly created accounts with administrative privileges.
• Endpoint/network indicators
  • Unexpected outbound calls to unknown third‑party domains from management appliances.
  • Changes to logging endpoints that point to attacker‑controlled collectors.

---

Why SAML signature verification bugs are particularly dangerous​

SAML is designed to delegate authentication to a trusted identity provider. When an SP (service provider) incorrectly validates signatures, the entire authentication model fails: attacker‑supplied assertions can be accepted as genuine, bypassing multi‑factor controls, password policies, and even conditional access logic.

• Trust failure — SAML’s security depends on strict cryptographic checks; any weakness effectively transforms the IdP model into an open door.
• Automation multiplier — Because many appliances and cloud services rely on SAML for federated logins, a single successful attack can unlock large numbers of systems if the SP side is flawed.
• Stealth — An attacker who can craft SAML assertions can appear as legitimate logins and is likely to evade naive detection rules that only flag failed authentications.

---

Broader analysis: what this says about device defaults and vendor processes​

This incident highlights persistent operational weaknesses in network appliance ecosystems:

• Feature enablement by registration — When security‑sensitive features are implicitly enabled during common administrative steps (such as device registration), risk rises due to human error and inconsistent hardening.
• Patch management friction — Network appliances often sit behind maintenance windows and change control, increasing the window of exposure even after fixes are published.
• Transparency and telemetry gaps — Device logs may not capture sufficient SAML artifacts or signature validation events to support rapid detection; operators must actively enable enhanced logging.
• Vendor scoring and messaging — Variances between vendor CVSS assignments and third‑party assessments create prioritization confusion for defenders; organizations should base response decisions on exploitability and business impact, not a single numerical score.

---

Practical advice for Windows‑centric and enterprise teams​

• Do not assume that perimeter or EDR controls will detect this class of compromise: administrative takeover at the appliance level often occurs outside endpoint processes.
• Prioritize Fortinet management appliances in vulnerability scanning and patching schedules, treating them with the same urgency as internet‑facing servers.
• If an appliance is administratively critical (VPN concentrator, central firewall, management switch), schedule an emergency maintenance window to apply patches and validate post‑patch integrity.
• Document the FortiCare/FortiCloud registration history of devices and reassure that any device registered without explicit disabling of FortiCloud SSO is treated as high priority.
• Ensure that change control procedures include checks for toggles like FortiCloud SSO that may be enabled during provisioning.

---

What defenders should expect next​

• Increased scanning and exploitation attempts. When high‑impact authentication bypasses are publicized, opportunistic actors and automated scanners rapidly probe for vulnerable devices.
• Proof‑of‑concepts and exploit code. Public PoCs can appear within days; admins should assume exploit code will become available and therefore treat unpatched devices as imminently exploitable.
• Targeted campaigns. Sophisticated actors will combine appliance access with lateral movement and data‑exfiltration toolkits; organizations must be ready to escalate to incident response.
• Regulatory and compliance reverberations. For federal systems, the KEV listing triggers formal remediation obligations; for regulated industries, vendor disclosures and public exploit evidence can influence breach reporting and contractual obligations.

---

Strengths of the response — and remaining risks​

Notable strengths​

• Rapid vendor patching. Fortinet released patches across the affected product families and provided specific guidance on the FortiCloud SSO toggle and recommended mitigations.
• Cross‑industry awareness. National CSIRTs and security vendors quickly analyzed the flaw and published detection guidance, helping defenders prioritize.
• CISA KEV listing. Formal cataloging raises visibility and forces prioritization for federal agencies, which is likely to accelerate remediation cycles.

Remaining risks and caveats​

• Potential for historic compromise. Patch application alone does not demonstrate that a device was never previously abused; incident responders must assume that patched devices could still be compromised and investigate accordingly.
• Incomplete telemetry. Many appliance deployments lack centralized logging or sufficiently verbose SAML logs, limiting post‑incident analysis.
• Human error in registration/configuration. Devices left registered to cloud management services without explicit administrator review represent silent risk.
• Patching delays. Organizations with strict change control windows, limited maintenance windows, or complex appliance clusters will struggle to patch immediately — increasing exposure time.

Where precise facts are time‑sensitive — for example, the official KEV remediation “due date” assigned by CISA for this specific CVE — organizations should consult the KEV Catalog entry and their agency security offices. If the catalog does not list a public due date at the time of review, treat the issue as requiring immediate mitigation given active exploitation potential.

---

Action plan (30/60/90 day roadmap)​

1. First 24–72 hours
   1. Inventory and triage: identify vulnerable devices and whether FortiCloud SSO is enabled.
   2. Apply emergency patches to internet‑facing and management devices.
   3. If patching is delayed, disable FortiCloud SSO and restrict management access.
   4. Initiate hunting for anomalous SAML events and admin account creation.
2. 30 days
   1. Complete patch rollout across all affected Fortinet devices.
   2. Verify device integrity: review configuration change logs, user lists, and firmware versions.
   3. Centralize logging for appliance management events; ensure retention for forensic needs.
3. 60–90 days
   1. Conduct post‑remediation audits and tabletop incident exercises to validate detection and response plans.
   2. Harden provisioning processes: ensure default registration flows don’t enable risky features without explicit review.
   3. Review vendor SLAs and emergency patch programs as part of procurement and risk analysis.

---

Final assessment​

CVE‑2025‑59718 is a significant and actionable vulnerability because it undermines an authentication trust boundary — SAML signature validation. Its inclusion in the KEV Catalog is a forceful signal: organizations should not treat this as a routine maintenance item. The combination of high impact (administrator takeover), ease of exploitation (network‑delivered crafted SAML responses, no authentication required), and real‑world exploit evidence makes this an incident‑grade event.
Defensive priorities are clear: inventory quickly, patch urgently, disable FortiCloud SSO where necessary, and hunt for signs of compromise. Beyond the immediate fix, this episode should catalyze a re‑examination of appliance provisioning practices: default toggles that implicitly enable powerful features are a recurring source of risk. Network and security teams must demand explicit, auditable controls around cloud registration and SSO features and ensure robust logging to enable rapid detection should the trust model fail again.
In short: treat Fortinet management appliances as mission‑critical pieces of infrastructure. Rapid remediation and careful forensic follow‑through will reduce the chance that an exploit of this nature becomes the first step in a broader compromise.

---

Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA