CVE-2026-20349 — Cisco Secure Firewall ASA/FTD Remote Access SSL VPN Denial of Service

What it is. CVE-2026-20349 is a CVSS 8.6 denial-of-service vulnerability in the Remote Access SSL VPN (WebVPN) service of Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software. The root cause is insufficient error checking / improper clearing of heap memory before release (CWE-244) while processing HTTP requests. An unauthenticated, remote attacker sends one crafted HTTP request to the WebVPN listener and the device reloads — no credentials or user interaction required. Vulnerable when IKEv2 Remote Access VPN with client services, SSL VPN (WebVPN), or Zero Trust Network Access (FTD only) is enabled and reachable. Secure Firewall Management Center (FMC) itself is not affected.

Why it matters. Cisco disclosed the flaw and confirmed active exploitation on 2026-08-11; CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a Federal Civilian Executive Branch remediation deadline of 2026-08-14 — today. There is no workaround. Cisco's advisory states plainly: "There are no workarounds that address this vulnerability." The only remedy is the hotfix. Because this is a single-request, pre-authentication crash, any internet-facing ASA/FTD device with SSL VPN, IKEv2 RA-VPN, or ZTNA enabled is a live target right now, and repeated exploitation can crash-loop a device indefinitely, or take down both members of an HA/failover pair if both are unpatched.

