FortiGate Under Siege: Automated Attacks Exploit SSO Bug [2025]

Something nasty is happening right now with Fortinet FortiGate firewalls. And it's the kind of thing that keeps security teams awake at 2 AM.

Hackers aren't knocking on doors anymore. They're using your own firewall against you, exploiting a patch that Fortinet released but apparently didn't fully fix. They're creating administrator accounts. They're stealing firewall configuration files. They're mapping your entire network topology. And according to Shadowserver data, there are over 10,000 vulnerable endpoints still exposed.

Here's what you need to know, and more importantly, what you need to do about it right now.

TL; DR

• Critical SSO Vulnerability: Hackers are exploiting an incomplete patch in FortiOS 7.4.10 to create rogue admin accounts via the single sign-on feature, as reported by The Hacker News.
• Massive Exposure: Stolen firewall configurations reveal network topology, VPN settings, security rules, and authentication mechanisms, enabling lateral movement and persistence.
• 10,000+ At Risk: Shadowserver reports over 10,000 vulnerable FortiGate endpoints globally, with automated attacks already underway.
• Patch Isn't Enough: The current patch doesn't fully fix the vulnerability; Fortinet is releasing new versions (7.4.11, 7.6.6, 8.0.0) to address the gap, according to Risky Business.
• Immediate Action Required: Organizations running FortiGate need to apply patches immediately and monitor for unauthorized admin accounts and suspicious configuration exports.

Estimated data shows that while 10,000 FortiGate devices are visible to scanners, many more remain hidden behind security layers or are unpatched, increasing the total vulnerability count.

Understanding the Attack Surface: What's Actually Happening

Let's be clear about what we're dealing with here. This isn't a theoretical vulnerability that requires a specific configuration. Real attackers are actively exploiting this right now, using automated scripts to find vulnerable FortiGate instances and compromise them at scale.

The attack starts with the single sign-on (SSO) feature in FortiOS. SSO is supposed to make authentication easier by centralizing user management. Instead, attackers discovered they could abuse this feature to create administrator accounts without proper authorization checks. That's the kind of flaw that makes you wonder how it got past code review.

What makes this particularly dangerous is the automation aspect. Security researchers at Arctic Wolf observed attackers using scripts to systematically compromise FortiGate instances. They're not manually typing commands. They're running batch processes that identify vulnerable firewalls, create rogue accounts, export configurations, and move on to the next target. It's industrial-scale compromise.

The similarity to December 2024 attacks involving CVE-2025-59718 and CVE-2025-59719 suggests this might be the same threat actor continuing their campaign with refined techniques. Or it could be copycats who saw how effective the December attacks were and are replicating the playbook.

Either way, the result is the same: your firewall, which is supposed to be your first line of defense, becomes an entry point for attackers.

Estimated data suggests that while 10,000 endpoints are identified as vulnerable, an additional 5,000 may be hidden, and around 2,000 could already be compromised. Estimated data.

The December 2024 Context: How We Got Here

To understand the current situation, you need to know what happened two months ago. In December 2024, Arctic Wolf and other security researchers identified two critical vulnerabilities in FortiGate that attackers were actively exploiting in the wild.

CVE-2025-59718 and CVE-2025-59719 were both related to authentication bypass vulnerabilities. The CVE-2025-59718 specifically affected the SSL VPN component, allowing unauthenticated users to create VPN connections under certain conditions. CVE-2025-59719 involved improper access control that could allow privilege escalation.

Fortinet released patches for these vulnerabilities, which is standard procedure. Organizations updated their systems. Security teams thought the problem was solved. Then in January 2025, researchers began noticing new suspicious activity that looked similar but didn't match the signatures of the old vulnerabilities.

That's when it became clear that either the December patch had gaps, or attackers found a workaround, or both. The current campaign bears all the hallmarks of an incomplete fix that threat actors quickly identified and exploited.

What's particularly frustrating about this timeline is that Fortinet customers were given a false sense of security. They applied the patch, patted themselves on the back, and moved on. Now they're discovering that the vulnerability wasn't actually fixed. It was just partially covered.

This is a pattern we see repeatedly in enterprise security. A vendor announces a critical vulnerability. They release a patch. Everyone updates. Then a few weeks later, someone discovers the patch didn't fully address the issue. By then, the damage is often already done.

