Is CVE-2018-13379 (Fortinet FortiOS SSL VPN Path Traversal) being exploited in the wild?

What “Exploited in the Wild” Means for This CVE

This question is not really about the vulnerability label alone, it is about whether the flaw has moved from theory to active abuse. For CVE-2018-13379, the practical answer is yes: the security implication is that exposed FortiOS SSL VPN portals should be treated as likely target systems, especially when internet-facing and unsegmented. Confirmation should start with exposure, not with assumptions about patch status.

When a CVE is in CISA’s Known Exploited Vulnerabilities catalogue, the operational meaning is that defenders should assume real-world exploitation pressure and prioritise verification accordingly. The most useful next step is to determine whether any FortiOS SSL VPN instance is reachable from untrusted networks, whether logging is enabled, and whether the affected portal has been used recently by unexpected sources.

The fact pattern also matters because the vulnerability is a path traversal issue in a remote access service. That means the likely blast radius is not limited to the portal itself, because file access to appliance-resident data can expose configuration material, internal references, and other information useful for follow-on access. For appliance-edge issues like this, the core question is whether the device was merely exposed or whether it may already have been used as an entry point.

Why SSL VPN Path Traversal Becomes an Exposure Problem

Path traversal on an SSL VPN web portal is especially dangerous because the portal sits at the trust boundary. If an attacker can coerce file retrieval, they may gain information that is normally hidden behind the remote access layer. That can turn a single public-facing flaw into a wider access problem, because appliance files often support reconnaissance, credential targeting, or further authentication abuse.

For defenders, the key operational issue is that internet-facing VPN appliances are often treated as infrastructure, not as high-value application targets. That mindset is risky. A public remote access endpoint should be treated like any other externally exposed entry point: inventory it, log it, monitor it, and patch it under an emergency timeline when active exploitation is confirmed.

When the affected service is used for remote access, exposure also tends to persist. Administrators may assume the appliance is safe because it is “just the VPN,” but that is precisely why attackers value it. Remote access systems concentrate trust, traffic, and credentials, so compromise or partial file disclosure can have outsize downstream consequences compared with a typical internal application flaw. See the VPN Security Guide for the broader hardening context around appliance exposure and emergency response.

What to Check, Fix, and Verify After Confirmation

If you are responsible for a FortiOS environment, first confirm whether any instance is internet-facing, whether it is actually running the affected SSL VPN portal, and whether the device has evidence of suspicious access around the period of known exploitation. Then move immediately to vendor remediation guidance and CISA’s current KEV entry for version-specific action.

If patching must wait, treat the situation as a temporary high-risk exception rather than a normal deferred change. Reduce exposure by restricting access to trusted source ranges where that is operationally feasible, disabling or constraining the vulnerable service path if the vendor permits it, and increasing monitoring around the appliance and adjacent authentication systems. After remediation, verify not only that the vulnerability is addressed, but that no suspicious account activity, new configuration changes, or unexpected file access occurred before the fix.

Because this is a publicly exploited edge-device issue, post-fix review matters as much as the patch itself. Preserve logs, compare current device state to known-good baselines, and check for any evidence that the portal was used as an initial foothold. A quick patch without compromise assessment can leave an attacker’s persistence path intact even when the CVE itself is closed.

Risk and Threat Considerations

Path traversal in an internet-facing VPN portal creates a direct exposure path from unauthenticated request traffic to appliance-resident data. When active exploitation is confirmed, the practical risk is not only service disruption, but also the possibility that attackers used the device for reconnaissance, credential harvesting, or staging follow-on access.

Failure mechanism: An attacker sends specially crafted HTTP resource requests that escape the intended portal path and retrieve files from the FortiOS appliance, potentially exposing configuration and other sensitive data that supports further intrusion.

Impact: The organisation may face remote access compromise, increased likelihood of lateral movement, and a need for credential, session, or configuration review if the appliance was accessed before remediation.

Practitioner Guidance

What to prioritise: Treat confirmed KEV-listed exploitation as an emergency response problem, not a routine vulnerability ticket. The first priority is exposure containment, then compromise assessment, then remediation verification.

What to verify: Confirm whether the VPN portal was externally reachable, whether logs cover the exploitation window, and whether there are signs of unusual downloads, config access, or login anomalies around that period. If those records are incomplete, assume your confidence is limited and widen the review scope.

Decision rule: If the appliance provided remote access to production resources, rotate any credentials, sessions, or secrets that could plausibly have been exposed through the portal before you close the incident. The right question is not only whether the patch is installed, but whether the device may have been used to enable subsequent access.

Practitioner takeaway: For KEV-listed edge-device flaws, exploitability in the wild should change your response tempo immediately, because the real risk is often the trust boundary the device protects, not the device alone.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2018-13379 (Fortinet FortiOS SSL VPN Path Traversal)?
• CVE-2018-13379 (Fortinet FortiOS SSL VPN Path Traversal)
• Is CVE-2023-27997 (Fortinet FortiOS and FortiProxy SSL-VPN Heap-Based Buffer Overflow) being exploited in the wild?
• Is CVE-2020-12812 (Fortinet FortiOS SSL VPN Improper Authentication) being exploited in the wild?