CISA's required action for CVE-2023-27997 is to apply updates per vendor instructions. In practice, find every instance of Fortinet FortiOS and FortiProxy SSL-VPN 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 “patch or mitigate” means for this CVE in practice
The right response is to treat this as an internet-facing edge appliance issue, not a routine software update. Start by locating every Fortinet VPN appliance security instance that could expose SSL-VPN, then compare each one against the vendor’s remediation path and CISA’s guidance. If a system cannot be patched quickly, the safe interim posture is to remove external reachability or decommission the service until it can be brought back under control.
For internet-facing VPN devices, the operational question is usually not whether the overflow is “patched somewhere,” but whether any reachable instance remains exposed. A partial rollout still leaves a live attack surface if one forgotten gateway, standby unit, or secondary environment is left on the public internet.
Because this flaw was used in the wild, VPN hardening and replacement planning matter as much as the update itself. If the vendor fix requires maintenance windows or service disruption, the security decision should be explicit: patch immediately, isolate the device, or take it out of service.
How to confirm exposure and reduce blast radius
Confirm every FortiOS and FortiProxy instance that offers SSL-VPN, including test systems, secondary portals, and devices behind load balancers or DNS aliases. Then verify which boxes are actually internet reachable, because a device can be “known” to inventory and still remain exposed through a forgotten interface, alternate address, or permissive firewall rule. The CISA Known Exploited Vulnerabilities Catalog is the authoritative reference for why this should be handled urgently.
When immediate patching is not possible, the highest-value containment step is to remove the attack path. That usually means disabling SSL-VPN, restricting source addresses to a tightly controlled administrative range, or placing the service behind stronger access controls while the device is remediated. If the appliance must stay online, reduce what it can reach and who can reach it.
Exposure checks should also include any management interfaces, backup portals, and downstream dependencies that might still trust the device. In edge-device incidents, the real risk is often not one server compromise but a compromised appliance that sits at a trust boundary and can be reused for broader access.
What to check after remediation
After updates or mitigations are in place, review authentication, VPN, and system logs for signs of earlier exploitation. Look for unusual login times, new source geographies, abnormal session durations, configuration changes, or evidence that the appliance was used as a foothold before patching. The State of NHI & AI Agent Breach Report 2026 is a useful reminder that once an edge credential or access path is exposed, attackers often move quickly to persistence and lateral movement.
If you see signs of compromise, treat the device as a potential trust break, not just a patched host. That may require credential rotation for VPN administrators, service accounts, and any secrets that could have been reachable from the appliance, plus session invalidation where the product or surrounding controls support it. The strongest signal is not a single failed login, but a change in what the appliance could reach or authenticate to before remediation.
When you need a broader validation path, pair log review with controlled simulation or detection testing. A Breach and Attack Simulation guide can help teams verify that detection and response controls actually notice abuse paths similar to exploited edge appliances.
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-18 — Penetration Testing | Log review and validation after remediation fit continuous verification of exposure. |
| Recommendation — Validate that the vulnerable VPN path is closed and detectable after remediation. | ||
| NIST CSF 2.0 | PR.PS-01 — Identity Management, Authentication and Access Control | SSL-VPN appliances expose authentication and access paths that must be reduced or removed. |
| Recommendation — Limit or remove exposed VPN access paths until remediation is complete. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The issue requires vendor update application or documented mitigation. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-patch log review is needed to detect signs of prior exploitation. | |
| Recommendation — Apply the vendor fix or approved mitigation to the affected appliance. Review appliance logs for indicators of earlier compromise. | ||
Practitioner Guidance
What to prioritise: Patch the externally reachable appliances first, then confirm that no standby, lab, or forgotten SSL-VPN instance is still exposed. If patching is delayed, containment should be treated as the primary control, not a temporary convenience.
What to verify: Verify the vendor update or mitigation was applied to the exact build in service, and verify logs before and after the change. If the device handled VPN authentication, verify whether any downstream credentials, sessions, or administrative access paths may have been exposed.
Decision rule: If you cannot confidently patch a live internet-facing instance within the required window, remove the service from exposure rather than accept an unbounded risk period. For this class of flaw, “monitor and wait” is usually the weakest acceptable option.
Practitioner takeaway: The real objective is not just closing the overflow, it is making sure no exposed appliance remains a reusable entry point, either before or after the patch.
Related resources from NHI Mgmt Group
- Is CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow) being exploited in the wild?
- CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow)
- How do you patch or mitigate CVE-2018-13379 (Fortinet FortiOS SSL VPN Path Traversal)?
- How do you patch or mitigate CVE-2023-33010 (Zyxel Multiple Firewalls Buffer Overflow)?
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.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org