How Stolen Firewall Configurations Become a Nightmare

You might be wondering: okay, so they stole my firewall configuration. How bad is that really? The answer is much worse than you probably think.

A firewall configuration file isn't just technical settings. It's a detailed map of your entire network security posture. When attackers export your FortiGate configuration, they gain access to information including:

Network Topology Exposure: Your configuration reveals how your network is segmented, which networks are considered trusted, and how traffic flows between different zones. Attackers can see your DMZ, internal networks, guest networks, and management networks all laid out in detail.

VPN Details: The configuration includes VPN settings, certificate information, and tunnel parameters. This allows attackers to potentially establish VPN connections without needing legitimate credentials, or to impersonate legitimate VPN users.

Security Rules and Policies: Every firewall rule that allows or blocks traffic is there. Attackers can identify which services are exposed, which are blocked, and which have weak filtering. They can find services that are supposed to be internal but are accidentally exposed.

Authentication Mechanisms: The configuration shows what authentication methods are used, which directories are integrated (Active Directory, LDAP, etc.), and which users or groups have admin access. This information is invaluable for lateral movement.

User Accounts and Groups: The configuration file contains references to administrative accounts and group memberships. Attackers can target specific admin accounts or identify service accounts they can compromise.

Encryption Keys and Certificates: Depending on what's exported, the configuration might include certificate information or key references that could compromise encrypted communications.

Once attackers have this information, the real attack begins. They use the network topology to identify which servers to target next. They use the security rules to find exploitable services. They use the authentication information to compromise high-value accounts. They use the VPN details to establish persistence.

It's not just a configuration file. It's a complete blueprint of your defenses and the keys to bypass them.

Estimated data suggests that 'Multiple Exploitation Vectors' has the highest impact level, indicating that the patch addressed only the most obvious issues, leaving other vulnerabilities open.

The Incomplete Patch Problem: Why 7.4.10 Doesn't Solve It

Fortinet released FortiOS version 7.4.10 with the intention of fixing this vulnerability. But here's the problem: it doesn't fully fix it. Not even close.

Why would a security patch for a critical vulnerability not actually fix the vulnerability? There are several possible reasons, and none of them inspire confidence.

Scenario One: Partial Fix Under Pressure: Fortinet might have identified part of the vulnerability and released a quick patch to show they were responding to the threat. But in their haste, they missed the actual root cause or didn't test comprehensively. The second attack wave revealed the gaps.

Scenario Two: Multiple Exploitation Vectors: The SSO feature might have several different ways to be abused. The first patch addressed the most obvious one, but attackers found alternative paths to achieve the same result. It's not that the patch is wrong; it's that the underlying feature has multiple flaws.

Scenario Three: Configuration-Dependent Vulnerability: The vulnerability might only be exploitable in certain configurations. Fortinet's patch might work for some deployments but not others, depending on how SSO is configured or which other features are enabled.

Scenario Four: Environmental Factors: The vulnerability might depend on specific environmental conditions like particular versions of integrated services, specific authentication backends, or particular configurations of other features. The patch might not account for all these permutations.

Regardless of the reason, the practical result is the same: organizations that applied the FortiOS 7.4.10 patch are still vulnerable. Attackers are still able to create admin accounts and export configurations.

Fortinet's response has been to announce that new versions are "in the pipeline." They've specifically called out FortiOS 7.4.11, 7.6.6, and 8.0.0 as containing the full fix. These are planned to be released within days (as of the incident report).

But here's the thing about software releases being "planned" to ship in a few days: plans change. Delays happen. Build tests fail. New issues are discovered. Organizations need to be prepared for the possibility that these "coming soon" fixes get pushed back.

The Scale of Exposure: 10,000+ Vulnerable Endpoints

When Shadowserver published their data showing over 10,000 vulnerable FortiGate endpoints, that number should have triggered alarms throughout the security community. And it did, but maybe not enough.

Ten thousand endpoints is a massive number. These aren't niche devices running in a few organizations. These are firewalls from enterprise companies, government agencies, educational institutions, and service providers. Each one potentially exposing their entire network.

But here's what's really concerning: that 10,000 number is only counting endpoints that Shadowserver could identify as vulnerable through their scanning process. The actual number of vulnerable endpoints is likely much higher. Some organizations have their FortiGate instances behind additional firewalls or proxies that hide them from external scanners. Some have network configuration that makes them invisible to Shadowserver's scanning methodology.

