FortiGate SAML Bypass: Detect It Fast With AI SOC

A critical Fortinet FortiGate SAML SSO authentication bypass is being exploited in the wild right now—and the most worrying part isn’t the CVSS score. It’s the speed and “quietness” of the attack path: attackers can slip past authentication using crafted SAML messages, log in as admin, then export device configurations through the GUI.

If you’re running FortiGate (or you manage networks that do), treat this as a live-fire drill for your authentication monitoring. Patching is non-negotiable. But patching alone doesn’t solve the bigger issue this incident highlights: identity and SSO telemetry is still a blind spot in a lot of network security programs.

This post is part of our AI in Cybersecurity series, and I’m going to take a stance: if your SOC can’t spot anomalous SSO behavior in minutes, you’re operating with last decade’s assumptions. The FortiGate SAML bypass (CVE-2025-59718 and CVE-2025-59719) is a clean case study for why AI-driven threat detection—especially around authentication—has moved from “nice to have” to “baseline.”

What’s happening with the FortiGate SAML SSO bypass (and why it’s messy)

Answer first: Attackers are bypassing SAML SSO authentication on certain Fortinet products when FortiCloud SSO is enabled, allowing unauthenticated logins via crafted SAML messages.

Two critical flaws (CVE-2025-59718 and CVE-2025-59719, each scored 9.8) enable authentication bypass of SSO login under specific conditions. Fortinet released patches for multiple products, including FortiOS and related management/proxy components.

Here’s the operational “gotcha” that makes this incident feel personal to a lot of defenders: FortiCloud SSO may be disabled by default, but it can be automatically enabled during FortiCare registration unless an admin explicitly turns it off. That’s the kind of checkbox-risk that doesn’t show up in a quarterly risk register… until it does.

The observed attack chain (simple, fast, damaging)

Answer first: The campaign observed so far uses malicious SSO logins against admin, then exports device configurations.

Based on activity observed by a major security provider, the early-stage intrusions followed a pattern that’s painfully pragmatic:

1. Target FortiGate management access over the internet (or otherwise reachable management plane).
2. Attempt SAML SSO login bypass using crafted SAML messages.
3. Log in to the GUI as admin (malicious SSO logins).
4. Export device configuration to attacker-controlled infrastructure.

Why configuration export matters: firewall configs often contain hashed credentials, VPN settings, identity integration details, internal IP ranges, object groups, and policy logic—basically a blueprint for lateral movement.

The compliance clock is real

Answer first: U.S. federal agencies have a hard deadline, and that’s a signal that exploitation is confirmed.

CISA added CVE-2025-59718 to the Known Exploited Vulnerabilities (KEV) catalog and required fixes by December 23, 2025 for federal civilian agencies. When a vulnerability hits KEV, it’s no longer a “theoretical” issue. It’s a confirmation that defenders are already behind the first wave.

Why authentication bypasses keep beating perimeter defenses

Answer first: Perimeter tools are good at blocking malware; they’re not automatically good at recognizing “weird but valid-looking” identity events.

A lot of organizations still treat firewalls and VPN concentrators as “infrastructure,” not as identity-critical systems. That mental model breaks when:

• SAML (or any federated identity mechanism) becomes a login path to the device itself
• SSO is enabled implicitly during registration flows
• The attack doesn’t require brute force, phishing, or malware—just crafted authentication messages

Here’s what most companies get wrong: they log authentication outcomes, but they don’t model authentication intent.

An attacker exploiting SAML bypass often doesn’t trigger classic signals like:

• repeated password failures
• impossible travel on a user account
• endpoint malware telemetry

Instead, you get a small number of “successful” logins that look legitimate unless you’re correlating context.

Why this FortiGate case is a perfect SSO monitoring test

Answer first: The behavior is distinctive if you’re watching the right signals across identity, network, and device telemetry.

The observed pattern—malicious SSO login to admin followed by configuration export—creates a compact but high-confidence detection story:

• SSO login where SSO logins are rare or newly enabled
• Privileged account access (admin) from unfamiliar IP ranges / hosting providers
• GUI-based config export soon after login
• No prior change ticket, no maintenance window, no known admin workstation

That’s not subtle. It’s just not visible if your logs aren’t centralized or your SOC isn’t correlating identity + device actions.

How AI-driven threat detection spots SAML bypass attempts faster

Answer first: AI helps by learning “normal” authentication patterns and flagging high-risk deviations instantly—without waiting for known indicators of compromise.

Signature-based detections are still valuable, but they’re reactive. In fast-moving campaigns (especially around widely deployed edge devices), attackers count on a predictable delay:

• disclosure → exploit PoCs → scanning → initial intrusions → defenders patch