The hunt problem. Cisco ASA/FTD is not a Falcon-sensor-capable operating system, so the exploitation primitive itself is invisible to endpoint telemetry. This is a bare-CVE, appliance/network-log-based hunt: no malware family, no C2 infrastructure, and no published IOCs exist for this CVE (Cisco's advisory explicitly states it ships no indicators of compromise). This pack hunts on two honest planes: (1) native ASA/FTD syslog forwarded into Falcon Next-Gen SIEM/LogScale — unscheduled reload/crash events and anomalous WebVPN request volume; and (2) a secondary, corroborating endpoint-visible proxy signal — VPN client reconnect storms on Falcon-managed hosts behind the gateway, which is not a standalone detection. This mirrors the established pattern for prior edge-device CVE packs in this library.

Defender priority: Patch every internet-facing ASA/FTD device running Remote Access SSL VPN, IKEv2 RA-VPN, or ZTNA to the fixed hotfix release today — the KEV deadline is today and there is no workaround. If patching cannot complete immediately, restrict WebVPN-listener reachability via control-plane ACLs as a stopgap, and confirm both members of any HA pair are patched, not just the active unit.

Sourcing transparency: the CISA KEV catalog page itself (cisa.gov/known-exploited-vulnerabilities-catalog) and the CISA KEV-addition alert page both returned HTTP 403 to direct automated fetch. The KEV addition date, product, and required-action language were corroborated instead via a third-party KEV mirror (kevintel.com) plus three independent T1/T2 sources (Cisco advisory, BleepingComputer, The Hacker News, Canadian Centre for Cyber Security) that all cite the same KEV addition and 2026-08-14 FCEB deadline. Confidence in the KEV fact remains High due to this convergence; the direct-fetch gap is disclosed rather than concealed.

Embedded-instruction check: no fetched source contained text addressed to an AI/assistant, claims of system/AI authority, or attempts to redirect agent behavior. The Security Arsenal blog (source #4 in the saved snapshots) ends with ordinary vendor self-promotion — links to its own penetration-testing and SOC-assessment services. This is commercial marketing copy, not a prompt-injection attempt, and it was noted but not acted upon. No other anomalies were observed across the 8 saved source snapshots.

Intel gaps: no atomic IOCs (hashes, domains, IPs), no attacker attribution, and no named campaign are published by any source — Cisco's advisory explicitly states it ships no indicators of compromise. This is expected and normal for a fresh appliance-DoS disclosure; treat the behavioral, syslog-based detections in §8 as the primary and durable detections for this CVE.

This is an appliance/network-log-based hunt, not a host-process-telemetry hunt. Cisco ASA/FTD is not a Falcon-sensor-capable operating system — there is no process, registry, or file-write behavior on the vulnerable device itself for Falcon to observe. Detection depends on Cisco ASA/FTD syslog being forwarded into Falcon Next-Gen SIEM/LogScale. This matches the established pattern for prior edge-device CVE hunt packs in this library.

Hunt hypotheses (fidelity-ordered)

Attack chain

No atomic indicators of compromise are published for CVE-2026-20349 by any source. Cisco's advisory explicitly states it does not provide IOCs associated with the ongoing exploitation. No source publishes attacker source IPs, domains, malware hashes, or a crafted-request signature. This is a legitimate, expected gap for a bare-DoS CVE with no dropped payload — not an extraction failure. Do not fabricate indicators; the behavioral observables below are the durable, sourced detections.

Coverage reality: H1 and H2 — the two primary, highest-confidence detections — are blind if ASA/FTD syslog is not forwarded to your SIEM. If that forwarding is not already in place, treat enabling it as the fastest, highest-leverage coverage win for this pack (and every future ASA/FTD advisory).

No other ATT&CK techniques are claimed by any source. This is a single-request DoS trigger — no lateral movement, persistence, or credential-access behavior is described anywhere in the sourced material.

These run against the appliance itself — the only place the exploit primitive and its immediate outcome are directly visible. Forward ASA/FTD logs to your SIEM if you have not already.

On the ASA/FTD device (CLI)

• Confirm exposure: show version to get the current running release, then check whether WebVPN/SSL VPN, IKEv2 Remote Access with client services, or ZTNA is enabled and bound to an internet-reachable interface.
• Confirm patch status: compare the reported build against Cisco's fixed-hotfix table (§12/§13) using Cisco's Software Checker — do not rely on release notes alone.
• Crash/reload history: show crashinfo and buffered/console logs for any unexpected reload not matching a known maintenance action.
• HA pair status: show failover (ASA) or the equivalent FTD HA status view — confirm both units report the same, patched software version and neither has an unexplained recent reload.

On the syslog/SIEM tier

• Alert on any ASA/FTD reload, reboot, crash, or crashinfo-generation syslog message with no matching change-ticket window.
• Alert on a burst of malformed, error, or denied HTTP requests to the WebVPN endpoint from a single source in a short window — the harvest/trigger pattern.
• Ensure NTP is synchronized across all ASA/FTD devices and your SIEM so reload timestamps correlate cleanly with request-volume timestamps.

Queries Q1 and Q2 assume Cisco ASA/FTD syslog is forwarded into Falcon Next-Gen SIEM/LogScale via a syslog/CEF ingest source. #event_simpleName, device_vendor/device_product, and message below are generic placeholder field names for a syslog ingest pipeline — they have not been validated against any specific customer log-source parser. Validate against a sample ingested row for your environment before deploying; your syslog connector may name these fields differently.

// HUNT: CVE-2026-20349 - Cisco ASA/FTD unscheduled reload / crash-traceback detection
// MITRE: T1499 / T1499.004 (inferred) | CONF: medium  FP: medium  COST: low | REQUIRES: Cisco ASA/FTD syslog forwarded to Falcon NG-SIEM (generic ingest field names below — validate in tenant)
// HYPOTHESIS: an unscheduled ASA/FTD reload/reboot/crash event with no matching change ticket indicates possible CVE-2026-20349 exploitation; >=2 reloads for the same device in this window is a crash-loop signal
// TUNING: exclude reloads inside a documented change window; exclude reloads immediately following a "write memory" / "copy running-config startup-config" / firmware-upgrade sequence visible in the same syslog stream; HA planned-failover tests look identical to a crash-loop -- confirm against the maintenance calendar
// ⚠ validate in tenant: device_vendor, device_product, message are generic syslog/CEF ingest field names, not native Falcon sensor fields -- confirm against a sample ingested row for YOUR syslog connector before deploying
#event_simpleName = /^(SyslogEvent|CiscoNetworkSyslog|CefEvent)$/
| device_vendor = "Cisco"
| device_product = /^(ASA|FTD|NGFW|FirewallThreatDefense)$/i
| message = /(reload|reboot|crash|traceback|crashinfo)/i
| device_host_name := coalesce([device_host_name, SourceHostName, host])
| groupBy([device_host_name], function=[count(as=reload_events), collect(message), collect(@timestamp)], limit=20000)
| sort(reload_events, order=desc)
| table([device_host_name, reload_events, message, "@timestamp"], limit=200)

// HUNT: CVE-2026-20349 - anomalous WebVPN HTTP request volume correlated to a subsequent device reload
// MITRE: T1190 | CONF: medium  FP: medium-high  COST: medium | REQUIRES: Cisco ASA/FTD syslog forwarded to Falcon NG-SIEM at a logging level that captures individual WebVPN HTTP request errors (not all deployments enable this by default)
// HYPOTHESIS: a malformed/error HTTP request burst to WebVPN immediately preceding a reload on the same device is mechanism-consistent with CVE-2026-20349 exploitation
// TUNING: a high WebvpnAnomalyCount with reload_events = 0 is NOT actionable on its own -- it is far more likely scanning/misconfiguration noise than exploitation; escalate only rows where reload_events > 0; if initial results are empty, widen the bucket from 5 minutes (300000 ms) to 15 minutes (900000 ms)
// ⚠ validate in tenant: device_vendor, device_product, message are generic syslog/CEF ingest field names, not native Falcon sensor fields -- confirm against a sample ingested row for YOUR syslog connector before deploying. reload_events is a locally-defined alias (see join subquery below), not a Falcon data-model field.
#event_simpleName = /^(SyslogEvent|CiscoNetworkSyslog|CefEvent)$/
| device_vendor = "Cisco"
| device_product = /^(ASA|FTD|NGFW|FirewallThreatDefense)$/i
| message = /webvpn/i
| message = /(error|malformed|invalid|failed|denied|reset)/i
| device_host_name := coalesce([device_host_name, SourceHostName, host])
| RequestBucket5m := @timestamp - (@timestamp % 300000)
| groupBy([device_host_name, RequestBucket5m], function=[count(as=WebvpnAnomalyCount), collect(message)], limit=20000)
| WebvpnAnomalyCount > 20
| join(query={
    #event_simpleName = /^(SyslogEvent|CiscoNetworkSyslog|CefEvent)$/
    | device_vendor = "Cisco"
    | device_product = /^(ASA|FTD|NGFW|FirewallThreatDefense)$/i
    | message = /(reload|reboot|crash|traceback|crashinfo)/i
    | device_host_name := coalesce([device_host_name, SourceHostName, host])
    | RequestBucket5m := @timestamp - (@timestamp % 300000)
    | groupBy([device_host_name, RequestBucket5m], function=count(as=reload_events), limit=20000)
  }, field=[device_host_name, RequestBucket5m], mode=left)
| reload_events := if(reload_events != "", then=reload_events, else=0)
| reload_events > 0
| sort(WebvpnAnomalyCount, order=desc)
| table([RequestBucket5m, device_host_name, WebvpnAnomalyCount, reload_events, message], limit=200)

// HUNT: CVE-2026-20349 (collateral/secondary signal) - endpoint-visible VPN reconnect-storm proxy signal
// MITRE: T1499 (proxy signal) | CONF: low (corroborating only)  FP: high standalone  COST: low | REQUIRES: standard Falcon NetworkConnectIP4/IP6 telemetry (no syslog ingest needed)
// HYPOTHESIS: if an ASA/FTD VPN concentrator is repeatedly crashed via CVE-2026-20349, active client sessions on Falcon-managed endpoints drop and reconnect simultaneously once the device returns to service
// TUNING: exclude known daily peak-login windows (e.g. 08:00-09:30 local business hours) and scheduled patch/reboot maintenance; a DistinctEndpoints spike with no corresponding Q1/Q2 hit in the same window is very likely benign -- never escalate on this query alone, use it only to corroborate a Q1/Q2 hit
#event_simpleName = /^(NetworkConnectIP4|NetworkConnectIP6)$/
| RemoteAddressIP4 := coalesce([RemoteAddressIP4, RemoteAddressIP6])
| !cidr(RemoteAddressIP4, subnet="10.0.0.0/8")
| !cidr(RemoteAddressIP4, subnet="172.16.0.0/12")
| !cidr(RemoteAddressIP4, subnet="192.168.0.0/16")
| ConnectBucket5m := @timestamp - (@timestamp % 300000)
| groupBy([ConnectBucket5m], function=count(aid, distinct=true, as=DistinctEndpoints), limit=20000)
| sort(ConnectBucket5m, order=asc)
| table([ConnectBucket5m, DistinctEndpoints], limit=500)

No Custom IOA rule applies to CVE-2026-20349 in the traditional endpoint-process sense. There is no process-creation, registry, or file-write behavior to key a Custom IOA rule on — Cisco ASA/FTD is not a Falcon-sensor-capable operating system, and the exploitation mechanism is a single crafted network request, not a multi-step endpoint behavior chain. This is a coverage note, not a gap to force-fill with an inapplicable rule type. If your organization runs a WAF or NGFW in front of the WebVPN endpoint, the highest-fidelity real-time control belongs there (rate-limiting and malformed-request rejection on / paths serving the SSL VPN portal), not in a Falcon Custom IOA.

CVE-2026-20349 ships zero published atomic indicators — no hashes, domains, or IPs. Cisco's advisory explicitly states it does not include indicators of compromise. The blocks below carry no atomic values to import; they are placeholder-driven and behavioral/audit-oriented instead, so this section documents that absence explicitly rather than fabricating an indicator or silently dropping the section.

type,value,action,severity,expiration,description,tags
# No atomic IOCs (hash/domain/IP) are published for CVE-2026-20349.
# Cisco's advisory states it ships no indicators of compromise for the
# ongoing exploitation. Do not populate this block with fabricated values --
# if your own incident response later confirms an attacker source IP, add it
# here with action=detect (never prevent -- IPs are too volatile) and a
# short (30-day) expiration.
ipv4,REPLACE_WITH_CONFIRMED_SOURCE_IP,detect,medium,2026-09-13,CVE-2026-20349 WebVPN exploitation source (populate only if confirmed in your own IR),campaign:CVE-2026-20349

# Primary detection (device outcome):
#   Syslog class : reload / reboot / crash / crashinfo / traceback
#   Anomaly      : no matching change-ticket window; repeats = crash-loop
# Secondary detection (exploitation mechanism, if WebVPN request logging is enabled):
#   Target path  : WebVPN / SSL VPN listener
#   Anomaly      : burst of malformed / error / invalid / denied HTTP requests
#                  immediately preceding a reload on the same device
# Collateral / corroborating only:
#   Signal       : synchronized VPN client disconnect/reconnect burst across
#                  many endpoints behind the affected device

# Run on each in-scope ASA/FTD device:
show version                    # confirm current build vs. Cisco fixed-hotfix table
show running-config | include webvpn|ikev2|zero-trust   # confirm exposed RA-VPN features
show crashinfo                  # any crash artifact present?
show failover                   # (ASA) confirm HA partner patch level matches
# Preserve crashinfo + buffered logs from any device that reloaded
# unexpectedly in the last 90 days before they roll off local storage.

# Confirmed ASA hotfix targets (Cisco advisory cisco-sa-asaftd-vpn-dos-dzv4mQFF):
#   9.16 -> 89.16.4.50      9.18 -> 89.18.4.50
#   9.20 -> 9.20.4.235      9.22 -> 9.22.3.191
#   9.23 -> 9.23.1.211      9.24 -> 9.24.1.221
# FTD trains 7.0 / 7.2 / 7.4 / 7.6 / 7.7 / 10.0 also have hotfixes published.
# Exact per-platform FTD build identifiers were NOT independently confirmed
# in this pack's sourcing -- run Cisco's Software Checker against the
# advisory ID for the authoritative FTD hotfix identifier for your exact
# platform and train. Do not guess a build number.

There is no workaround for this vulnerability. Cisco's advisory states it explicitly: "There are no workarounds that address this vulnerability." Every control below except patching is a compensating, attack-surface-reduction measure to reduce exposure while patching is scheduled — none of them close the vulnerability itself.

What to verify after deployment

• Patch verification: Cisco Software Checker against post-upgrade show version output — confirm the reported build matches the advisory's fixed-release target.
• ACL verification: show access-list / show running-config access-list (or the FMC access-control-policy view) confirms the WebVPN-restricting ACL is the winning rule, not shadowed by a broader pre-existing one.
• HA-pair parity: show failover on both units reports the same, patched software version.
• Telemetry spot-check: run the field-name-validation query from §11 and confirm every in-scope device hostname appears with a non-zero event count before trusting Q1/Q2.

Playbook A — Patch verification and HA-pair audit (ASA/FTD CLI)

# 1. Confirm current version and exposure on each in-scope device
show version
show running-config | include webvpn|ikev2|zero-trust

# 2. Cross-reference the reported build against Cisco's Software Checker
#    using advisory ID cisco-sa-asaftd-vpn-dos-dzv4mQFF for the authoritative
#    fixed-hotfix identifier for your exact platform and train.

# 3. Apply the hotfix per Cisco's documented upgrade procedure for your
#    platform, then reboot and re-run "show version" to confirm the new build.

# 4. Confirm HA-pair parity (ASA) -- BOTH units must report the patched build
show failover

# 5. Preserve any existing crash evidence BEFORE upgrading
show crashinfo

Playbook B — Interim control-plane ACL restricting WebVPN reachability (pseudo-config)

# Restrict inbound reachability to the WebVPN/SSL VPN listener to known-good
# source ranges only, pending patch. Adjust interface name and source
# object-group to your environment -- this is a compensating control, not a fix.
object-group network TRUSTED-VPN-SOURCES
  network-object REPLACE_WITH_YOUR_TRUSTED_RANGE

access-list OUTSIDE-IN extended permit tcp object-group TRUSTED-VPN-SOURCES \
  any eq 443 log
access-list OUTSIDE-IN extended deny tcp any any eq 443 log
access-group OUTSIDE-IN in interface outside

# Verify the rule is winning and not shadowed by a broader pre-existing ACE:
show access-list OUTSIDE-IN

Playbook C — Syslog forwarding to Falcon Next-Gen SIEM/LogScale (concept steps)

# 1. On each ASA/FTD device, enable and direct syslog to your forwarder:
logging enable
logging host outside REPLACE_WITH_FORWARDER_IP
logging trap informational
logging timestamp

# 2. Confirm NTP is synchronized on the device so timestamps correlate
#    cleanly with your SIEM's clock:
show ntp status

# 3. In Falcon NG-SIEM/LogScale, confirm the ingest source/repo receiving
#    this syslog stream, and validate field names (device_vendor,
#    device_product, message, device_host_name or equivalents) against a
#    sample row before relying on Q1/Q2 in this pack (see gate in §11).

Known gaps: the exploit primitive itself (the crafted HTTP request content) is off-sensor and typically not captured at default ASA/FTD logging levels — closing this gap requires enabling WebVPN request-level logging, which some deployments do not have on by default. Custom IOA coverage is not applicable (§9) since ASA/FTD is not Falcon-instrumented.

Source provenance: 8 sources fetched and saved verbatim at research time; 0 atomic IOCs published for this CVE, so there is nothing to trace in the IOC provenance gate — this pack ships no fabricated indicators. Validation gates (§11) must pass — telemetry-ready and field-name-validation in particular — before Q1/Q2 are trusted operationally.