The real question isn't "are there 10,000 vulnerable endpoints?" It's "how many of those 10,000 have already been compromised?"

Arctic Wolf reported seeing active exploitation with automated scripts. That means at least some subset of those 10,000 endpoints have already been hit. The question is whether organizations know they've been compromised.

Security teams face a challenge here. Even if you applied the 7.4.10 patch, you might still be vulnerable. But you probably can't easily determine whether you've been compromised without forensic investigation. You'd need to:

1. Export the admin account audit logs and look for accounts you didn't create
2. Check for configuration exports in the logs
3. Review authentication attempts for successful logins from unexpected sources
4. Analyze firewall flow logs for unusual outbound connections from the firewall itself

That's time-consuming work, and most organizations don't have the resources to do a comprehensive forensic analysis of every FortiGate instance.

Stolen firewall configurations pose high risks across various areas, with network topology and encryption keys being particularly critical. Estimated data based on typical security assessments.

Automated Attack Campaigns: How the Exploitation Works

The automation aspect of these attacks is worth examining in detail because it reveals how modern threat actors operate at scale.

Traditional cyberattacks required significant human effort. A skilled attacker would manually identify targets, manually test for vulnerabilities, and manually perform compromise steps. They were slow, but they were thorough.

Modern attacks use scripts and automation. The process looks something like this:

Stage 1: Reconnaissance and Scanning: Attackers use internet scanning tools (or purchase results from scanning services) to identify all publicly accessible FortiGate instances. They check the HTTP headers and response pages to determine which versions are running. This stage might identify thousands of targets worldwide in minutes.

Stage 2: Vulnerability Verification: The script automatically sends specific requests to determine if the target is vulnerable to the SSO bypass. This doesn't require human analysis; the script just checks for specific response codes or behaviors that indicate vulnerability.

Stage 3: Exploitation: Once a vulnerable instance is identified, the automated script exploits the SSO vulnerability to create a new administrator account. The script uses predictable account names and credentials, making it less likely for human defenders to notice.

Stage 4: Data Extraction: Using the newly created admin account, the script exports the firewall configuration file. This happens automatically and leaves minimal traces in typical audit logs because the request came from a legitimate admin account.

Stage 5: Data Staging: The extracted configuration is saved to a temporary location on the FortiGate instance or immediately transmitted to an attacker-controlled server.

Stage 6: Cleanup and Pivot: The script either removes the evidence of compromise or leaves the admin account in place for later use. Either way, it moves on to the next target.

The entire process, from initial discovery to data extraction, might take seconds per target. An attacker could potentially compromise hundreds of FortiGate instances in a single night.

What makes this particularly effective is that automated attacks don't care about skill or resources. A moderately skilled attacker can write a script once, then let it run against thousands of targets simultaneously. The marginal cost of each additional compromise is essentially zero.

The SSO Feature as an Attack Vector: Design Weakness

The fact that the vulnerability exists in the SSO feature itself reveals something interesting about how complex security systems can have unintuitive weak points.

SSO is supposed to be a security improvement. Instead of every application maintaining its own user database and passwords, SSO centralizes authentication. Users log in once, and that authentication token grants access to all connected applications and services. For users, it's convenient. For security teams, it's supposed to be more manageable.

But SSO introduces new complexity. The FortiGate device needs to trust tokens from the SSO provider. It needs to validate those tokens correctly. It needs to ensure that only users who actually authenticated get their tokens accepted.

Apparently, something in this process is broken. Attackers can either:

1. Forge SSO tokens that the FortiGate trusts
2. Use SSO tokens in ways that bypass normal restrictions
3. Create accounts that bypass SSO token validation entirely
4. Exploit a race condition in the SSO validation process

Without seeing Fortinet's specific code, it's hard to know exactly which, but all of these are classic SSO bypass patterns.

The broader lesson here is that adding features like SSO to a firewall makes the code more complex, and more complex code has more bugs. Every integration point is a potential vulnerability. Every feature is an additional attack surface.

This isn't unique to Fortinet. Other firewall vendors have had similar issues. The lesson is that even security appliances from trusted vendors can have critical flaws, especially when they implement complex features like SSO.

