CVE-2022-42475: How to Fix the FortiOS SSL-VPN Heap Overflow (FG-IR-22-398)

CVE-2022-42475 is a critical heap-based buffer overflow in the FortiOS and FortiProxy SSL-VPN daemon (sslvpnd) that lets an unauthenticated remote attacker run code on the device. It has been exploited in the wild. Fix it by upgrading FortiOS to 6.0.16, 6.2.12, 6.4.11, 7.0.9, 7.2.3 or later, then check the device for Fortinet’s published indicators of compromise.

Fortinet tracks the issue as FG-IR-22-398. The only workaround in the advisory is to disable SSL-VPN.

What the scanner is actually detecting

In Nessus the finding is titled Fortinet Fortigate Heap-based buffer overflow in sslvpnd (FG-IR-22-398), plugin ID 168637, in the Firewalls family, published December 12, 2022. Tenable states that Nessus has not tested for the flaw and relies only on the version the device reports. Three details matter:

• It is a paranoid check. The plugin requires the Settings/ParanoidReport knowledge base item, so it only reports when the scan policy’s report paranoia is set to Paranoid. A default scan will not show it.
• It does not check SSL-VPN. The bug lives in sslvpnd, but the plugin only compares the FortiOS version (Host/Fortigate/version) against the affected ranges. It cannot tell whether SSL-VPN is enabled or reachable.
• It targets FortiGate. FortiProxy appliances are also affected per the advisory, so check them against the advisory table.

Real-world risk

This finding deserves its rating. Fortinet scores it 9.3 (CVSSv3) and Tenable lists 9.8: network reachable, no authentication, code execution. When Fortinet published the advisory it said it was aware of an instance of in-the-wild exploitation, and CISA added the CVE to the Known Exploited Vulnerabilities catalog with a due date of January 3, 2023 (our explainer on the CISA KEV catalog covers what that listing means for patch deadlines).

Fortinet’s January 2023 analysis described an advanced actor with a preference for government or government-related targets. The implant replaced IPS engine components with trojanized versions and patched FortiOS logging processes to hide its activity, so a clean event log is not proof of a clean device. In April 2025 Fortinet also reported that attackers who had exploited this and later SSL-VPN flaws (CVE-2023-27997 and CVE-2024-21762) left a symbolic link in the folder that serves SSL-VPN language files. That link kept read-only access to the file system, including configuration, after the original holes were patched.

For balance: exploitation needs SSL-VPN (web or tunnel mode) listening on an interface the attacker can reach. A FortiGate that has never had SSL-VPN enabled is not exposed through this bug. An affected device with SSL-VPN facing the internet is an emergency, and it very likely carries the later SSL-VPN CVEs too.

How to confirm it on the FortiGate

Check the version and whether SSL-VPN is running

From the CLI, read the Version line:

get system status

Then check whether the SSL-VPN daemon is running and which interface it listens on. A process ID in the output of the second command means sslvpnd is active:

show vpn ssl settings
diagnose sys process pidof sslvpnd

Check for the FG-IR-22-398 indicators of compromise

Fortinet’s technical tip lists these commands, which require an administrator with the super_admin profile:

diagnose debug crashlog read
fnsysctl ls -l /data/lib
fnsysctl ls -la /var
fnsysctl ls -l /data/etc
fnsysctl ls -l /

What to look for:

• Repeated sslvpnd crashes with Signal 11 in the crash log, or event log entries with Logdesc=”Application crashed” and application:sslvpnd. Search system event logs on the FortiGate or FortiAnalyzer.
• /data/lib/libips.bak, libgif.so, libiptcp.so, libipudp.so or libjepg.so in /data/lib.
• /var/.sslvpnconfigbk, /data/etc/wxd.conf, or an unexpected /flash entry at the root.
• Connections from the FortiGate itself to the IP addresses listed in the advisory (for example 188.34.130.40 on port 444). Search forward traffic logs or FortiAnalyzer.

Collect this evidence before you upgrade, and open a Fortinet support case if anything matches.

How to fix CVE-2022-42475

Choose the target build

FortiOS-6K7K (FortiGate 6000 and 7000 series) has its own rows: upgrade 6.4 to 6.4.10, 6.2 to 6.2.12 and 6.0 to 6.0.15 or later. For 6K7K 7.0 the advisory lists 7.0.8 as both the last affected build and the fix, so choose a later 7.0 build or confirm with Fortinet support.

These are minimums. Because the April 2025 persistence symlink is removed on upgrade to FortiOS 7.6.2, 7.4.7, 7.2.11, 7.0.17 or 6.4.16, a device that ran SSL-VPN should go to one of those builds or a later one in a supported branch. Use Fortinet’s upgrade path tool (docs.fortinet.com/upgrade-tool) to plan the intermediate hops.

Upgrade FortiOS

Back up the configuration first, for example to a TFTP server:

execute backup config tftp <backup_filename> <tftp_server>

In the GUI on FortiOS 7.2 and later, go to System > Fabric Management, select the FortiGate and click Upgrade. Pick the build from Latest, All Upgrades or File Upload, choose Follow upgrade path when offered, then click Confirm and Backup Config and Continue. On FortiOS 7.0 and earlier, use System > Firmware, upload the image and click Backup config and upgrade. If FortiManager manages the device, upgrade FortiManager to a compatible version first.

