CVE-2026-20349: Cisco ASA and FTD Remote-Access VPN Is Crashing Firewalls in the Wild

An unauthenticated attacker on the internet can send a single crafted HTTP request to your Cisco ASA or FTD firewall's remote-access VPN service and force it to reload. No credentials. No user interaction. No exploit chain beyond that one request. Cisco's Product Security Incident Response Team confirmed active exploitation before it published the fix, and CISA added the flaw, CVE-2026-20349, to the Known Exploited Vulnerabilities catalog on August 11 with a three-day remediation deadline for federal agencies.

If your ASA or FTD does not run Remote Access SSL VPN (webvpn), IKEv2 remote-access VPN with client services, or Zero Trust Network Access, this one is not yours. If any of those three features are live, and most firewalls fronting a remote workforce have at least one of them, keep reading.

What Cisco has confirmed, and what it has not

Cisco published advisory cisco-sa-asaftd-vpn-dos-dzv4mQFF on August 11 alongside fixed software, stating that PSIRT became aware of exploitation attempts that same month, ahead of the patch. CISA added CVE-2026-20349 to the KEV catalog the same day. The required action is blunt: apply the fix under CISA's BOD 26-04 risk-based patching guidance, or stop using the product if you cannot mitigate it.

Here is what the advisory and the KEV entry do not say. Cisco has not attributed the exploitation to a named threat actor, and CISA's own KEV record lists knownRansomwareCampaignUse as unknown. It is tempting to reach for ArcaneDoor, the 2024 espionage campaign that used two other ASA zero-days (CVE-2024-20353, CVE-2024-20359) against the same product line, but nothing in the current advisory ties this bug to that actor, UAT4356, or any other tracked group. Treat it as its own event.

The mechanism: a crash, not a foothold

The bug is CWE-244, improper clearing of heap memory before release. When the Remote Access SSL VPN service processes a specially crafted HTTP request, insufficient error checking lets that request trigger an unexpected reload. CVSS 3.1 vector: AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, base score 8.6. Read it literally: no confidentiality loss, no integrity loss, high availability loss, changed scope, meaning the fault takes down the whole device rather than one isolated process. This is a denial-of-service bug. There is no public evidence of code execution, credential theft, or persistence. The severity is entirely about how easy it is to trigger and how much depends on the device staying up.

Three conditions all have to be true for a device to be exposed

• Remote Access SSL VPN (webvpn) is enabled, or
• IKEv2 remote-access VPN with client services is enabled, or
• Zero Trust Network Access is enabled (FTD only)

Affected trains span ASA 9.16, 9.18, 9.20, 9.22, 9.23, and 9.24, and FTD 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. If none of those three services are running on your device, this bug has no code path to reach.

Hunt for it before you assume you are clean

Cisco's advisory does not publish indicators of compromise for the exploitation it observed, which means you cannot search a hash or a signature and call it done. What you can do is behavioral: look for reload events that do not match a maintenance window, pull the crash record for each one, and correlate the timing against inbound traffic to the VPN service. A single unexplained reload could be a hardware fault. A pattern of reloads, especially from more than one source IP inside a short window, is what active scanning or exploitation attempts look like.

! On the ASA/FTD CLI, check current uptime and pull the crash record
show version | include Up
show crashinfo

! Confirm whether the box has reloaded outside a known change window
show logging | include Device rebooted

# In your SIEM, correlate reload events against inbound VPN traffic.
# Adjust field and index names to your log source.
index=firewall sourcetype=cisco:asa "Device rebooted"
| eval reload_time=_time
| join type=left max=0
    [ search index=firewall dest_port=443 dest=<asa_ra_vpn_ip>
      | bucket _time span=5m
      | stats dc(src_ip) as unique_sources by _time ]
| where unique_sources > 5

Pull buffered logs and archived syslog for every ASA or FTD that reloaded unexpectedly in the last 90 days, even one you already wrote off as a fluke. If reload events do not currently reach a SIEM or an alert, that gap matters more than this CVE does.

Patch per train; the only mitigation is exposure reduction

Cisco has shipped fixed releases for every affected train: ASA 9.16.4.50, 9.18.4.50, 9.20.4.235, 9.22.3.191, 9.23.1.211, and 9.24.1.221, with corresponding FTD hotfixes listed in the same advisory. Cisco states plainly that there is no workaround. If you cannot apply the hot fix inside a maintenance window this week, the only real compensating control is narrowing who can reach the service at all: restrict the RA-VPN listener to your known remote-access address ranges or VPN client pool with an interface ACL rather than leaving it open to the entire internet, and turn off IKEv2 client services or Zero Trust Network Access on any device where you are not actually using them. Every one of the three features you disable is one less way to trigger this bug.

CISA's required action is not just federal-agency boilerplate: apply the fix, or stop exposing the product to the internet if you genuinely cannot mitigate it.

Confirm the hot fix, then make unexpected reloads page someone

If your ASA or FTD runs SSL VPN, IKEv2 remote access, or ZTNA and faces the internet, patch to the fixed release for your train tonight, not next maintenance window. If you cannot patch tonight, apply the source-IP restriction on the RA-VPN listener as the interim control and put the hot fix on this week's change calendar. Either way, wire firewall reload events into whatever you use for alerting so the next unexpected reboot pages someone instead of surfacing as an unexplained outage ticket three days later. A firewall that silently reloads and comes back up looks like nothing happened. That is the problem.