Estimated data shows increasing trends in incomplete patches, automation in attacks, and vulnerabilities due to complex features, highlighting the evolving challenges in enterprise security.

Impact on Connected Networks and Partners

One aspect of this attack that often gets overlooked is the downstream impact on connected networks and partner organizations.

When an attacker steals your FortiGate configuration, they don't just gain knowledge about your network. They gain knowledge about all networks connected to yours. If you have a VPN connection to a partner organization, that's documented in your configuration. If you have a site-to-site connection to a branch office, that's there too. If you have a cloud connection, Azure Express Route, AWS Direct Connect, or any other connection, it's all in that configuration file.

Attackers can use this information to:

Target Connected Networks: If your configuration shows a VPN tunnel to a partner's network, attackers can now target that partner's network knowing that a trusted path exists from your compromised FortiGate to their network.

Establish Secondary Footholds: Attackers can use the VPN credentials from your configuration to establish their own connections to partner networks, potentially without those partners knowing.

Chain Compromises: Attackers can use your compromised FortiGate as a jumping-off point to compromise connected networks, which then become attack platforms for additional targets.

Supply Chain Targeting: Attackers know which organizations your network trusts. They can use this information to prioritize targets, knowing that if they compromise a partner first, they can then use that compromise to get into your network.

This creates a cascading risk scenario where a single FortiGate compromise can ultimately expose multiple organizations.

Many organizations don't adequately communicate security incidents with their partners. If you discover you've been compromised, you have a responsibility to inform connected organizations so they can check their logs and monitor for suspicious activity from your network.

Immediate Response Actions for Affected Organizations

If you're running FortiGate and haven't already taken action, here's what needs to happen immediately. Not soon. Not within a few days. Right now.

Action 1: Audit Admin Accounts

Log into your FortiGate instances and review all administrative accounts. Look for:

• Accounts you don't recognize
• Accounts created recently that you didn't create
• Accounts with generic names
• Service accounts that shouldn't exist
• Accounts with unusual email addresses or descriptions

For each account, check when it was created by reviewing the admin audit logs. Any accounts created in the last 60 days should be carefully examined unless you can document that you created them.

If you find suspicious accounts, take them offline immediately and preserve the logs for forensic analysis.

Action 2: Review Configuration Exports

FortiGate devices log when configurations are exported. These logs should be in the audit trail. Look for configuration exports that you didn't initiate, or exports from admin accounts that shouldn't be exporting configurations.

Check both the GUI logs and the system logs. Look for entries showing configuration downloads or backups.

Action 3: Enable Strict Logging

If you haven't already, enable detailed audit logging for all administrative actions. This should include:

• All logins (successful and failed)
• All account creations
• All configuration changes
• All policy modifications
• All certificate changes

Set log retention as long as your system supports. These logs might be the only evidence of a compromise.

Action 4: Plan Your Patch Strategy

You need to decide: do you wait for FortiOS 7.4.11, 7.6.6, or 8.0.0, or do you upgrade to a version that might not have this specific vulnerability?

If you're on 7.4.10 and want to stay on the 7.4 branch, you'll need to wait for 7.4.11. If you're willing to upgrade to 7.6.x, you might have more version options available now.

But here's the thing: any significant version upgrade should be tested in a lab environment first. You don't want to introduce new problems while trying to fix this one.

Action 5: Implement Network Monitoring

Even if you patch, monitor your FortiGate instances for unusual behavior:

• Unexpected outbound connections from the firewall itself
• Unusual SSL/TLS connections to the management interface
• High-volume data exports or backups
• Configuration changes that don't match your change management process

Action 6: Verify VPN Integrity

If you have VPN connections configured on the FortiGate, verify they're still intact and that no suspicious VPN tunnels have been added. Check the VPN logs for unusual connection attempts.

Action 7: Review Firewall Rules

Attackers might modify firewall rules to create backdoors or exfiltration paths. Review all inbound and outbound rules to ensure nothing suspicious has been added. Compare your current ruleset to recent backups if available.

Action 8: Change Admin Credentials

Change the password for all administrative accounts, especially any built-in accounts or service accounts that might have been using default credentials. If you use LDAP or other directory integration, verify those credentials haven't been captured.

Auditing admin accounts is the highest priority action, followed by reviewing configuration exports and enabling strict logging. Planning a patch strategy is crucial but can be slightly delayed. Estimated data.

