What breaks and who should care
If your network relies on Fortinet FortiOS or FortiProxy, an unauthenticated attacker can now bypass authentication and obtain super‑admin rights. The flaw is rated 9.8 on the CVSS scale – that’s critical. Any organisation that runs these products in production, especially those exposed to the internet or untrusted networks, needs to treat this as an emergency.
For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.
Why it matters
The vulnerability allows a remote party to send specially crafted requests to the Node.js websocket module built into the appliance. Those requests trick the software into thinking the attacker is already authenticated, granting them full administrative control. With super‑admin privileges the attacker can change firewall policies, exfiltrate data, or install ransomware – and the CISA catalogue confirms that ransomware groups have already used this flaw in the wild.
How the bug works
At its core this is an authentication bypass. The product uses a Node.js based websocket service for management traffic. The service checks a token that should have been set after a successful login. A flaw in the token validation logic means that an attacker can supply a token of their own design, and the service accepts it as valid. Once the service believes the request is coming from an authenticated admin, it hands over the full control plane.
The exact code path and the precise request format have not been published by Fortinet or the security community. That means you won’t find a detailed packet dump in public advisories. What we do know is that the vulnerability is triggered by a single HTTP‑upgrade request that upgrades the connection to a websocket, followed by a malformed authentication frame. The frame contains a token that bypasses the normal login flow.
Because the vulnerable component is part of the management interface, any network that allows unauthenticated access to that interface – even indirectly via a jump host – is at risk. The impact is total compromise of the device.
How to know if you’re exposed
First, confirm you are running FortiOS or FortiProxy. Both appliances expose a version string via the CLI. Run one of the following commands on the device:
get system statusshow system info
The output will include a line that reads something like Version: X.Y.Z. Compare that version against the table below. If your version falls in the range marked as vulnerable, you are exposed.
If you manage the device through a central FortiManager, you can also pull the version information from the manager’s inventory view. Look for the same version field under each managed device.
What you can do right now
The vendor has released patched releases for each affected branch. The simplest and safest remediation is to upgrade to the patched release for your branch – see the table below for the exact point at which the fix was applied.
Upgrade steps differ slightly between FortiOS and FortiProxy, but the general process is:
- Back up the current configuration (
execute backup config). - Download the appropriate firmware image from the Fortinet support portal.
- Upload the image to the device (
execute restore imageor via the web UI). - Reboot the appliance and verify the new version with the commands above.
After the upgrade, confirm that the version displayed is no longer in the vulnerable range. Then run a quick sanity check: try to access the management UI from an unauthenticated source. You should be denied.
If you cannot upgrade immediately
Some organisations cannot apply a firmware upgrade right away – perhaps because they are in a change‑window or because the upgrade path requires a major version jump. In those cases you must apply mitigations to reduce the attack surface.
- Restrict access to the management interface. Use firewall rules or ACLs to allow only trusted IP ranges (for example, your internal management subnet) to reach the device’s HTTPS/SSH ports.
- Disable the websocket service if you do not use it. Fortinet provides a CLI knob to turn off the websocket listener. The exact command is documented in the release notes – look for a setting called
set ws-service disableor similar. - Enforce strong network segmentation. Place the appliance in a zone that is not directly reachable from the internet. If you must expose it, put a reverse proxy or VPN in front of it.
- Monitor for suspicious activity. Enable logging of all management‑plane connections and set up alerts for any unauthenticated attempts to the websocket endpoint (usually port 443 with an HTTP Upgrade header).
These mitigations do not eliminate the flaw, but they make it much harder for an attacker to reach the vulnerable code path.
If a patch is unavailable for your specific deployment
In rare cases a particular hardware model or custom build may not have a patched firmware yet. CISA’s guidance in that situation is clear: either apply the vendor‑provided mitigations or discontinue use of the product until a fix is available. Discontinuing use could mean moving the device to an air‑gapped environment, or replacing it with a different firewall solution.
Document your decision, keep evidence of the mitigations you have applied, and schedule a review for when the next patch cycle arrives.
What to do after you’ve remediated
Once the device is patched or mitigated, run a quick verification scan with your vulnerability scanner. The CVE should now be reported as “fixed”. Also, rotate any super‑admin credentials that were in use before the patch – an attacker who may have already obtained them could still use them after the fix.
Finally, update your incident‑response playbooks. Include a step that checks for this specific vulnerability whenever a new FortiOS/FortiProxy version is deployed. That way you won’t be caught off guard the next time a critical flaw appears.
Summary
CVE-2024-55591 is a critical authentication bypass that lets an unauthenticated remote attacker become a super‑admin on FortiOS and FortiProxy. It has been confirmed in the wild and is being used by ransomware operators. If your device version appears in the vulnerable range in the table below, you must act now. The recommended fix is to upgrade to the patched release for your branch. If you cannot upgrade, lock down the management interface, disable the websocket service, and monitor closely. If no patch exists for your hardware, consider taking the device out of production until a fix is released.
Time is of the essence. The longer the vulnerable device stays online, the greater the chance an attacker will exploit it. Follow the steps above, verify the remediation, and you’ll have closed a critical gap in your security posture.
Affected versions
Straight from the NVD record for CVE-2024-55591. If your build is inside one of these ranges, treat it as vulnerable.
| Product | Affected range | Fixed in |
|---|---|---|
fortiproxy |
7.0.0 up to 7.0.20 | 7.0.20 |
fortiproxy |
7.2.0 up to 7.2.13 | 7.2.13 |
fortios |
7.0.0 up to 7.0.17 | 7.0.17 |
