HowToFixMe
● Critical · CVSS 9.1 ⚠ ACTIVELY EXPLOITED: CISA KEV

How to Fix CVE-2018-13379: Fortinet FortiOS SSL VPN Path Traversal

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

CVE-2018-13379 is one of the most-exploited enterprise vulnerabilities of the last several years. It is a pre-authentication path traversal in the SSL VPN web portal of Fortinet FortiOS and FortiProxy. By sending a single specially crafted HTTP request, an unauthenticated attacker can walk outside the web root and download system files off the device, including the SSL VPN session file, which on vulnerable builds stored usernames and passwords in plaintext. No login, no exploit chain, no user interaction. One request, and the attacker has working VPN credentials.

If you operate an affected FortiGate or FortiProxy, the rest of this page is the short version: upgrade to a fixed build, then assume every credential that touched the SSL VPN was stolen and rotate it.

⚡ At a glance
SeverityCVSS 9.1 (CNA), Critical · vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Actively exploited?Yes — in CISA KEV (added 2021-11-03), known use in ransomware campaigns
Type (CWE)CWE-22: Improper limitation of a pathname to a restricted directory (path traversal), pre-authentication
AffectedFortiOS 5.4.6 through 5.4.12, 5.6.3 through 5.6.7, and 6.0.0 through 6.0.4; FortiProxy 1.0.0 through 1.0.7, 1.1.0 through 1.1.6, 1.2.0 through 1.2.8, and 2.0.0 — only when SSL VPN web mode is enabled
Fixed inFortiOS 5.4.13, 5.6.8, 6.0.5 (and 6.2.x / 6.4.x and later); FortiProxy 1.2.9 and 2.0.1 or later, per advisory FG-IR-18-384. Confirm the exact build for your hardware with the FortiGuard advisory.

Exploitation status

CVE-2018-13379 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Fortinet FortiOS SSL VPN Path Traversal Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . It is known to be used in ransomware campaigns. If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: working exploit code is public and the attack is trivial — a single crafted request to /remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession returns the SSL VPN session file. The bug has been mass-scanned since 2019, and lists of credentials harvested from vulnerable Fortinet devices have been published openly more than once. Treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

⚠️ Patch immediately. CVE-2018-13379 is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03). Federal agencies had until 2022-05-03 to remediate.

What is CVE-2018-13379?

CVE-2018-13379 is a CWE-22 path traversal in the SSL VPN web portal component of FortiOS and FortiProxy. The portal serves language files from a fixed directory, and the lang parameter on the /remote/fgt_lang endpoint was not properly sanitized. By stuffing the parameter with ../ sequences, an unauthenticated attacker climbs out of the intended directory and reads arbitrary files from the appliance filesystem.

The file that made this catastrophic is /dev/cmdb/sslvpn_websession. On vulnerable builds it held active SSL VPN sessions with usernames and passwords in cleartext. So this is not merely "an attacker can read a config file" — it hands over valid VPN credentials, which attackers then replay to log in legitimately. If the same passwords are reused for domain accounts (they usually are), the breach spreads well past the firewall.

Two things make this CVE special and explain why it still appears in incident reports years after the patch shipped: it requires no authentication and no user interaction, and the stolen credentials remain valid until they are rotated. Patching a device that was already looted does not undo the theft. That is why the credential reset below is not optional cleanup — it is half the fix.

Am I affected?

You are affected if you run one of the FortiOS or FortiProxy versions in the Affected row above and SSL VPN web mode (the browser-based portal) is or was enabled. Devices using only IPsec VPN, or SSL VPN in tunnel-only mode without the web portal, are not exposed through this vector — but verify rather than assume, because the portal is enabled in many default remote-access setups.

Check your running build and whether the SSL VPN portal is live from the FortiGate CLI:

# Show firmware version and build number
get system status

# Is the SSL VPN web portal enabled and on which interface/port?
show vpn ssl settings
get vpn ssl settings | grep -i 'status\|port\|source-interface'

If get system status reports a version at or below the affected range and show vpn ssl settings shows the service enabled, treat the device as exposed and move straight to the fix.

How to fix CVE-2018-13379

There are two parts, and you need both: (1) upgrade to a fixed firmware build, and (2) rotate every credential that could have been exposed. Doing only the first leaves stolen passwords working.

Step 1 — upgrade FortiOS / FortiProxy firmware

Upgrade to a fixed build from the Fixed in row: FortiOS 5.4.13, 5.6.8, or 6.0.5 (or move to a current 7.x branch), and FortiProxy 1.2.9 or 2.0.1 and later. Always check the FG-IR-18-384 advisory and Fortinet's upgrade path tool first, because skipping multiple major versions in one jump is not always supported and can require an intermediate build.

The clean, supported path is the GUI: System → Firmware, upload the verified image, confirm the upgrade. From the CLI the equivalent is below. Back up the config first — an upgrade across major versions occasionally drops settings that need re-applying.

# 1. Confirm current build before you touch anything
get system status

# 2. Back up the running config to a TFTP server you control
execute backup config tftp fgt-config-pre-patch.conf 10.0.0.10

# 3. Stage the verified firmware image (downloaded from support.fortinet.com)
#    and flash it. The device validates the image, installs, and reboots.
execute restore image tftp FGT_-v6-buildXXXX-FORTINET.out 10.0.0.10
# The unit reboots automatically once the image is written.

# 4. After reboot, confirm the new build
get system status

For an HA cluster, upgrade through the cluster's coordinated firmware process so the secondary updates first and the failover is graceful; do not flash members independently.

Step 2 — rotate every exposed credential (do not skip)