Patching Timeline and Version Strategy

Fortinet has committed to releasing patched versions, but here's what we know about the timeline and strategy.

FortiOS 7.4.11: This is the patched version of the 7.4 branch. If you're running 7.4.10, this is probably your first choice for an upgrade. However, wait times after release can be significant as Fortinet customers rush to update. There will likely be a queue.

FortiOS 7.6.6: This is a newer version that should contain the fix. If you're on an older version of the 7.6 branch, this gives you the security fix. However, upgrading between minor versions (7.4 to 7.6) introduces more risk than patching within the same version (7.4.10 to 7.4.11).

FortiOS 8.0.0: This is the latest major version. It has the fix, but a major version upgrade is significant. FortiOS 8.x introduced several architectural changes and behavioral differences. Organizations should thoroughly test a major version upgrade before deploying to production.

The challenge is that Fortinet's release process is somewhat opaque. They announce versions are "in the pipeline," but they don't always give exact release dates. This leaves organizations in a difficult position. Do you wait for the patch or take other risk mitigation measures?

Most security professionals would recommend:

1. If you're on 7.4.10, wait for 7.4.11 if possible, but don't wait indefinitely. If it's not released within a week, consider upgrading to 7.6.6 or 8.0.0
2. If you're on an older version, you might actually be less vulnerable than those on 7.4.10 because you're not relying on an incomplete patch
3. Test any upgrade in a lab or dev environment first
4. Have a rollback plan in case the upgrade introduces new problems

Broader Security Implications: What This Tells Us

This vulnerability and attack campaign reveal several troubling trends in enterprise security.

Trend One: Incomplete Patches Are Becoming More Common: Whether due to pressure to respond quickly, complexity of the code, or insufficient testing, security patches that don't fully address vulnerabilities are happening more frequently. Organizations can't trust that a patch fully fixes a disclosed vulnerability.

Trend Two: Automation Enables Massive Scale: Modern threat actors don't need large teams or significant resources. A well-written exploit script can compromise thousands of systems automatically. Defenders are increasingly outgunned by attackers' automation.

Trend Three: Complex Features Create Complex Vulnerabilities: Adding features like SSO to security appliances increases attack surface. Fortinet chose to add SSO capability to FortiGate, expanding what the device can do. This expansion introduced this vulnerability.

Trend Four: Firewall Configurations Are High-Value Targets: The value attackers get from stealing a firewall configuration (complete network topology, security architecture, VPN details) is enormous. Firewalls are hardened against external attacks but often not hardened against insider threats or authenticated users with elevated privileges.

Trend Five: Disclosure Creates New Exploitation Windows: When Fortinet disclosed the original CVE-2025-59718 and CVE-2025-59719 vulnerabilities, they created a window where all organizations with unpatched systems were at risk. The December attacks exploited that window. The current attacks are using an incomplete patch, creating another window.

Organizations need to shift their thinking from "patch when convenient" to "patch when critical" and from "trust vendor patches" to "verify vendor patches actually work."

Monitoring and Detection: How to Spot Compromise

Even if you patch immediately, you need to assume that some systems might have already been compromised. Here's how to detect it.

Log Analysis: Examine FortiGate logs for:

• Failed login attempts followed by successful logins from unusual IP addresses
• Account creation events from admin accounts
• Configuration export events
• Unusual API calls or SSH commands
• SSL VPN connection attempts from unexpected sources

Behavioral Analysis: Look for:

• FortiGate instances initiating outbound connections to unusual destinations
• High-volume data transfers from the FortiGate to external servers
• Configuration changes that don't match your change log
• Policy modifications that increase permissiveness without authorization

Network Analysis: Monitor for:

• Unusual traffic patterns from your FortiGate instance
• Connections to known malicious IP addresses
• Excessive DNS queries for rare domains
• Data exfiltration over unusual protocols

Credential Analysis: If you can export Active Directory logs or LDAP logs for the same time period:

• Look for authentication attempts using admin credentials from unusual locations
• Check for service account activity at unusual times
• Look for lateral movement patterns that suggest an attacker pivoting through your network

The challenge is that modern firewalls log enormous amounts of data. A single FortiGate can generate gigabytes of logs per day. You need either a robust log analysis system or a managed security service provider with expertise in FortiGate forensics.

Long-Term Security Hardening

