Patching the Fortinet auth bypass doesn't remove the admin account the attacker added

CVE-2022-40684 was a critical authentication bypass on Fortinet’s administrative interface, CVSS 9.8, mass-exploited within days of disclosure. The mechanism is one we keep seeing: the appliance trusted client-supplied HTTP headers (a crafted Forwarded header plus a specific User-Agent) as proof the request came from a trusted internal source, letting an unauthenticated attacker perform admin operations, the same “a header is not authentication” mistake behind the F5 BIG-IP and TerraMaster bypasses. But the detail that matters most for remediation is what attackers did with that admin access: they added persistence. And persistence survives the patch.

This is a runbook. If your Fortinet gear was exposed and unpatched in late 2022, work it.

What the bug is

CVE-2022-40684 (CWE-288) affects FortiOS, FortiProxy, and FortiSwitchManager, allowing an unauthenticated attacker with access to the management interface to perform administrator operations via specially crafted HTTP/HTTPS requests, per Fortinet advisory FG-IR-22-377. Affected: FortiOS 7.0.0-7.0.6 and 7.2.0-7.2.1, FortiProxy 7.0.x-7.2.0, and FortiSwitchManager 7.0/7.2, fixed in 7.0.7 and 7.2.2. Horizon3 released a PoC on October 13, 2022, and CISA added it to the Known Exploited Vulnerabilities catalog on October 11 with the ransomware flag.

The documented exploitation didn’t stop at “act as admin once.” Attackers used the access to upload an SSH public key (via a PUT to /api/v2/cmdb/system/admin/admin) and to create new super-admin accounts, giving themselves durable, legitimate-looking administrative access to the device. That’s the part the patch doesn’t address.

Step 1 — Patch

• Upgrade FortiOS to 7.0.7 / 7.2.2 or later, FortiProxy and FortiSwitchManager to their fixed builds. This closes the bypass. It does not undo anything done while the device was exposed.

Step 2 — Hunt for attacker-planted persistence

If the management interface was internet-reachable and unpatched (roughly October 2022 onward), assume an attacker may have been admin and check for what they left:

• Unexpected administrator and super-admin accounts. Review the full admin account list and remove any you don’t recognize. New super-admin accounts were a primary persistence mechanism.
• Unrecognized SSH keys. Audit configured SSH public keys for admin accounts and remove any your team didn’t add. An attacker’s key grants ongoing access without a password.
• Configuration changes. Look for modified admin profiles, new or altered local-in policies, changed trusted hosts, and any config that would preserve or widen access. Compare against a known-good configuration if you have one.
• Indicators from Fortinet/CISA. Fortinet published exploitation indicators; check logs for the crafted requests to the admin API endpoints and for the User-Agent strings associated with the exploit.

Step 3 — Lock down the management interface

• Take the admin interface off the internet. The bypass is only reachable by something that can hit the management HTTP/HTTPS interface. Restrict it to a management network, use trusted-hosts allowlisting, and never expose it to the world. This single control would have neutralized the mass-exploitation event for most victims, and it defends against the next appliance auth bypass too.

Step 4 — If you find persistence, treat it as a breach

• A firewall or proxy compromise is serious because of where the device sits and what it can see. If you find rogue admins, keys, or config changes, rotate all device credentials, regenerate keys and certificates, review what traffic and credentials the device could have exposed, and investigate downstream for lateral movement. Consider rebuilding from a known-good configuration rather than trusting cleanup in place.

The lesson

Two things to carry forward. First, the recurring one: an HTTP header is something the client sends, not proof of who the client is, and any appliance that trusts Forwarded, X-Forwarded-For, remote_user, or a User-Agent as authentication is one request away from a bypass. Second, the remediation one, which is the focus here: for any auth-bypass or RCE on a device where attackers can create accounts or add keys, patching is necessary but not sufficient, because the patch removes the vulnerability, not the persistence the attacker established through it. The full remediation is patch, then audit for what they left, then lock down the interface so it can’t happen again. We flag the perimeter-device auth bypasses with this two-step expectation, because the back door an attacker installs while the bug is open outlives the bug itself.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• NVD CVE-2022-40684 — 2022-10
• Fortinet PSIRT FG-IR-22-377 — 2022-10-06
• Rapid7: CVE-2022-40684 remote authentication bypass in Fortinet firewalls, web proxies — 2022-10-07
• Tenable: CVE-2022-40684 critical authentication bypass in FortiOS and FortiProxy — 2022-10