Is CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow) being exploited in the wild?

What “exploited in the wild” means for this Fortinet CVE

For a vulnerability like CVE-2023-27997, the practical question is not whether the flaw exists, but whether defenders should treat it as an active intrusion path. CISA’s KEV listing is the clearest public signal for that, because it reflects evidence of real exploitation rather than theoretical risk. For exposure triage, that is more useful than waiting for a broader industry consensus.

In operational terms, “being exploited in the wild” means you should assume some environments may already have been probed, weaponised requests may already exist, and delayed remediation can turn a known vulnerability into a live access route. The issue is especially material on internet-facing SSL-VPN services, where attackers can reach the vulnerable path without prior credentials.

Why this vulnerability is high priority for edge-device response

The attack surface here is the remote access tier, which often sits outside normal application hardening and can become a trusted entry point into internal systems. A heap-based buffer overflow on a VPN edge device matters because successful exploitation can convert a perimeter service into code execution or command execution, which is usually more consequential than a routine service crash.

Because VPN appliances concentrate authentication, session handling, and network reachability, compromise can create a broad blast radius. If the device also brokers access for admins, vendors, or privileged users, a single exploited endpoint can expose far more than the appliance itself. The most relevant reader action is to treat VPN appliance security as a dedicated control surface, not as a standard server patching problem.

When exploit activity is confirmed, the correct framing is incident response plus vulnerability management. That means checking whether the vulnerable service is externally reachable, whether mitigation can be applied immediately, and whether there is any sign of prior access or post-exploitation activity on the appliance or adjacent systems.

What to do when patching or mitigation is delayed

If immediate remediation is not possible, reduce exposure first. Restrict access to the SSL-VPN service, apply vendor guidance and compensating controls, and remove any unnecessary remote access paths until the device is no longer directly exposed. For internet-facing appliances, temporary exposure reduction is often more effective than waiting for a maintenance window while the exploit remains reachable.

Use the vulnerability as a trigger to review adjacent credentials and sessions that the appliance may protect or broker. If the device handled privileged access, assume the compromise window may extend beyond the vulnerable process itself and verify whether administrative accounts, active VPN sessions, or downstream systems need review. That is why remote access identity controls belong in the response even when the CVE itself is a memory corruption issue.

After remediation, validate that the appliance is not only patched but also clean. Look for unusual configuration changes, unexpected accounts, abnormal logins, new tunnels, or signs that the device was used as a foothold for later movement. The “fixed” state is only credible if exposure, exploitability, and compromise checks have all been closed.

Risk and Threat Considerations

This CVE is high risk because active exploitation turns a perimeter vulnerability into a live intrusion path. On VPN and edge devices, attackers often aim for initial access, credential theft, or a foothold that can be reused for lateral movement, which makes delayed response materially more dangerous than with an ordinary application bug.

Failure mechanism: A heap-based buffer overflow on an externally reachable SSL-VPN service can allow crafted requests to trigger code or command execution, bypassing the trust organisations place in remote access infrastructure.

Impact: Successful exploitation can expose the appliance, nearby credentials, and the internal network segment it fronts, creating a path to persistence, data access, or broader compromise.

Practitioner Guidance

What to verify: Confirm whether the vulnerable FortiOS or FortiProxy SSL-VPN service is internet-facing, whether CISA KEV remediation has been applied, and whether your monitoring covers the appliance’s logs, admin events, and authentication records.

Decision rule: If the appliance provides privileged or broad internal access, treat any credible exposure as urgent containment work, not routine patch scheduling. If patching must wait, narrow exposure first and then assess compromise before returning the service to normal trust.

Practitioner takeaway: For a KEV-listed VPN flaw, the priority is not just fixing the bug, it is proving the appliance was not already used as an entry point.

Related resources from NHI Mgmt Group

• CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow)
• CVE-2022-42475 (Fortinet FortiOS Heap-Based Buffer Overflow)
• Is CVE-2023-33009 (Zyxel Multiple Firewalls Buffer Overflow) being exploited in the wild?
• Is CVE-2023-33010 (Zyxel Multiple Firewalls Buffer Overflow) being exploited in the wild?