Beyond the immediate patch and response, this incident suggests several longer-term improvements to FortiGate security posture.

Principle One: Reduce Attack Surface

Disable any features on your FortiGate that you're not actively using. If you don't use SSL VPN, disable it. If you don't use SSO, disable it. If you don't use voice over IP features, disable them. Every enabled feature increases the attack surface.

Principle Two: Implement Admin Access Controls

Not all admins need full access. Implement role-based access control where:

• Some admins can modify policies
• Some admins can view logs only
• Some admins can manage certificates
• Some admins can manage user accounts

The principle of least privilege applies to firewall admin access too.

Principle Three: Separate Admin Networks

Administrative access to your FortiGate should come from a separate, dedicated management network. This prevents attackers on the regular network from compromising the firewall's management interface, even if they compromise other servers.

Principle Four: Implement MFA for Admin Access

FortiGate supports two-factor authentication for administrative access. Use it. A stolen password alone shouldn't be enough to compromise your firewall.

Principle Five: Monitor Configuration Changes

Implement a change management system that logs all configuration changes and requires approval. If someone tries to make an unauthorized change, the logs document it.

Principle Six: Regular Backups and Testing

Maintain regular backups of your FortiGate configuration. But also test your ability to restore from those backups. A backup is worthless if you can't restore it.

Principle Seven: Network Segmentation

Use your FortiGate to create proper network segmentation. Even if attackers get through one segment, they shouldn't be able to freely move to others. Zero-trust networking at the firewall level can limit lateral movement.

Industry Response and Disclosure Patterns

How Fortinet has handled this disclosure (or not handled it) is worth examining because it sets a precedent for how vendors handle incomplete patches.

Fortinet's approach has been:

1. Acknowledge the patch for the initial CVEs is incomplete
2. Announce that newer versions will fully fix the issue
3. Release those versions "in a few days"

What Fortinet has not done:

1. Provide a detailed root cause analysis of why the original patch was incomplete
2. Explain what specifically is different about the new patch versions
3. Provide a timeline with specific dates ("in a few days" is vague)
4. Provide interim mitigations for organizations that can't patch immediately
5. Publish forensic guidance for organizations trying to determine if they've been compromised

This is a common pattern in vendor responses to security issues. Vendors tend to minimize transparency to avoid further damaging their reputation. But from a security community perspective, this lack of transparency makes it harder for organizations to adequately protect themselves.

A more thorough vendor response would include:

• Detailed technical analysis of the vulnerability
• Forensic indicators that organizations can use to detect compromise
• Interim mitigation steps for organizations
• Specific timelines and version numbers
• Guidance on whether existing patches should be trusted or if they need to be reapplied

As an industry, we should expect more from vendors when they release incomplete patches.

Organizational Risk Assessment

Not all organizations face equal risk from this vulnerability. Your risk depends on several factors.

High Risk Factors:

• You have FortiGate instances exposed to the internet
• You're running FortiOS 7.4.10 or older versions
• You haven't yet applied any patches
• You have sensitive data accessible through your FortiGate network
• You have partner connections through this FortiGate
• You can't easily audit your admin account history
• You lack robust logging capabilities

Medium Risk Factors:

• You have FortiGate instances but they're behind additional layers of security
• You're running a non-vulnerable version but haven't verified this
• You have applied patches but suspect they might not be complete
• You have limited logging capabilities
• You lack a managed detection and response service

Lower Risk Factors:

• You have FortiGate instances in isolated environments with no external access
• You're running a version that's not vulnerable to this specific attack
• You have comprehensive logging and analysis capabilities
• You have a dedicated security operations center monitoring your infrastructure
• You have incident response procedures and backups ready

Organizations with high-risk factors should prioritize patching immediately, even if it means upgrading to a different version than they originally planned.

Future Vulnerabilities: What to Expect

This incident probably won't be the last critical vulnerability in FortiGate or similar devices. Here's what organizations should expect.

Expect More SSO-Related Issues: SSO is complex, and there are likely more vulnerabilities hiding in FortiGate's SSO implementation. Plan for additional SSO-related patches.

Expect Automation Attacks to Continue: Attackers will continue developing automated scripts to exploit vulnerabilities at scale. If they find a vulnerability, they'll weaponize it within hours or days.

