CISA’s required action for CVE-2022-40684 is to apply updates per vendor instructions. In practice, find every instance of Fortinet Multiple Products in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What this CVE means operationally
CVE-2022-40684 is a practical patch-and-exposure problem, not just a software versioning issue. Because it was used in the wild, the immediate question is whether any Fortinet Multiple Products instance is still reachable, whether the vendor update or mitigation can be applied cleanly, and whether you can safely keep the product online while you work through remediation.
The first pass is inventory and scope. Treat every Fortinet appliance or service using the affected product family as potentially exposed until you have confirmed otherwise, especially if it has internet-facing management or admin access. For edge-device style exposure and management-plane hardening, see Edge Device Security Guide.
Do not rely on patching alone if the device was directly reachable from the internet. If the vendor update cannot be applied immediately, the safer interim choice is to remove the exposure path, restrict management access, or take the product out of service until the documented fix or mitigation is in place.
How to mitigate when you cannot patch immediately
The vendor path is the preferred path: apply updates per vendor instructions, then validate that the device is no longer exposed to the attack path that made the bypass possible. If patching is delayed, the mitigation needs to reduce reachability first, because an authentication bypass is most dangerous when the product remains exposed to untrusted networks.
That usually means tightening who can reach management interfaces, removing direct internet exposure, and checking whether any fallback access paths still provide administrative reach. If the device is part of a broader vulnerability handling process, use the Vulnerability Management Guide to keep asset scope, exception handling, and verification aligned.
If you cannot reduce exposure quickly enough, treat the system as a candidate for temporary isolation or service suspension. That is often the least risky option when the affected product is security infrastructure itself, because keeping a compromised edge device online can preserve attacker reach into the rest of the environment.
What to check after remediation
After patching or mitigation, assume the flaw may already have been abused. Review administrative logs, authentication events, configuration changes, and any sign of unexpected account creation, new admin access, or unusual remote sessions around the exposure window. Because this issue was exploited in the wild, post-fix validation should include compromise checks, not only service restoration.
Look for evidence that the device was used as an initial foothold, then follow the trail outward. On appliances and other perimeter systems, the important question is whether the attacker used the bypass to change configuration, create persistence, or pivot into adjacent systems. The practical lesson from exploited edge-device cases is that authentication bypass often becomes a control-plane compromise, not a single isolated login event.
If logs are limited, preserve what you have before making further changes. A device that has been patched but not investigated can still leave you blind to prior access, and that blind spot matters when the product sits at the boundary between the internet and internal services.
Risk and Threat Considerations
An authentication bypass on an internet-facing security appliance creates immediate exposure because it can turn a trusted control point into an untrusted entry point. The main risk is not only unauthorised access, but also silent administrative control, policy tampering, or downstream access into internal systems that were assumed to be protected by the appliance.
Failure mechanism: The flaw allows attacker access without the expected authentication barrier, so exposure is highest where management interfaces or administrative paths remain reachable from untrusted networks, or where the device was left online while remediation was pending.
Impact: Attackers can alter configuration, persist on the device, inspect traffic, or use the appliance as a launch point for broader compromise. If the device handled privileged access or security enforcement, the blast radius can extend well beyond the appliance itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST SP 800-53 Rev 5 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 | CVE mitigation requires inventory, prioritisation, patching and verification. |
| Recommendation — Track affected Fortinet assets, prioritize remediation, and verify exposure is removed. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The question is about applying vendor fixes and mitigations for a known flaw. |
| RA-5 — Vulnerability Monitoring and Scanning | Finding all exposed instances and validating remediation requires vulnerability visibility. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-patch review of logs is needed to look for signs of prior exploitation. | |
| Recommendation — Apply vendor updates or mitigations and confirm the flaw is remediated. Scan for all exposed instances and recheck them after remediation. Review logs and alert data for evidence of prior compromise after remediation. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of Technical Vulnerabilities | The subject is about applying vendor patches and mitigations for a known vulnerability. |
| Recommendation — Manage the vulnerability through vendor updates, compensating controls, and verification. | ||
Practitioner Guidance
What to prioritise: Patch or isolate the most exposed Fortinet instances first, starting with any device that has a management interface reachable from the internet or from a broad internal network segment. Exposure is a stronger priority signal here than asset criticality alone.
What to verify: Confirm that the vendor update or mitigation actually removed the reachable attack path, not just that the package version changed. Then verify administrative access, config integrity, and whether the device has unexpected accounts, rules, or remote sessions.
Decision rule: If you cannot confirm clean remediation quickly, keep the product offline or tightly segmented until you can. For this class of flaw, continued exposure is often riskier than temporary service disruption.
Practitioner takeaway: Treat this as both a patching task and an incident-response check. The right outcome is not simply “fixed,” but “no longer reachable, no longer trusted blindly, and no longer showing signs of earlier use.”
Related resources from NHI Mgmt Group
- Is CVE-2022-40684 (Fortinet Multiple Products Authentication Bypass) being exploited in the wild?
- CVE-2022-40684 (Fortinet Multiple Products Authentication Bypass)
- How do you patch or mitigate CVE-2022-1040 (Sophos Firewall Authentication Bypass)?
- How do you patch or mitigate CVE-2025-59718 (Fortinet Multiple Products Improper Verification of Cryptographic Signature)?