Because the session file leaked plaintext passwords, assume that any credential used for SSL VPN while the device was vulnerable is now in someone else's hands. Fortinet's own guidance after the mass-exploitation events was explicit about this. Reset, in order of priority:

  1. All SSL VPN user passwords — local users on the FortiGate, and the upstream directory passwords (LDAP / Active Directory / RADIUS) for any account that authenticated through the portal.
  2. All administrator passwords on the device, plus any API keys or admin tokens.
  3. Pre-shared keys and certificates referenced by the VPN configuration, if there is any chance they were readable.

Then turn on multi-factor authentication for SSL VPN so a stolen password alone is no longer enough to log in:

# Reset a local SSL VPN user's password
config user local
    edit "vpnuser1"
        set passwd 
    next
end

# Require client certificate / token in addition to password on the SSL VPN portal,
# and review who is allowed in
config vpn ssl settings
    set reqclientcert enable
end

If the device was internet-facing on a vulnerable build for any meaningful window, treat it as a confirmed credential compromise rather than a hypothetical one. The cost of an unnecessary password reset is an afternoon; the cost of skipping it has been ransomware.

If you can't patch immediately

If you genuinely cannot flash firmware right now, the only reliable mitigation is to take the SSL VPN web portal off the internet until you can. There is no input-filtering trick that fully closes a flaw inside the appliance's own web service, so reduce exposure instead:

These steps shrink the blast radius. They are a stopgap, not a fix: schedule the firmware upgrade as an emergency change.

How to verify the fix worked

First confirm the build. Run the version probe again and check it matches the Fixed in row:

get system status
# Look for Version: FortiGate-... v6.0.5 (or 5.6.8 / 5.4.13 / a later branch)

Then confirm the exploit no longer works. From a host that is not on the device, request the formerly-vulnerable path and confirm you get a 403 or an empty/error response instead of session data:

# Should NOT return any sslvpn_websession content on a patched device
curl -k 'https://<fortigate-ip>:<sslvpn-port>/remote/fgt_lang?lang=/../../../..//////////dev/cmdb/sslvpn_websession'

Finally, re-run your vulnerability scanner and confirm the CVE-2018-13379 finding has cleared, then sweep authentication logs for SSL VPN logins from unexpected locations or accounts that bypassed MFA during the exposure window. Compare against the indicators of compromise published in the FortiGuard and CISA advisories.

Frequently asked questions

Is patching CVE-2018-13379 enough, or do I also need to reset credentials?

Patching alone is not enough. Because the path traversal let attackers download the SSL VPN session file in plaintext, any password used during the exposure window may already be on an attacker's leaked credential list. Fortinet and CISA both advise treating every local and remote (LDAP/RADIUS) credential used for SSL VPN as compromised: force a reset for all VPN users and admin accounts, then enable MFA.

Which FortiOS and FortiProxy versions fix CVE-2018-13379?

Per Fortinet advisory FG-IR-18-384, the fix is in FortiOS 5.4.13, 5.6.8, and 6.0.5 (and all 6.2.x / 6.4.x and later), plus FortiProxy 1.2.9 and 2.0.1 or later. Confirm the recommended build for your specific hardware with the FortiGuard advisory and the upgrade path tool, because the safe upgrade route depends on your current version.

How do I tell if my FortiGate was already exploited?

Check whether SSL VPN web mode was enabled and internet-facing while you ran a vulnerable build. Look for SSL VPN logins from unexpected geographies, logins that bypassed MFA, and the IOCs in the FortiGuard and CISA advisories. Successful pre-auth file reads leave little trace, so if the device was exposed, assume credential theft and rotate secrets rather than waiting for proof.

Is there public exploit code for CVE-2018-13379?

Yes. Working exploit code is public and the attack is trivially weaponized — a single crafted request to the SSL VPN portal returns the session file. It has been mass-scanned since 2019, lists of harvested Fortinet credentials have been dumped publicly, and CISA lists it in the Known Exploited Vulnerabilities catalog, including use in ransomware intrusions.

References

Written by Sai Kiran Pandrala on 2026-05-25. Sourced from the official vendor advisory, the NVD record, and the CISA KEV listing. Always confirm against the vendor advisory before applying changes in production.

Related guides worth a look while you sort this one out:

People also ask

Is patching CVE-2018-13379 enough, or do I also need to reset credentials?

Patching alone is not enough. Because the path traversal let attackers download the SSL VPN session file in plaintext, any password used during the exposure window may already be on an attacker's leaked credential list. Fortinet and CISA both advise treating every local and remote (LDAP/RADIUS) credential used for SSL VPN as compromised: force a reset for all VPN users and admin accounts, then enable MFA.

Which FortiOS and FortiProxy versions fix CVE-2018-13379?

Per Fortinet advisory FG-IR-18-384, the fix is in FortiOS 5.4.13, 5.6.8, and 6.0.5 (and all 6.2.x / 6.4.x and later), plus FortiProxy 1.2.9 and 2.0.1 or later. Confirm the recommended build for your specific hardware with the FortiGuard advisory and the upgrade path tool.

How do I tell if my FortiGate was already exploited?

Check whether SSL VPN web mode was enabled and internet-facing while you ran a vulnerable build. Look for SSL VPN logins from unexpected geographies, logins that bypassed MFA, and the IOCs in the FortiGuard and CISA advisories. Successful pre-auth file reads leave little trace, so if the device was exposed, assume credential theft and rotate secrets rather than waiting for proof.

Is there public exploit code for CVE-2018-13379?

Yes. Working exploit code is public and the attack is trivially weaponized — a single crafted request to the SSL VPN portal returns the session file. It has been mass-scanned since 2019, lists of harvested Fortinet credentials have been dumped publicly, and CISA lists it in the Known Exploited Vulnerabilities catalog, including use in ransomware intrusions.