AI-driven detection aims to shrink the middle part by focusing on behavioral anomalies, not just known IoCs.

What to monitor: the minimum viable signals

Answer first: You need SSO telemetry, management-plane logs, and configuration-change/export events in the same place.

If you want a SOC that can catch this class of attack, pull these into your SIEM / security data lake and make them queryable:

• FortiGate admin login logs (success/failure, method, source IP, username)
• SSO/SAML events (assertion validation outcomes, SSO provider interactions, unusual SAML attributes if logged)
• GUI activity logs (especially config export and backup actions)
• Management interface access logs (who can reach the admin plane, from where)
• Network metadata (NetFlow or firewall session logs that show management access patterns)

Then use AI/ML to do what humans can’t do continuously: build baselines and score deviations.

AI detections that work well for this incident pattern

Answer first: Prioritize detections that combine “rare event” + “privileged action” + “new source.”

I’ve found that the highest signal-to-noise alerts in identity-heavy incidents are compound ones. Examples your SOC can implement (even without fancy tooling) and then mature with AI scoring:

1. New SSO admin login

   • Condition: admin authenticates via SSO for the first time (or first time in 30–90 days)
   • Add AI: anomaly score based on historical auth method distribution

2. SSO login from hosting/provider IP space

   • Condition: successful login from ASN / hosting ranges not seen before
   • Add AI: reputation + novelty scoring on source infrastructure

3. Privilege action within short time window

   • Condition: config export within 5–15 minutes of login
   • Add AI: sequence modeling (login → export) with risk weighting

4. Sudden change in FortiCloud SSO enablement state

   • Condition: SSO feature toggled / registration event precedes auth anomalies
   • Add AI: detect “feature enablement drift” across fleet

The point isn’t that AI magically “knows it’s CVE-2025-59718.” The point is that AI recognizes the behavior is wrong for your environment even when the exploit path is new.

Automated response: where AI helps you buy time

Answer first: The fastest containment is to reduce the blast radius of identity events—automatically.

When the alert fires, AI-assisted SOAR playbooks can do the boring-but-critical steps immediately:

• Temporarily restrict management-plane access to a known safe jump host range
• Disable FortiCloud SSO (as a mitigation) until patched and validated
• Force credential rotation for local admin accounts (and any secrets present in configs)
• Pull and snapshot device configs (your copy, not the attacker’s)
• Trigger incident workflow: preserve logs, open a case, notify network team

Speed matters because config export is often followed by deeper access attempts: VPN abuse, lateral movement, and reuse of cracked hashes.

Practical mitigation checklist (do this before the weekend)

Answer first: Patch, reduce exposure, then validate with monitoring—because attackers are already testing you.

If you manage FortiGate devices, here’s a focused checklist aligned to the observed activity:

1) Patch immediately, then verify the version

• Apply Fortinet’s patches for the affected products in your environment.
• Confirm the running version post-maintenance (don’t assume the job completed).

2) Disable FortiCloud SSO until you’re patched

• If FortiCloud SSO is enabled and you don’t strictly need it, turn it off.
• If you do need it, keep it off until patching is complete and you’ve validated access paths.

3) Lock down the management plane (non-negotiable)

• Restrict management GUI access to internal networks or a hardened admin jump host.
• Block management access from the public internet unless there’s a documented business requirement.

4) Hunt for the specific “login then export” pattern

• Search for successful SSO logins to admin.
• Correlate those logins with GUI configuration exports.
• Pay attention to logins from unfamiliar IPs, especially cloud/hosting ranges.

5) If you find indicators, assume compromise and rotate secrets

• Treat exported configurations as data exfiltration.
• Reset credentials that could appear in configs (even if hashed).
• Increase password strength requirements to resist offline cracking.

A blunt rule that holds up: If an edge device config left your environment, you should behave as if the attacker has a map of your internal network.

Where this fits in the AI in Cybersecurity series

Answer first: Incidents like the FortiGate SAML bypass show why AI belongs in identity security and SOC operations—not just in malware detection.

This Fortinet episode isn’t unique; it’s representative. Attackers keep choosing paths that are:

• high-impact (edge devices)
• low-friction (auth bypass)
• fast to monetize or operationalize (config export → cracking → reuse)

AI in cybersecurity earns its keep when it reduces the time between “first weird login” and “containment action.” That’s the difference between a scary alert and a full-blown incident.

If you’re building your 2026 security roadmap right now, I’d argue for a simple priority shift: treat authentication monitoring as a primary detection surface, and use AI to baseline it across your environment. Your firewall is no longer just a firewall; it’s an identity endpoint.

Before your next patch cycle, ask your team one uncomfortable question: If a privileged SSO login happens to an edge device at 3:12 a.m., will you know in 3 minutes—or in 3 days?