Expect Patches Might Not Be Perfect: Vendors are under pressure to release patches quickly. Some patches will have gaps. Plan for follow-up patches.

Expect New Feature Vulnerabilities: Fortinet continues adding features to FortiGate (like AI-powered threat detection, cloud integration, etc.). Each new feature introduces new attack surface. Monitor their release notes carefully.

Expect Attackers to Chain Vulnerabilities: Attackers rarely exploit a single vulnerability in isolation. They chain vulnerabilities together to achieve their goals. A single vulnerability might be low-risk in isolation, but combining it with other vulnerabilities in the ecosystem could be critical.

Organizations should have a structured approach to staying current with vendor security information. This includes subscribing to advisories, monitoring security research, and maintaining relationships with security consultants who can provide guidance on emerging threats.

Conclusion: Security as an Ongoing Process

The Fortinet FortiGate vulnerability and automated attack campaign are a stark reminder that security isn't a one-time effort. It's an ongoing process of monitoring, patching, auditing, and improving.

The incident itself is serious: attackers are actively compromising firewalls at scale, creating rogue admin accounts, and stealing network configurations. Over 10,000 endpoints remain vulnerable. The patch that Fortinet released doesn't fully fix the issue.

But the incident is also instructive. It shows us that:

1. Even security appliances from trusted vendors can have critical flaws
2. Patches might not fully fix vulnerabilities
3. Attackers will rapidly weaponize new vulnerabilities at massive scale
4. Stolen firewall configurations are incredibly valuable and enable further compromise
5. Organizations need to assume they might be compromised and actively look for evidence

The organizations that will fare best through this incident are those that act quickly on multiple fronts: patching immediately, auditing for compromise, implementing better monitoring, and hardening their overall security posture.

For those running FortiGate, the time to act is now. Check for unauthorized admin accounts. Monitor your logs. Plan your patch strategy. Assume your firewall might already be compromised and look for evidence. Strengthen your overall security posture to limit the damage if compromise has occurred.

Security isn't about preventing all attacks. It's about detecting attacks quickly and responding effectively. This incident tests exactly that capability.

FAQ

What exactly is the vulnerability being exploited in FortiGate?

The vulnerability exists in the single sign-on (SSO) feature of FortiOS. Attackers can exploit an authentication bypass in the SSO implementation to create administrator accounts without proper authorization. This allows them to gain administrative access to the FortiGate firewall and export sensitive configuration data containing network topology, VPN settings, security rules, and authentication mechanisms.

Why is the FortiOS 7.4.10 patch incomplete?

The FortiOS 7.4.10 patch was designed to address CVE-2025-59718 and CVE-2025-59719, but it doesn't fully close the vulnerability. Attackers have discovered ways to bypass or circumvent the patch, likely because the patch addressed only part of the underlying issue or failed to account for specific exploitation methods. Fortinet has acknowledged this and is releasing newer versions (7.4.11, 7.6.6, and 8.0.0) to provide complete remediation.

How many FortiGate devices are currently vulnerable?

Shadowserver has identified over 10,000 vulnerable FortiGate endpoints globally based on their scanning data. However, this number likely represents only a portion of actually vulnerable devices, as many FortiGate instances are behind additional security layers or not visible to external scanners. Organizations running older versions of FortiOS that haven't yet applied any patches are also at risk.

How can attackers use stolen firewall configurations?

Stolen firewall configurations contain comprehensive information about an organization's network security posture, including complete network topology, VPN settings, security policies, authentication mechanisms, and trust relationships. Attackers use this information to identify exploitable services, plan lateral movement paths, establish persistence through trusted VPN connections, and target connected partner networks. This information is so valuable that complete configurations can sell for thousands of dollars on dark web marketplaces.

What's the immediate action I should take if I run FortiGate?

Immediately: (1) Audit all administrative accounts for ones you don't recognize or that were created without your knowledge, (2) Review FortiGate audit logs for unauthorized configuration exports or admin account creations, (3) Enable detailed logging for all administrative actions, (4) Monitor your FortiGate for unusual outbound connections or suspicious activity. Then: (5) Develop a patch strategy—if on 7.4.10, plan to upgrade to 7.4.11 when available, or to 7.6.6 or 8.0.0 if you can handle a larger version upgrade, (6) Implement MFA for all administrative access, (7) Test backups and ensure you have a complete configuration backup.

