JSTGTECH
← Back to blog

CVE-2024-21762: FortiOS RCE that needed no login at all

4 min read

Edge VPN appliances keep landing on this blog for the same reason they keep landing on CISA’s Known Exploited Vulnerabilities list: they sit on the internet by design, and a memory-safety bug there skips every access control behind it. CVE-2024-21762 is one of the starkest versions of that pattern — an out-of-bounds write in FortiOS’s sslvpnd process that let a completely unauthenticated attacker send one crafted HTTP request and get arbitrary code execution as root, no credentials, no session token, no prior foothold required (Fortinet PSIRT).

Root cause

The bug lives in how sslvpnd parses HTTP requests with chunked transfer encoding. By manipulating the declared size of a chunk, an attacker can make the daemon write attacker-controlled data past the end of the buffer it allocated for that chunk — a classic heap out-of-bounds write, rated CVSSv3 9.6 (Tenable). Because sslvpnd handles the request before any authentication check runs — its entire job is to be the thing an unauthenticated remote user talks to first — the corrupted memory is reachable pre-auth, and Fortinet’s own advisory confirms exploitation “via specially crafted HTTP requests” with no login step involved.

What makes this a worse bug than a typical memory-safety issue is where it runs: sslvpnd operates with root privileges on the appliance. A heap corruption that on most software might crash a sandboxed worker process instead hands the attacker full control of the security device itself — the same box terminating VPN sessions, holding routing and firewall configuration, and often trusted as a clean jump point into the internal network it’s supposed to be guarding.

Blast radius

Fortinet disclosed CVE-2024-21762 on February 8, 2024, warning it was “potentially” already being exploited; CISA added it to the KEV catalog the very next day, February 9, based on evidence of active exploitation (Tenable). Shadowserver’s internet-wide scans found roughly 150,000 FortiOS/ FortiProxy devices still exposed to the bug immediately after disclosure — a number that only dropped to about 133,000 ten days later, meaning the overwhelming majority of vulnerable appliances were still sitting unpatched on the public internet a week and a half after a KEV-listed, actively-exploited RCE became public knowledge (The Register). Asia accounted for the largest share of exposure, with North America and Europe not far behind. By mid-March a working exploit was for sale on a hacker forum, and researchers began observing exploitation attempts and callback traffic from opportunistic scanners well beyond whatever targeted activity preceded disclosure (SOCRadar).

This CVE also sits inside a longer, uglier pattern for the same vendor: the PRC state-sponsored group CISA and partners track as Volt Typhoon confirmed initial access into a US critical-infrastructure target through a different, earlier FortiGate SSL-VPN bug, CVE-2022-42475, which similarly gave pre-auth code execution on an unpatched perimeter firewall (CISA AA24-038A). Volt Typhoon’s whole operating model is to get in through exactly this class of edge-device bug and then live off the land — no malware, just built-in admin tools — specifically because it blends into normal traffic and evades detection built around file-based indicators. Two separate root causes, same vendor, same device category, same attacker calculus: unauthenticated RCE on the network perimeter is worth stockpiling and reusing.

Remediation

Patch to a fixed build — FortiOS 7.4.3, 7.2.7, 7.0.14, 6.4.15, 6.2.16 or later, and the corresponding FortiProxy releases — and do it before worrying about anything else, since this bug requires no interaction with an authenticated user to exploit. Fortinet’s advisory is explicit that disabling webmode is not a valid workaround; the only workaround that actually removes the attack surface is disabling SSL-VPN entirely on any device you can’t patch immediately.

Past that, treat internet-facing SSL-VPN daemons as a standing liability rather than a set-and-forget service. Restrict management and SSL-VPN access with source-IP allow-lists where your user base permits it, put the appliance’s admin plane behind an out-of-band network rather than the same interface serving VPN clients, and subscribe to vendor PSIRT advisories directly rather than relying on patch-cycle habits — a device that’s exploitable pre-auth doesn’t give you the luxury of a normal patch window. If you run Fortinet gear, also check for indicators of compromise predating your patch: this class of bug is routinely exploited before public disclosure, and a clean patch does nothing to evict an attacker who already has a root shell and persistence.

The bigger lesson

CVE-2024-21762 is what happens when a device explicitly designed to be internet-reachable and pre-authentication-facing has a memory-safety bug in exactly the code path that has to run before any access control does. There’s no clever chained attack here and no social engineering — the entire vulnerability class is “the thing you can’t avoid exposing to the internet has a bug in the part that runs before login.” That means the fleet-wide exposure numbers matter as much as the CVSS score: a 9.6 that stays unpatched for a week and a half on 130,000-plus devices is a bigger real-world risk than a 9.8 that gets patched same-day. Track your edge-appliance patch SLA against KEV due dates, not against your normal change-management cadence, because attackers are already scanning for the build number before most fleets have finished their change ticket.

Related posts