Listen to this Post
Introduction:
Fortinet has confirmed that two critical vulnerabilities in its FortiCloud Single Sign-On (SSO) feature, tracked as CVE-2025-59718 and CVE-2025-59719, are being actively exploited in the wild. These flaws, with a maximum severity CVSS score of 9.8, allow unauthenticated attackers to completely bypass authentication on affected devices by sending crafted SAML messages. This incident underscores the catastrophic risk posed by edge security devices when a vulnerability in a core, trusted feature like SSO is weaponized.
Learning Objectives:
- Understand the technical mechanism of the SAML authentication bypass affecting multiple Fortinet products.
- Learn immediate mitigation steps, including CLI commands to disable the vulnerable feature and inspect logs for compromise.
- Develop a long-term hardening strategy for network appliance management interfaces to prevent similar breaches.
You Should Know:
1. The Anatomy of a Critical SAML Bypass
The core failure is an Improper Verification of Cryptographic Signature (CWE-347) in the FortiCloud SSO implementation. Security Assertion Markup Language (SAML) is a protocol that allows identity providers to pass authentication credentials to service providers. In a secure flow, the service provider (the FortiGate) must cryptographically validate the signed assertion from the identity provider (FortiCloud).
What Happened: The vulnerability allows an attacker to forge a malicious SAML response. The affected Fortinet products fail to properly verify the digital signature on this crafted message, accepting it as legitimate. Consequently, an attacker can trick the device into logging them in as any user, most notably the privileged ‘admin’ account, without any valid credentials.
Step-by-step Exploitation Path:
- Reconnaissance: Attackers scan the internet for Fortinet management interfaces (port 443) using tools like Shodan or Censys.
- Target Verification: They check if the target has the FortiCloud SSO login option enabled, which is often turned on automatically during device registration with FortiCare.
- Crafting the Payload: The attacker creates a malicious SAML response message designed to exploit the signature verification flaw.
- Authentication Bypass: Sending this payload to the vulnerable device’s SSO endpoint grants unauthenticated access as an administrator.
- Post-Exploitation: As observed by Arctic Wolf, attackers immediately export the full device configuration, which contains hashed administrator credentials and the complete network security posture.
2. Immediate Action: Detect and Disable the Threat
If you cannot patch immediately, you must disable the vulnerable FortiCloud SSO feature. This is a critical workaround provided by Fortinet.
Step-by-step Mitigation Guide:
Via Graphical User Interface (GUI):
- Log in to your Fortinet device (FortiGate, FortiProxy, etc.).
2. Navigate to System > Settings.
- Locate the setting “Allow administrative login using FortiCloud SSO”.
4. Toggle the switch to OFF.
Via Command Line Interface (CLI): This is the fastest method, especially for managing multiple devices. Use the following commands:
Connect to your Fortinet device via SSH ssh admin@<fortinet_device_ip> Enter configuration mode for the global system settings config system global Disable the FortiCloud SSO login feature set admin-forticloud-sso-login disable Exit configuration mode and save the change end
Detection in Logs: Check your logs for evidence of exploitation. Look for successful admin logins from the `sso` method originating from suspicious IPs. Arctic Wolf has published indicators of compromise, including IPs from hosting providers like The Constant Company LLC, Bl Networks, and Kaopu Cloud Hk Limited.
Example Malicious Log Entry:
`logdesc=”Admin login successful” user=”admin” ui=”sso(199.247.7[.]82)” method=”sso” srcip=199.247.7[.]82 action=”login” status=”success”`
Follow-up Action Log: After login, attackers downloaded configs:
`logdesc=”Admin performed an action from GUI” action=”download” msg=”System config file has been downloaded”`
3. Strategic Patching: Navigating the Upgrade Path
Disabling SSO is a temporary fix. Patching is the only permanent solution. A shared codebase means multiple products are affected, requiring a coordinated upgrade effort.
Step-by-step Patching Guide:
- Identify Affected Versions: Cross-reference your device’s firmware version with the official advisory:
FortiOS 7.6: Upgrade from versions 7.6.0-7.6.3 to 7.6.4 or above.
FortiOS 7.4: Upgrade from versions 7.4.0-7.4.8 to 7.4.9 or above.
FortiProxy 7.4: Upgrade from versions 7.4.0-7.4.10 to 7.4.11 or above.
FortiWeb 7.6: Upgrade from versions 7.6.0-7.6.4 to 7.6.5 or above.
(Consult for a complete list of products and versions.) - Plan the Upgrade: Use Fortinet’s upgrade path tool (`https://docs.fortinet.com/upgrade-tool`) to plan a valid upgrade sequence and avoid firmware compatibility issues.
- Schedule Maintenance: Plan an outage window. Always back up your configuration before starting.
- Execute the Upgrade: Upload the new firmware image via the GUI or CLI and reboot the device.
- Post-Upgrade Validation: Verify the new version is running and re-enable FortiCloud SSO if needed for your operations. Crucially, review logs and configurations for any unauthorized changes made during the window of compromise.
4. Credential Recovery and Post-Compromise Actions
If you find evidence of malicious SSO logins or configuration downloads, you must assume your hashed credentials are compromised. Attackers will attempt to crack these hashes offline.
Step-by-step Credential Reset and Audit:
- Assume Breach: Operate under the assumption that any credential hash in a downloaded configuration file is in adversary hands.
- Rotate All Credentials: Change passwords for all administrator accounts on the compromised device. Enforce strong, unique passwords that resist dictionary attacks.
- Audit User Accounts: In the CLI, list all administrator accounts and verify their legitimacy.
show system admin
Look for any newly created, unauthorized accounts.
- Review System Configurations: Compare your current running config with a known-good backup. Pay special attention to:
New firewall policies (especially those allowing inbound traffic).
Changes to VPN settings (SSL-VPN, IPsec).
Modifications to SNMP or syslog server destinations.
Added static routes pointing to unfamiliar gateways.
5. Long-Term Hardening: Beyond This Patch
This event highlights systemic risks in managing perimeter security appliances. Implementing defense-in-depth principles is non-negotiable.
Step-by-step Network Hardening Guide:
- Restrict Management Access: Never expose firewall, VPN, or switch management interfaces directly to the internet. Use a jump host or a dedicated management VLAN. Implement Zero Trust Network Access (ZTNA) for administrative connections.
- Implement Multi-Factor Authentication (MFA): Where possible, enable MFA for all administrative access. This provides a critical layer of defense even if credentials are stolen.
- Segment Critical Networks: Adhere to the “Adama Principle” mentioned in the original thread: avoid inter-connecting critical or sensitive networks unnecessarily. Use firewalls to enforce strict segmentation.
- Enable Robust Logging and Monitoring: Ensure logs are sent to a centralized, secure SIEM (like FortiAnalyzer). Create alerts for any successful admin login, especially via SSO, and for configuration download events.
What Undercode Say:
- The Default Setting Trap is a Critical Vulnerability. A feature turned on by default during a routine administrative task (device registration) created a widespread attack surface. Security must audit not just code, but deployment workflows and default states.
- Edge Devices are Crown Jewels, Not Just Perimeter Walls. Compromising a firewall doesn’t just breach the perimeter; it gives attackers a trusted foothold, network maps, and credential hashes. Their security requires a paradigm shift towards the highest level of internal protection.
Analysis: This exploitation wave is a classic example of the “patch gap” crisis, where the window between disclosure and weaponization shrinks to zero. The attacker’s focus on immediately exfiltrating configurations reveals a mature, resource-conscious approach aimed at credential harvesting and lateral movement planning. The incident also exposes the double-edged sword of a unified codebase: while it enables consistent features and management, a single flaw can ripple across an entire product ecosystem. The recommendation to abandon internet-facing management interfaces is not new, but its repeated violation by organizations continues to be a primary enabler for such large-scale attacks.
Prediction:
In the next 6-12 months, we predict a secondary wave of incidents stemming from this initial breach. The stolen configuration files and cracked credential hashes will be used in targeted, follow-on attacks against the internal networks of compromised organizations. Furthermore, the technical specifics of this SAML bypass will be reverse-engineered and adapted by threat actors to probe for similar logic flaws in other vendors’ SSO implementations, potentially leading to a new vulnerability class focused on federated authentication in network appliances. This event will accelerate the market shift towards ZTNA and cloud-based, identity-centric management planes for security infrastructure, moving away from traditional IP-based management access.
▶️ Related Video (86% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jerin Johnson – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
