How to Fix CVE-2020-3452: Cisco ASA and FTD WebVPN Path Traversal

CVE-2020-3452 is an unauthenticated, read-only path traversal in the web services interface of Cisco ASA and Firepower Threat Defense (FTD) software, reachable whenever WebVPN or AnyConnect is enabled. Attackers can read files from the web services file system, such as WebVPN configuration and bookmarks. The fix is upgrading to a fixed release, because no workaround exists.

Cisco published the advisory on July 22, 2020 and updated it the next day to report public exploit code and active exploitation. If this finding is on an internet-facing VPN gateway, treat it as urgent even if your scanner labels it Medium.

What the scanner is actually detecting

Some reports shorten the title to “Cisco ASA and FTD Software Web Services Read-Only Path Traversal”. Nessus 139064 is a remote check in the CISCO plugin family. It sends an HTTP request containing directory traversal sequences to the device’s web service (port 443 or another detected web port), and Tenable marks it as exploited by Nessus. A hit therefore reflects how the device actually responded, not just a version string.

Tenable rates it CVSS v2 5.0 and CVSS v3 7.5 (High), with a VPR of 6.0. Scanner views that rank by CVSS v2 show it as Medium, which is why it sometimes sinks in the queue.

Real-world risk

Cisco is specific about the limits. The attacker can read files only within the web services file system, which exists when WebVPN or AnyConnect is configured. Those files can include WebVPN configuration, bookmarks, web cookies, partial web content and HTTP URLs. Cisco’s own example of impact is impersonating another VPN user and establishing a Clientless SSL VPN or AnyConnect session as that user.

What it cannot do also matters: it does not reach ASA or FTD system files, underlying operating system files, or VPN user login credentials (Cisco added that last point in advisory revision 1.5). It is read-only, so there is no file write, code execution or denial of service from this CVE alone.

The reason to move fast is exposure plus exploitation. The VPN portal faces the internet by design, public exploit code has existed since July 2020, and CVE-2020-3452 is listed in the CISA Known Exploited Vulnerabilities catalog. Tenable’s plugin page also shows a FIRST EPSS score of about 0.9999 (June 2026), near the top of all scored CVEs.

How to confirm it on the device

Check the version and VPN configuration on ASA

show version
show running-config webvpn
show running-config crypto ikev2 | include enable

The device is vulnerable if it runs an affected release and has any of the configurations from Cisco’s advisory:

• AnyConnect SSL VPN or Clientless SSL VPN: a webvpn block containing enable <interface_name>
• AnyConnect IKEv2 remote access: crypto ikev2 enable <interface_name> client-services port <port #>

Note the notation: show version prints a release such as 9.12(3)12, which the advisory writes as 9.12.3.12.

Check FTD

Run show version in the regular FTD CLI. Per the advisory, show running-config is available only in Diagnostic CLI mode, so enter it first, then use enable to reach privileged mode:

system support diagnostic-cli
enable
show running-config webvpn
show running-config crypto ikev2 | include enable

Remote Access VPN on FTD is configured under Devices > VPN > Remote Access in FMC or Device > Remote Access VPN in FDM. FTD releases earlier than 6.2.2 are not vulnerable, and Cisco confirmed that Firepower Management Center (FMC) itself is not affected.

Test the web service directly

Tenable’s analysis of the public proof of concept shows it reading /+CSCOE+/portal_inc.lua. Against a gateway you are authorized to test:

curl -sk "https://<vpn-gateway>/+CSCOT+/translation-table?type=mst&textdomain=/%2bCSCOE%2b/portal_inc.lua&default-language&lang=../"

If the response body contains Lua source, the device is vulnerable. A fixed device does not return the file.

How to fix CVE-2020-3452

Choose the target release

These are 2020 minimums, not good targets. Cisco has since published more advisories against the same ASA and FTD VPN web server, so paste your show version output into the Cisco Software Checker and pick a currently supported release that clears all of them. Some older ASA hardware cannot run 9.6 or later; check Cisco’s ASA compatibility matrix, because for those units there is no fixed release.

Upgrade a standalone ASA from the CLI

Following Cisco’s ASA upgrade guide, keep a copy of the current configuration and leave the old image on flash for rollback:

copy running-config disk0:/pre-upgrade.cfg
copy https://<server>/<path>/<asa_image_name> disk0:/<asa_image_name>
configure terminal
show running-config boot system
no boot system disk0:/<old_image_name>
boot system disk0:/<asa_image_name>
write memory
reload

If you previously pointed asdm image at a separate file, the guide has you reset it to the bundled image first.