Can I trust vendor patches after an incomplete fix?

This incident highlights a real concern: vendor patches don't always fully address vulnerabilities, especially when released quickly under pressure. Best practice is to treat major patches with caution. Don't automatically trust that a patch completely solves a problem. Monitor security research and vendor advisories for follow-up patches or reports of bypass techniques. For critical vulnerabilities, consider having a security firm verify that a patch actually works in your specific environment rather than assuming the vendor has fully fixed the issue.

How do I detect if my FortiGate has been compromised?

Look for: (1) Unauthorized admin accounts in your account list, especially those created recently or with generic names, (2) Configuration export events in your audit logs that you didn't initiate, (3) Failed login attempts followed by successful logins from unusual IP addresses, (4) Unusual outbound connections from your FortiGate to external servers, (5) Policy or rule changes that don't match your change management log, (6) Unusual VPN tunnel connections. You'll need to examine FortiGate logs in detail, which often requires specialized log analysis tools or forensic expertise.

Should I wait for the new patch or upgrade to a different version?

If you're on 7.4.10 and can wait a few days for 7.4.11 without excessive risk, wait. However, if you face active threat activity or can't adequately monitor your environment, upgrade to 7.6.6 or 8.0.0 immediately. Major version upgrades carry more risk than minor patches, so test thoroughly in a lab environment first. Consider your organization's risk tolerance and ability to monitor for compromise. High-risk environments should patch immediately even if it means a larger version upgrade.

Are other firewall vendors at risk from similar vulnerabilities?

While this specific vulnerability is specific to Fortinet FortiGate, the underlying pattern is universal. Any complex security appliance, especially those with features like SSO, single sign-on, cloud integration, or VPN capabilities, can have authentication bypass vulnerabilities. Palo Alto Networks, Cisco ASA, Juniper SRX, and other major firewall vendors have all had critical vulnerabilities in similar features. The lesson is that you shouldn't trust any vendor implicitly. Maintain regular patching, audit for compromise, and have robust logging and monitoring.

What should I do if I discover my FortiGate was compromised?

If you discover unauthorized admin accounts or other signs of compromise: (1) Don't panic, but treat it as serious, (2) Isolate the FortiGate if possible or at minimum disable external access, (3) Preserve all logs for forensic analysis, (4) Contact your incident response team and consider hiring external forensics experts, (5) Notify all connected organizations about the compromise so they can check their logs, (6) Perform a complete backup before making changes, (7) Consider performing a factory reset and full reconfiguration rather than trying to patch and remediate, (8) Monitor all connected networks and systems for signs of attacker activity.

How can I reduce my risk from future FortiGate vulnerabilities?

Implement these hardening measures: (1) Disable any features you don't actively use, (2) Implement role-based access control for admin access, (3) Use a separate management network for administrative access, (4) Require MFA for all admin logins, (5) Implement network segmentation using the firewall, (6) Monitor all configuration changes and require approval, (7) Maintain regular backups and test restoration procedures, (8) Subscribe to Fortinet security advisories and monitor their updates closely, (9) Have incident response procedures ready, (10) Consider hiring a managed security service provider to monitor your firewall for suspicious activity.

Key Takeaways

• Fortinet FortiOS 7.4.10 patch doesn't fully fix the SSO vulnerability; new versions 7.4.11, 7.6.6, and 8.0.0 required
• Over 10,000 vulnerable FortiGate endpoints identified globally with active automated attacks underway
• Stolen firewall configurations expose complete network topology, VPN settings, security rules, enabling further compromise
• Organizations must audit admin accounts, review configuration export logs, and monitor for unauthorized access immediately
• Supply chain risk: compromised FortiGates expose connected partner networks, requiring notification and coordinated response
• Future patches should not be blindly trusted; security teams must verify that patches actually remediate vulnerabilities

Related Articles

• Ingram Micro Ransomware Attack: 42,000 Affected, SafePay Claims Responsibility [2025]
• Malicious Chrome Extensions Spoofing Workday & NetSuite [2025]
• Proton VPN Kills Legacy OpenVPN: What You Need to Know [2025]
• Microsoft Teams Brand Spoof Call Warnings: Complete Security Guide [2025]
• Microsoft 365 Outage 2025: What Happened, Why, and How to Prevent It [2025]
• Under Armour 72M Record Data Breach: What Happened [2025]