FortiGate SAML SSO bypass attacks are active. Learn what to patch, what to monitor, and how AI anomaly detection can catch malicious admin behavior fast.
FortiGate SAML SSO Bypass: Detect It Faster With AI
A critical Fortinet FortiGate authentication bypass is being exploited in the wild, and the uncomfortable lesson is this: SSO can fail “open” in ways most teams don’t monitor. When the perimeter device itself is the target, you don’t get the luxury of slow incident response. You either catch it early—or you’re reading your own firewall configuration out of an attacker’s hands.
The flaws (CVE-2025-59718 and CVE-2025-59719, both rated 9.8) abuse crafted SAML messages to bypass SSO authentication when FortiCloud SSO is enabled. Arctic Wolf reported malicious SSO logins against the admin account and subsequent export of device configurations via the GUI to external IP addresses. CISA has also placed CVE-2025-59718 in the Known Exploited Vulnerabilities catalog, with a rapid remediation deadline for U.S. federal agencies.
This post is part of our AI in Cybersecurity series, and I’m going to take a clear stance: patching is necessary, but it’s not a detection strategy. Real resilience comes from combining hardening with AI-driven anomaly detection that spots suspicious authentication and admin behavior in minutes—not days.
What’s happening with the FortiGate SAML SSO authentication bypass
Answer first: Attackers are bypassing SSO logins on affected Fortinet appliances by submitting crafted SAML messages, then using successful “admin” access to export configurations.
Fortinet released patches for FortiOS and related products (FortiWeb, FortiProxy, FortiSwitchManager). The issue becomes exploitable when FortiCloud SSO is enabled, and that’s where many environments get caught off-guard: while it’s disabled by default, it can be enabled during registration unless an admin explicitly turns off the option to allow administrative login via FortiCloud SSO.
Why this exploit path is especially dangerous
If an attacker gets into a firewall or VPN appliance admin interface, they can often:
- Pull full configuration backups, including network topology, VPN settings, and policy rules
- Extract hashed credentials stored in configs, then crack them offline if they’re weak
- Add new admin users, API tokens, or automation hooks to maintain persistence
- Quietly modify security policies (for example, add permissive rules or bypass inspection)
This isn’t theoretical. The reported behavior—malicious SSO login → GUI config export—is a classic “get in, grab the blueprint, and come back better prepared” pattern.
The early-stage, opportunistic nature matters
Arctic Wolf noted the activity appears opportunistic and early. That’s actually bad news in practice: early opportunistic campaigns are when attackers are scanning broadly, finding the easy wins, and scaling.
If your management plane is exposed, your admin account is reachable, and you haven’t patched, you’re the “easy win.”
Why SAML SSO is a recurring weak spot (and why teams miss it)
Answer first: SAML SSO attacks succeed because organizations often treat identity flows as “trusted plumbing,” while monitoring focuses on endpoints and network traffic.
SAML is widely used because it reduces password sprawl and centralizes access. But the same centralization means a single break in the trust chain—signatures, assertions, replay protections, issuer validation—can have outsized impact.
Here are the operational reasons this keeps happening:
1) “SSO is secure” becomes a blind assumption
Most organizations do monitor VPN logins and privileged access… but they don’t always separate:
- password-based admin login n- SAML-based admin login n- break-glass local accounts
When SSO is enabled for administrative access to a network appliance, the blast radius expands fast.
2) Management-plane exposure is still common
Even mature environments sometimes allow management access from:
- broad corporate IP ranges
- third-party vendor networks
- remote access subnets shared by many users
That’s not “wrong,” but it means a bypass turns into a breach immediately.
3) GUI activity isn’t logged and alerted like it should be
A config export via GUI should be treated like a database dump. Instead, it’s often a low-signal log line that nobody tunes alerts for.
What to do right now: a pragmatic response checklist
Answer first: Patch immediately, disable FortiCloud SSO until patched, lock down management access, and assume compromise if you see the IoCs pattern.
If you run FortiGate (or manage it for customers), here’s a response plan that works in the real world.
Step 1: Patch, then verify the running version
Apply the vendor fixes for affected products. Don’t stop at “scheduled maintenance.” Active exploitation compresses your timeline.
Then confirm the actual running version across your fleet. In incident work, I keep seeing “we patched” followed by “that one HA node didn’t fail over and update.”
Step 2: Disable FortiCloud SSO for administrative logins (until fully updated)
Because the exploit path depends on FortiCloud SSO being enabled, disabling it is a direct mitigation. You may need it later—but right now you need certainty.
Step 3: Restrict management-plane access aggressively
At minimum:
- Allow admin GUI/SSH only from hardened jump hosts
- Enforce VPN + device posture checks for admins
- Block inbound management from the public internet (even “temporarily”)
If you can’t do all of that today, do one thing: force management traffic through a single controlled path you can monitor well.
Step 4: Hunt for the behaviors that actually matter
The reported pattern gives you a clean hunt model:
- SSO logins against
admin - logins from unfamiliar hosting providers / ASN ranges
- GUI actions that export or download configuration
- outbound connections from the appliance to unfamiliar external IPs
A useful rule: If your firewall is sending data to a random host, treat it like malware until proven otherwise.
Step 5: If configs were exported, rotate credentials like you mean it
If configuration data left the device, assume hashed secrets are now subject to offline cracking. Prioritize:
- admin passwords and local accounts
- VPN user secrets or PSKs (where applicable)
- service accounts and automation credentials referenced in config
- any reused passwords (yes, they still happen)
Also rotate any credentials that could be derived indirectly (shared jump host passwords, monitoring accounts, TACACS/RADIUS shared secrets).
Where AI helps: catching SSO bypass and “quiet admin” behavior
Answer first: AI-driven anomaly detection is effective here because the signal isn’t a known malware signature—it’s unusual authentication and administrative behavior across time, users, devices, and networks.
This is the exact kind of incident that exposes the limits of static rules:
- The login may look “valid” at the application layer.
- The attacker uses built-in features (SSO login, GUI export).
- Indicators can be minimal, especially early on.
AI helps by modeling what “normal” looks like for admin access and then flagging deviations quickly.
Practical detection ideas that work well with ML
You don’t need sci-fi. You need models that score events using context:
- SSO login rarity: “FortiGate admin SSO logins happen 2 times/month; why did we have 4 in 10 minutes?”
- Geo/ASN deviation: “Admin logins never come from hosting ASNs; why now?”
- Time-of-week anomalies: It’s December and many teams are on holiday coverage. If your environment typically has no changes Friday night, treat Friday-night admin sessions as higher risk.
- Sequence anomalies: Login → immediate config export → outbound transfer is a high-confidence chain.
- Peer-group analysis: Compare one firewall against others: “Only this device exported config today.”
The simplest “AI win”: reduce alert fatigue while raising confidence
Security teams ignore alerts when everything is high priority. AI scoring helps by:
- grouping related events into a single incident storyline
- weighting alerts by business criticality (perimeter device > workstation)
- suppressing predictable admin automation while highlighting novel patterns
In my experience, the best outcome is not “AI replaces analysts.” It’s AI gets your analyst to the right screen first.
AI also helps after containment
Once you’ve patched and locked down access, you still need to answer:
- Did the attacker modify policies?
- Did they add persistence (new admins, API tokens, scheduled tasks)?
- Did they pivot to internal systems using knowledge from the config?
AI-assisted correlation across firewall logs, identity logs, VPN logs, and endpoint telemetry speeds this up dramatically.
“People also ask” answers you’ll want handy
How do attackers abuse SAML to bypass authentication?
They exploit weaknesses in how a system validates SAML assertions—often around signature verification, issuer/audience checks, or message structure—so the target accepts a forged authentication result.
If FortiCloud SSO is disabled by default, why are organizations still exposed?
Because features get enabled during onboarding or registration workflows, and settings can drift over time. The real risk is configuration surprise—what you think is off may be on.
Why export of firewall configuration is a big deal
A firewall configuration is effectively a map of your environment: subnets, VPN entry points, routing, security rules, and sometimes credential material. It turns a random attacker into a well-informed one.
What this FortiGate incident should change in your security program
SSO is a control plane. Treat it like one. That means:
- Monitor identity events as first-class security telemetry, not just IT logs
- Instrument management-plane actions (exports, backups, policy edits) with high-signal alerts
- Assume appliances are targets, not neutral infrastructure
- Use AI in cybersecurity operations to spot behavior chains that signatures miss
If you want one concrete next step: build a detection rule (and ideally an ML model) that raises an incident when a privileged SSO login is followed by a configuration export within a short window. That single correlation catches an enormous amount of real attacker behavior.
If you’re thinking, “Do we even have the logs to do that?”—that’s the point. The FortiGate SAML SSO bypass is your reminder to make identity and admin telemetry non-optional.
Where are your blind spots right now: SSO authentication, management-plane access, or your ability to spot unusual admin behavior fast enough to matter?