On February 8, 2024, Fortinet disclosed CVE-2024-21762, an out-of-bounds write in the FortiOS SSL VPN component (sslvpnd) that permits unauthenticated remote code execution via a crafted HTTP request. The advisory carried a CVSS of 9.6, and Fortinet's own language was unusual: "potentially being exploited in the wild." CISA added the CVE to the Known Exploited Vulnerabilities catalog the next day, and the Dutch Military Intelligence and Security Service (MIVD) soon tied earlier exploitation to a PRC-linked actor that had used similar FortiGate zero-days to compromise a Dutch Ministry of Defence network in 2023. FortiGate devices sit on the perimeter of tens of thousands of organizations and are the first hop for a large share of remote workers, which makes any pre-auth RCE in SSL VPN a Tier 1 incident. This post maps the exploitation timeline, the scanner patterns we observed, and the remediation moves that actually shrank exposure.
What exactly does CVE-2024-21762 let an attacker do?
CVE-2024-21762 is an out-of-bounds write in the SSL VPN web component that an unauthenticated remote attacker can trigger with a specially crafted HTTP request, leading to arbitrary code execution as the SSL VPN process. The bug lives in memory management for chunked HTTP request bodies; researchers at Assetnote and watchTowr later published technical write-ups showing how the flaw can be chained into a write-what-where primitive. Because SSL VPN runs with elevated privileges on the FortiGate, successful exploitation yields access to VPN session state, captive portal configuration, and enough filesystem reach to stage persistence before credentials can be rotated.
Which FortiOS versions are affected and which are fixed?
FortiOS 7.4.0 through 7.4.2, 7.2.0 through 7.2.6, 7.0.0 through 7.0.13, 6.4.0 through 6.4.14, and 6.2.0 through 6.2.15 are affected, as are FortiProxy 7.4.0 through 7.4.2, 7.2.0 through 7.2.8, 7.0.0 through 7.0.14, 2.0.0 through 2.0.13, and the 1.x branch. Fortinet's PSIRT advisory FG-IR-24-015 lists fixed builds 7.4.3, 7.2.7, 7.0.14, 6.4.15, and 6.2.16. Crucially, end-of-engineering-support FortiOS 6.0.x and 5.6.x did not receive fixes and should be assumed permanently vulnerable. Fortinet also backported fixes to FortiOS-6K7K builds used on large chassis.
What did exploitation look like in the wild?
Exploitation began with mass internet-wide scanning within 48 hours of disclosure, and by mid-February targeted post-exploitation activity was showing up in incident response cases. The Shadowserver Foundation reported roughly 150,000 FortiGate SSL VPN instances exposed to the internet when the advisory dropped, most running affected versions. GreyNoise saw scanning spikes on February 9 and 10 probing /remote/login and /remote/logincheck with malformed chunked bodies. In parallel, the Dutch MIVD published details of the CoatHanger implant — a persistent ELF backdoor installed on FortiGates that survived firmware upgrades by patching the firmware rootfs on boot. CoatHanger was tied to earlier Fortinet zero-days but the tradecraft lifted directly into 21762 campaigns.
How did CISA and national agencies respond?
CISA added CVE-2024-21762 to the KEV catalog on February 9, 2024 with a three-week remediation deadline for federal civilian agencies, and allied CERTs issued parallel advisories through February. BOD 22-01 obligated FCEB agencies to patch or remove affected devices from networks by March 1. The UK NCSC, Canadian Centre for Cyber Security, and Australian Signals Directorate's ACSC all published guidance linking the CVE to nation-state tradecraft and recommending credential rotation on any FortiGate that had been exposed during the exploitation window. The consistent message: treat any exposed, unpatched FortiGate as compromised and hunt for post-exploitation artifacts rather than assuming a clean patch is sufficient.
What mitigations actually worked before a patch could be applied?
The only real pre-patch mitigation was disabling the SSL VPN web service, because IPS signatures released in the following days were evaded by minor request variants. Fortinet's workaround — config vpn ssl settings; unset source-interface; end — effectively shuts off the listener, which breaks remote access but eliminates the attack surface. Organizations that could not disable SSL VPN rolled IP allowlists at upstream firewalls or cloud front doors and audited fnsysctl logs for the crash signatures associated with exploitation. Postmortems in our incident response data showed that organizations that disabled SSL VPN for 24 hours during patching saw zero successful exploitation, while those relying solely on IPS saw a non-zero false-negative rate during the first week.
What does hunting for post-exploitation look like?
Hunting begins with firmware integrity checks and goes through to outbound connection analysis, because CoatHanger persists in the firmware image itself. Operators should pull the boot image hash and compare against Fortinet's published hashes, inspect diagnose sys flash list for unexpected entries, and check diagnose debug crashlog read for the SSL VPN crash pattern associated with the OOB write. On the network, look for outbound TLS to low-reputation IPs from the FortiGate's management plane during the exposure window. Credential hunting is the other half: any AD accounts that authenticated through SSL VPN during the exposure window should be treated as potentially compromised, including service accounts used for SAML federation.
# Minimum triage steps
diagnose sys flash list
diagnose debug crashlog read | grep -i sslvpnd
execute ssh-certificate export admin
How Safeguard Helps
Safeguard maps FortiGate appliances as first-class assets in your supply chain graph and cross-references running firmware versions against the FG-IR-24-015 advisory, so reachability analysis shows which identities and internal systems are downstream of an exposed VPN concentrator. Griffin AI correlates CoatHanger indicators with your firmware telemetry and outbound flow data, calling out likely compromise before signature-based tooling catches up. SBOM and component inventories for FortiOS track every affected build across the 6.2, 6.4, 7.0, 7.2, and 7.4 trees, and policy gates block deployments that depend on tenants still exposing vulnerable SSL VPN. TPRM assessments flag upstream vendors and managed service providers operating affected appliances so you know which partners need evidence of remediation.