Is CVE-2022-40684 (Fortinet Multiple Products Authentication Bypass) being exploited in the wild?

Yes. CISA added CVE-2022-40684 to its Known Exploited Vulnerabilities catalogue on 11 October 2022, 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, FortiProxy, and FortiSwitchManager contain an authentication bypass vulnerability that could allow an unauthenticated attacker to perform operations on the administrative interface via specially crafted HTTP or HTTPS requests.

What “being exploited in the wild” means for CVE-2022-40684

For this CVE, the practical question is not whether the flaw exists, but whether there is reliable evidence that attackers are already using it against real environments. Once CISA places a vulnerability in the KEV catalogue, it is a strong operational signal that exposure is active and that internet-facing management paths need immediate attention, not routine backlog treatment.

That matters here because the vulnerable products are edge and management components, where administrative access is often reachable over HTTP or HTTPS and where a bypass can turn a perimeter device into an entry point for broader compromise. For administrators, the first task is to confirm where these products are deployed, how they are exposed, and whether any management interface is reachable from untrusted networks.

The most useful confirmation step is to treat KEV inclusion as a prompt to validate asset inventory and management-plane exposure, then compare that inventory against vendor guidance. If the affected product is present and reachable, the issue should be handled as an active-threat condition rather than a theoretical advisory.

Why this vulnerability is operationally urgent

An authentication bypass on a management interface is high-value to attackers because it can remove the normal barrier between an external request and administrative actions. In edge-device contexts, that often means a single exposed interface can become the bridge into routing, proxying, filtering, or policy functions that sit near the trust boundary.

This is also the kind of flaw that can be used quickly. Attackers do not need credentials if the bypass succeeds, and they can often test exposure with a small number of crafted requests. That makes internet-facing deployments especially sensitive, since scanning and exploitation can occur before teams finish their normal change window.

For that reason, this class of issue is usually handled as both a vulnerability-management problem and a perimeter-trust problem. NHI Management Group’s Edge Device Security Guide is useful here because it frames management exposure, logging minimums, and hardening for internet-facing appliances as a single operational problem, which is exactly how these incidents tend to play out.

What practitioners should do before and after remediation

Start by identifying every instance of the affected Fortinet products, then verify whether management interfaces are exposed to the internet or to broad internal networks. If patching or mitigation must wait, reduce exposure immediately by restricting access paths, tightening administrative network reachability, and increasing monitoring for unusual administrative requests.

If there is any sign the device has already been reachable from untrusted networks, check for earlier compromise rather than assuming the absence of obvious alerts means safety. Focus on administrative actions, configuration drift, new local accounts, unexpected policy changes, and suspicious login or request patterns around the management plane.

For active exploitation events, use vendor and CISA guidance as the source of truth for version-specific remediation, then validate that the fix actually removes exposure rather than simply reducing it. NHI Management Group’s Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide are useful for the response sequence: triage, emergency mitigation, compromise assessment, and post-patch verification.

Risk and Threat Considerations

Edge and management-plane vulnerabilities are attractive because they can convert a single exposed interface into administrative control, persistence, or a staging point for later movement. When a flaw is already in KEV and linked to ransomware activity, the risk shifts from possible compromise to likely opportunistic targeting.

Failure mechanism: An attacker sends crafted HTTP or HTTPS requests to the administrative interface, bypasses authentication, and uses the resulting privileged access to alter configuration, inspect the environment, or establish footholds before defenders notice.

Impact: Exposure can include configuration tampering, service disruption, unauthorized administrative changes, and downstream compromise of adjacent systems that trust the edge device or rely on its policy decisions.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires prioritised vuln handling and exposure verification.
Recommendation — Prioritize and verify remediation for actively exploited vulnerabilities in exposed assets.
NIST CSF 2.0	DE.CM-01 — Networks and network services are monitored to find potentially adverse events	Exposed management interfaces need monitoring for suspicious administrative activity.
	RS.MA-1 — Incidents are contained	If exploitation is suspected, containment should begin before deeper analysis.
Recommendation — Monitor management-plane traffic and alert on anomalous admin requests. Contain affected devices quickly to limit further attacker activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	KEV-listed flaws require prompt remediation and verification on affected products.
	AC-17 — Remote Access	Management access restrictions are central when an admin interface is exposed.
Recommendation — Remediate the flaw quickly and confirm the fix removes exposure. Restrict remote administrative access to approved networks and paths.

Practitioner Guidance

What to prioritise: Treat external management exposure as the first-order risk. If the device can be reached from the internet or from networks you do not control tightly, prioritize containment and exposure reduction before deeper forensic work.

What to verify: Confirm asset ownership, product family, management reachability, and whether any administrative requests or config changes occurred before remediation. Use logs and configuration history to decide whether you need a compromise investigation, not just a patch cycle.

Decision rule: If the vulnerable interface is reachable and remediation cannot be applied immediately, place the device into a narrower trust zone, restrict administration to known paths, and treat the system as higher risk until you can prove it is not being abused.

Practitioner takeaway: KEV inclusion means this should be handled as an active exploitation problem, not a normal vulnerability ticket, and the most important judgement is whether the management plane was exposed long enough for attacker activity to matter.