Fortinet FortiGate Authentication Bypass: CVE-2024-55591 Explained

On January 14, 2025, Fortinet published an advisory for CVE-2024-55591, a critical authentication bypass vulnerability affecting FortiOS versions 7.0.0 through 7.0.16 and FortiProxy versions 7.0.0 through 7.0.19 and 7.2.0 through 7.2.12. The vulnerability carried a CVSS score of 9.6, and for good reason: it allowed remote, unauthenticated attackers to gain super-admin privileges on affected devices.

This was not a theoretical risk. Arctic Wolf reported active exploitation in the wild dating back to at least November 2024, well before the patch was available.

What Happened

The vulnerability existed in the Node.js websocket module of the FortiOS management interface. By sending specially crafted requests to this endpoint, an attacker could bypass authentication entirely and obtain a session token with super-admin privileges.

Arctic Wolf's threat intelligence team observed a campaign that followed a consistent pattern across multiple victim organizations:

1. Reconnaissance scanning of FortiGate management interfaces exposed to the internet (mid-November 2024).
2. Exploitation of CVE-2024-55591 to create new admin accounts or modify existing ones (late November through December 2024).
3. VPN tunnel creation using those compromised admin credentials, establishing persistent access into internal networks.
4. Lateral movement through the victim's environment using the VPN as a foothold.

The attackers were methodical. They created admin accounts with names like forticloud-tech, fortigate-firewall, and adnimistrator (note the deliberate typo) to blend in with legitimate administrative accounts. They also modified firewall policies to allow traffic from their VPN tunnels into internal network segments.

Technical Breakdown

The root cause was an alternative path or channel authentication bypass (CWE-288). The FortiOS management interface exposes a websocket-based API alongside its traditional HTTP-based management interface. The websocket module did not properly validate authentication tokens before granting administrative access.

Here's what made this particularly dangerous:

• No authentication required. The attacker did not need any existing credentials.
• Super-admin privileges. The resulting session had the highest privilege level available, with full read/write access to the device configuration.
• Network-accessible. Any FortiGate with its management interface exposed to the internet was vulnerable.

The affected versions were:

| Product | Affected Versions | Fixed Versions | |---------|------------------|----------------| | FortiOS | 7.0.0 - 7.0.16 | 7.0.17+ | | FortiProxy | 7.0.0 - 7.0.19 | 7.0.20+ | | FortiProxy | 7.2.0 - 7.2.12 | 7.2.13+ |

Importantly, FortiOS 7.2.x, 7.4.x, and 7.6.x branches were not affected. The vulnerability was specific to the 7.0.x branch.

The Exposure Problem

According to Shodan data at the time of disclosure, over 300,000 FortiGate management interfaces were accessible from the internet. Not all of these ran vulnerable versions, but the sheer number of exposed devices highlighted a recurring problem in enterprise security: network appliance management interfaces that should be internal-only are routinely exposed to the public internet.

This is not unique to Fortinet. We see the same pattern with Palo Alto, Cisco, SonicWall, and virtually every other network equipment vendor. The management interface is the keys to the kingdom, and it keeps getting left on the front porch.

Indicators of Compromise

Fortinet and Arctic Wolf published several indicators that defenders could use to detect compromise:

• Unusual admin account creation in FortiGate logs, particularly accounts created outside of normal change windows.
• jsconsole-based login events with suspicious source IPs. The attackers used the jsconsole interface, which normally generates log entries with a source IP of 127.0.0.1. Anomalous entries showed randomized source IPs like 1.1.1.1 or 8.8.8.8.
• SSL VPN tunnel creation from unexpected geographic locations or IP ranges.
• Firewall policy modifications that opened access from VPN address pools to internal networks.

Organizations that could not patch immediately were advised to disable the HTTP/HTTPS management interface or restrict access to trusted IP addresses via local-in policies.

Lessons for Defenders

CVE-2024-55591 reinforced several principles that security teams already know but often struggle to implement:

Minimize management interface exposure. There is rarely a legitimate reason for a firewall's management interface to be accessible from the entire internet. Use out-of-band management networks, VPN-only access, or at minimum IP allowlists.

Monitor for configuration changes. Admin account creation and firewall policy modifications on network appliances should generate alerts. Many organizations treat their firewalls as "set and forget" infrastructure, checking configurations only during planned maintenance windows.

Assume breach timelines are longer than disclosure timelines. The CVE was published in January 2025, but exploitation started in November 2024. The gap between active exploitation and public disclosure is common, and defenders need detection capabilities that don't depend on knowing the specific CVE.

Patch network appliances with urgency. These devices sit at the boundary of your network. A compromised firewall is not just another vulnerable host; it's a position that gives the attacker visibility into and control over all traffic flowing through it.

How Safeguard.sh Helps

Safeguard.sh continuously monitors your software inventory for known vulnerabilities, including those affecting network infrastructure firmware. When CVE-2024-55591 was published, organizations using Safeguard received immediate notifications if FortiOS appeared in their tracked asset inventory.

With Safeguard's SBOM management and vulnerability correlation, you get:

• Automated CVE matching against your deployed software versions, including firmware on network appliances.
• Priority scoring that factors in real-world exploitation status, so actively exploited vulnerabilities like CVE-2024-55591 surface at the top of your remediation queue.
• Compliance tracking that maps vulnerabilities to regulatory requirements, helping you demonstrate due diligence to auditors and regulators.
• Continuous monitoring that catches new disclosures as they happen, not when you get around to checking vendor advisories.

The window between exploitation and patching is where breaches happen. Safeguard.sh helps you close that window.