Is CVE-2024-55591 (Fortinet FortiOS and FortiProxy Authentication Bypass) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2024-55591 to its Known Exploited Vulnerabilities catalogue on 14 January 2025, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Fortinet FortiOS and FortiProxy contain an authentication bypass vulnerability that may allow an unauthenticated, remote attacker to gain super-admin privileges via crafted requests to Node.js websocket module.

What the KEV listing means for exploitation status

CISA’s KEV catalogue is not a theoretical watchlist. When a CVE appears there, the question changes from “could this be abused?” to “assume it is already being used and verify whether you are exposed.” For this Fortinet issue, the practical reading is that exploitation is credible enough to drive immediate response, not routine patch-cycle planning.

Because the vulnerability is in internet-facing security appliances, the first task is scope confirmation. Identify every FortiOS and FortiProxy instance, especially those reachable from untrusted networks or used as remote access gateways, and determine whether any management or authentication paths are exposed in ways that make the bypass reachable.

To follow the authoritative record, use the CISA Known Exploited Vulnerabilities Catalog for exploitation status and remediation expectations, and the CVE Program entry plus vendor advisory for the exact product scope and fix instructions.

Why authentication bypass on perimeter appliances is high impact

An authentication bypass on a perimeter or VPN appliance is especially serious because the device often sits at a trust boundary. If an attacker can reach the vulnerable path, they may skip normal authentication controls and move directly into privileged administrative functions, which can expose the wider environment rather than just the appliance itself.

That is why appliance vulnerabilities are often treated as access events, not just software defects. A successful bypass can lead to session creation, administrative configuration changes, account creation, log tampering, or pivoting into internal systems that were assumed to be protected by the gateway.

For readers who want a broader handling model for exposed appliance issues, NHIMG’s Edge Device Security Guide covers the same operational pattern: internet-facing management surfaces, exposed credentials, logging minimums and the need to treat edge devices as high-value access points.

The same trust-boundary logic appears in incident writeups such as CitrixBleed 2 2025, where appliance compromise translated into session theft and downstream account abuse rather than a narrow device-only issue.

How to respond when patching cannot happen immediately

If the vendor fix is not yet applied everywhere, reduce exposure first. Remove direct internet exposure where possible, restrict administrative access to known source addresses, disable unnecessary management interfaces, and monitor for abnormal login, configuration, or websocket activity against the appliance.

Do not wait for proof of compromise before tightening control. For KEV-listed issues, the safer assumption is that exploitation may already be in progress somewhere in the fleet, so containment and validation need to run in parallel with patching or mitigation.

Use the NIST National Vulnerability Database for the canonical CVE record, and check the FIRST EPSS signal as a prioritisation input, not as a substitute for KEV status or active-exploitation evidence.

Where possible, inspect logs for unusual administrative sessions, configuration writes, new local accounts, policy changes, or connections that arrive from unexpected geographies or hosting providers. If the appliance may have been reachable before containment, treat credentials and sessions tied to it as potentially exposed and review whether any downstream access tokens or administrative secrets need rotation.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The subject is an actively exploited CVE requiring rapid prioritisation and remediation.
Recommendation — Prioritise and remediate this KEV-listed flaw through continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A known exploited vulnerability on perimeter appliances requires prompt remediation and verification.
	AC-6 — Least Privilege	An authentication bypass can expose overly broad administrative privilege on the appliance.
Recommendation — Apply flaw remediation and verify the appliance is patched or mitigated. Restrict administrative privilege on exposed appliance management paths.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	This is a technical vulnerability with active exploitation and required remediation.
Recommendation — Track, prioritise and remediate the exploited vulnerability under technical vulnerability management.
OWASP ASVS	V6 — Authentication	The flaw is an authentication bypass, so authentication assurance is directly implicated.
Recommendation — Reassess authentication assumptions and harden the bypassable login path.

Practitioner Guidance

What to prioritise: Triage by exposure, not by asset criticality alone. A FortiOS or FortiProxy instance that is publicly reachable and administratively privileged deserves faster action than a less exposed instance even if both are technically affected.

What to verify: Confirm whether the vulnerable path is reachable from the internet, whether administrative functions were used during the exposure window, and whether any account, session or configuration changes occurred that do not match normal change control.

Decision rule: If you cannot patch immediately, treat the device as a high-risk access boundary and apply compensating restrictions first. If you find signs of misuse, escalate to compromise assessment and credential review rather than limiting the response to software remediation.

Practitioner takeaway: For KEV-listed appliance flaws, the key question is not whether a patch exists, but whether the device has already become a trusted path into the network; that determines whether you are doing vulnerability management or incident response.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org