From the CLI, with the image in the root of a reachable TFTP server:

execute ping <tftp_server>
execute restore image tftp <firmware_filename> <tftp_server>
execute update-now

Answer y at the confirmation prompt. The device verifies the image, installs it and reboots. After it comes back, execute update-now refreshes antivirus and attack definitions, which matters here because Fortinet also pushed an AV/IPS signature that removes the persistence symlink on licensed devices. FortiProxy follows the same image upgrade approach; check the FortiProxy documentation for your version.

If you cannot upgrade yet: disable SSL-VPN

This is the advisory’s workaround. On FortiOS 6.4.9 and later, 7.0 and 7.2, per Fortinet’s technical tip on disabling SSL VPN:

config vpn ssl settings
    set status disable
end

With VDOMs, enter config vdom and edit <vdom_name> first. On 6.4.8 and earlier, 6.2 and 6.0, bring the SSL-VPN interface down instead (use ssl.<vdom_name> in a VDOM):

config system interface
    edit ssl.root
        set status down
end

Confirm with diagnose sys process pidof sslvpnd, which should return nothing. This is a stopgap that removes remote access, not a fix. For how to handle a KEV entry while the real fix waits, see what to do when a KEV vulnerability has no patch yet.

If you found indicators of compromise

Upgrading does not reliably evict an implant. Fortinet’s guidance after the symlink findings is to review all configuration and treat it as potentially compromised. In practice that means working with Fortinet support, rebuilding from a known-good configuration, and rotating every secret the device held: administrator and local user passwords, LDAP or RADIUS bind credentials, VPN pre-shared keys, and certificates with private keys stored on the FortiGate.

How to verify the fix and rescan

1. Run get system status and confirm the version is at or above the fixed build for your branch.
2. If SSL-VPN is meant to stay off, confirm diagnose sys process pidof sslvpnd returns nothing.
3. Repeat the IOC commands and check that the AV and IPS engines are licensed and current.
4. Rescan with the same Nessus policy, credentials and Paranoid report setting, so plugin 168637 evaluates the new version string and closes.

What can break and how to roll back

A firmware upgrade reboots the device, dropping traffic on a standalone unit and disconnecting SSL-VPN users. Jumping several releases can change configuration syntax; Fortinet warns that upgrading directly instead of following the upgrade path may result in loss of configuration. On an HA cluster, follow Fortinet’s HA firmware upgrade procedure for your version. Disabling SSL-VPN breaks remote access for everyone who uses it, so arrange an alternative before you switch it off.

Rollback is harder than it looks. Fortinet’s release notes state that downgrading results in configuration loss on all models apart from a few basic settings such as interface and management IP addresses. To go back, install the previous image and restore the backup you took on that version:

execute restore config tftp <backup_filename> <tftp_server>

In the GUI, use the user name menu, then Configuration > Restore. A rollback reinstates the vulnerability, so keep SSL-VPN disabled until you can upgrade again.

Common false positive reasons

• Stale version data. The plugin uses the version collected during the scan. Results from a scan that ran before the upgrade will not close until you rescan.
• FortiOS-6K7K numbering. The 6K7K fixed builds differ from standard FortiOS (for example, 6K7K 6.4.10 is fixed while FortiOS 6.4.10 is not). If a FortiGate 6000 or 7000 series device is flagged, compare its build with the 6K7K rows before accepting the finding.
• Wrong asset. Check which host and version the plugin output names, especially behind NAT.

A device with SSL-VPN disabled is mitigated rather than a false positive. Record the pidof output as evidence and schedule the upgrade at normal priority.

FAQ

Is my FortiGate vulnerable if SSL-VPN is disabled?

The bug is in sslvpnd, so it is not reachable while the daemon is off. The vulnerable code is still installed, so upgrade anyway.

Why did a normal Nessus scan not report plugin 168637?

It only runs when the scan policy’s report paranoia is set to Paranoid.

Does upgrading remove an attacker who already got in?

Not necessarily. Fortinet documented implants and a persistence symlink that survived patching. Upgrade to 7.6.2, 7.4.7, 7.2.11, 7.0.17, 6.4.16 or later and treat the configuration as compromised.

Is there a fix for FortiOS 5.x?

No. The advisory says to migrate to a fixed release, which may mean replacing the hardware.

Tracking this finding across many hosts

Across a fleet of firewalls, the work is separating devices that really expose SSL-VPN from version-only hits and proving each upgrade happened. If you use SITEY, you upload the .nessus export (results are not pulled automatically), AI triage suggests likely false positives with supporting evidence while a person makes the final call, and a per-finding Nessus retest confirms plugin 168637 has closed. Its remediation agents run on Windows and Linux endpoints, so the FortiOS upgrade itself remains a change you make on the device.

Sources

• Fortinet PSIRT: FG-IR-22-398, heap-based buffer overflow in sslvpnd
• Tenable: Nessus plugin 168637
• Fortinet Community: Protect against heap-based buffer overflow in sslvpnd
• Fortinet PSIRT blog: Analysis of Threat Actor Activity (symlink persistence)
• Fortinet Document Library: Upgrading individual devices