Upgrade an Active/Standby failover pair

Run these on the active unit. failover exec mate copies the image to the standby unit:

copy https://<server>/<path>/<asa_image_name> disk0:/<asa_image_name>
failover exec mate copy /noconfirm https://<server>/<path>/<asa_image_name> disk0:/<asa_image_name>
configure terminal
no boot system disk0:/<old_image_name>
boot system disk0:/<asa_image_name>
write memory
failover reload-standby

Wait until show failover reports the standby unit as Standby Ready, then run no failover active to fail over. Reconnect to the new active unit and run failover reload-standby to upgrade the former active unit.

Upgrade FTD through FMC or FDM

Use the FMC or FDM upgrade workflow for your release. Cisco’s advisory says to reapply the access control policy after installation. The hot fixes listed for 6.3.0.5, 6.4.0.9 and 6.5.0.4 close this CVE, but a full move to a current release is the better end state. Check the FTD upgrade guide for required intermediate versions before planning a large jump.

If WebVPN or AnyConnect is configured but unused

There is no workaround while these features are in use. If a device carries leftover VPN configuration that nobody uses, removing it takes the device out of scope while you schedule the upgrade:

configure terminal
webvpn
 no enable <interface_name>

Check the crypto ikev2 enable line in Cisco’s command reference before touching it, because IKEv2 may also carry site-to-site tunnels.

After the upgrade: clean up what may have leaked

• Run vpn-sessiondb logoff all in privileged EXEC mode so every VPN user re-authenticates, ending any session that relied on stolen cookies.
• Review bookmark lists under Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks, including POST parameters, and customization objects (show import webvpn customization).
• Rotate any password, token or API key stored in a bookmark or customization, and remove internal URLs that no longer need to be published.
• For detection on FTD with SSL Decryption, Cisco lists Snort rules 54598 to 54601 (SRU 2020-07-22-001).

How to verify the fix and rescan

1. Run show version (and show failover on pairs) and confirm every unit runs the new release.
2. Repeat the curl request. It should no longer return Lua source.
3. Rescan with a Nessus policy that includes plugin 139064 and reaches the VPN portal’s actual port, from the same vantage point that found it. If the portal listens on a non-standard port, add that port.
4. Run the new version through the Cisco Software Checker to catch later advisories.

What can break and how to roll back

Any rollback to an affected release reopens CVE-2020-3452, so keep that window short.

Common false positive reasons

Because 139064 tests behavior, a genuine false positive is uncommon. Mismatches usually come from:

• Wrong asset. The scanned IP is a NAT address or load balancer in front of the ASA, so the finding belongs to a different device than the one in your inventory.
• Stale results. The scan predates the upgrade or failover.
• Version-based tools. Other scanners may flag an FTD with the hot fix applied because they read only the version.
• Duplicates. One ASA with several VPN-enabled interfaces appears as several hosts.

The opposite also happens: a clean result can mean the scanner never reached the portal, for example a custom port or a scan from a segment that cannot reach the outside interface. Knowing which gateways are exposed is part of external attack surface management scope.

FAQ

Is there a workaround for CVE-2020-3452?

No. Cisco states there are no workarounds. Only removing the WebVPN and AnyConnect configuration takes a device out of scope.

Can attackers steal VPN passwords with it?

Not directly. Cisco says VPN user login credentials are not exposed, but cookies and session data in the web services file system could let an attacker impersonate a user.

Is Firepower Management Center affected?

No. Cisco confirmed FMC is not affected. The managed FTD devices are.

Why does Nessus show it as Medium?

The CVSS v2 score is 5.0. The CVSS v3 score is 7.5, and the CVE is actively exploited and KEV-listed, so prioritize it above its label.

Tracking this finding across many hosts

With several VPN gateways, the practical question is which ones are actually upgraded. SITEY, a self-hosted vulnerability management platform, imports Nessus results from an uploaded .nessus export, pulls CISA KEV and FIRST EPSS data, and can re-test an individual Nessus finding such as 139064 after an upgrade. Duplicates are merged per scanner, so a gateway reported by two different scanners still shows as two findings.

Sources

• Cisco Security Advisory cisco-sa-asaftd-ro-path-KJuQhB86
• Tenable: Nessus plugin 139064
• Tenable blog: CVE-2020-3452 analysis
• Cisco Secure Firewall ASA Upgrade Guide: Upgrade the ASA
• Cisco ASDM VPN Configuration Guide: Advanced Clientless SSL VPN Configuration (bookmarks)