Am I vulnerable?
Two conditions have to be true: the appliance runs an affected ASA or FTD release, and it has at least one of three features enabled that open the SSL listen sockets. FMC is confirmed not affected.
Affected versions
| Product |
Vulnerable range |
| Secure Firewall ASA |
9.16 (9.16.1 to 9.16.4.92), 9.18 (to 9.18.4.90), 9.19 (to 9.19.1.42), 9.20 (to 9.20.4.46), 9.22 (9.22.1.1 to 9.22.3.5), 9.23 (to 9.23.1.32), 9.24 (to 9.24.1.11) |
| Secure Firewall Threat Defense (FTD) |
7.0 (to 7.0.9), 7.2 (to 7.2.12), 7.3 (to 7.3.1.2), 7.4 (to 7.4.8), 7.6 (to 7.6.4), 7.7 (to 7.7.13), 10.0 (to 10.0.2) |
| Secure Firewall Management Center (FMC) |
Not affected |
The precondition most teams will get wrong
Checking only for webvpn clears devices that are still vulnerable. Cisco's advisory lists three configurations, any one of which is independently sufficient:
webvpn
enable <interface_name>
crypto ikev2 enable <interface_name> client-services port <port_numbers>
zero-trust
enable
The third, Zero Trust Network Access, is FTD only.
Diagnostic commands
- Fastest go/no-go (ASA CLI):
show asp table socket | include SSL. Any output means an SSL listener is present. Cisco's example of a vulnerable device: SSL 00185038 LISTEN 172.16.0.250:443 0.0.0.0:*. Empty output means no listener. Sourcing caveat: Cisco publishes this determination step in its sibling Remote Access SSL VPN DoS advisories (cisco-sa-asaftd-vpn-dos-mfPekA6e, cisco-sa-asa-ssl-vpn-dos-qY7BHpjN), which use identical precondition wording. This CVE's advisory omits a determination section, so the mapping is an inference.
- Which feature is on (ASA CLI):
show running-config, then look for any of the three blocks above. This is the only diagnostic command named in the advisory itself.
- Running release (ASA CLI):
show version, and read the "Cisco Adaptive Security Appliance Software Version" line. Feed the exact string to the Cisco Software Checker for First Fixed and Combined First Fixed.
- FTD via FMC or FDM: no CLI equivalent published. Remote access VPN is enabled under Devices > VPN > Remote Access in FMC, or Remote Access VPN in FDM. A policy assigned to a device means it meets the precondition.
- Post-incident (ASA CLI):
show crashinfo files lists crash files in flash. Cisco published no signature identifying a CVE-2026-20349 crash, so a matching crashinfo is suggestive, not conclusive.
Two release trains are enumerated as affected but have no hot fix in Cisco's table: ASA 9.19 and FTD 7.3. Those deployments have neither a patch nor a workaround.
Vulnerability
Cisco describes the root cause in a single sentence: "insufficient error checking when processing HTTP requests." An unauthenticated attacker sends a crafted HTTP request to the Remote Access SSL VPN service, and the device reloads. No credentials, no administrator action, no user interaction.
The CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, base 8.6. Read the impact metrics carefully, because they carry the operational message: confidentiality None, integrity None, availability High. Scope is Changed, which is Cisco encoding the fact that a reloading firewall takes down everything traversing it, not just the VPN process.
There is an inconsistency here that has not been reconciled publicly. Cisco assigned CWE-244, Improper Clearing of Heap Memory Before Release, in both the advisory header and the CVE record, and CISA inherited the label into the KEV entry name ("Heap Inspection Vulnerability"). CWE-244 normally describes sensitive data surviving in freed heap memory, which is an information-disclosure weakness and does not fit a C:N vector or a description whose only stated effect is a reload. Cisco's prose root cause, insufficient error checking in an HTTP handler, points at an unhandled error path instead. Cisco has published no detail below that sentence and no third-party analysis resolves the gap, so treat the description and the vector as authoritative: availability only. Do not plan for data exfiltration on the strength of the CWE label.
Cisco credits the finding to internal security testing and to Valerio Brussani (@val_brux); the bug ID is CSCwv96220. One prioritisation note: Tenable recorded EPSS at roughly 0.97 percent while this sat on KEV with a three-day federal deadline. EPSS lags on fresh edge-device bugs with no public proof of concept, so an EPSS-driven queue would have ranked it near the bottom.
Threat model
Who would exploit this: The trigger is unauthenticated, network-reachable, and low complexity, against a service that must answer from the public internet, so once a working trigger circulates the capability bar is low. Opportunistic disruptors, booter and stresser operators, hacktivists targeting a named organisation, extortion actors who use availability as leverage, and state-aligned actors pursuing disruption all fit. Cisco PSIRT states it became aware of active exploitation in August 2026 and has published nothing about who is exploiting it or which organisations are targeted.
What they are after:
- Business disruption: removing remote workforce access, and where the same appliance is the internet edge, all transiting traffic, timed to a business-critical window.
- Extortion leverage over availability, in the DDoS-extortion pattern rather than the data-theft pattern.
- Denying remote access during a concurrent intrusion elsewhere, keeping remote IT staff and responders off the network.
- Degrading a perimeter control: while the device is down, inspection, logging, and policy enforcement on that path stop.
Data exfiltration and lateral movement are not goals this vulnerability serves. Its impact is availability only.
Attack chain: An attacker enumerates internet-facing ASA and FTD appliances with Remote Access VPN services enabled, which is straightforward at internet scale because the headend answers on a public address. A crafted HTTP request to that service causes the device to reload. Repeatability is the operationally important property: if the attacker sends the trigger again each time the device returns to service, the result is a sustained outage rather than a single blip. No source states the device enters a crash loop on its own, so treat sustained denial as an inference from the vector rather than a Cisco statement.
Blast radius: Every remote worker loses VPN connectivity for each reload plus reconvergence, and sessions re-establish rather than resume. Site-to-site tunnels on the same appliance drop with them. Where the appliance is also the internet edge firewall, all traffic transiting it stops, which is the safe failure mode for a firewall but still a full outage for everything behind it, and management and monitoring paths on the same box go dark in the same window. The attacker gets no code execution, no credential or configuration access, no data, and no persistence.
Two clarifications. High availability does not solve this, because the peer runs the same software version and, once it holds the active VPN address, presents the same service on the same public entry point. And ASA and FTD in routed or transparent mode stop passing traffic while reloading, so the device fails closed; the hardware-bypass behaviour some readers associate with FTD applies to inline-set IPS deployments, not to a VPN headend.
Attribution: none published. Cisco attributes the 2025 activity involving CVE-2025-20333, CVE-2025-20362, and CVE-2025-20363 to the ArcaneDoor actor, and that page does not mention CVE-2026-20349. The product line's targeting history is context, not a claim about this CVE.
Mitigation
Patch
Upgrade is the only remediation. Cisco states plainly: "There are no workarounds that address this vulnerability."
| Train |
Fixed release |
| ASA 9.16 |
89.16.4.50 (hot fix) |
| ASA 9.18 |
89.18.4.50 (hot fix) |
| ASA 9.20 |
9.20.4.235 |
| ASA 9.22 |
9.22.3.191 |
| ASA 9.23 |
9.23.1.211 |
| ASA 9.24 |
9.24.1.221 |
| FTD 7.0 |
GC-7.0.9.1-1 |
| FTD 7.2 |
HM-7.2.11.1-2 |
| FTD 7.4 |
HK-7.4.7.1-1 |
| FTD 7.6 |
DD-7.6.4.1-2 |
| FTD 7.7 |
AN-7.7.11.1-2 |
| FTD 10.0 |
S-10.0.0.1-2 |
| ASA 9.19, FTD 7.3 |
No hot fix published |
Two operational details. Hot fixes whose version starts with 89 require ASDM Release 7.24.1.374 or later, because earlier ASDM releases do not recognise that numbering format. FTD hot fixes ship as per-platform tarballs (Cisco_FTD_Hotfix_, Cisco_FTD_SSP_FP1K_Hotfix_, Cisco_FTD_SSP_FP2K_Hotfix_, Cisco_FTD_SSP_FP3K_Hotfix_, Cisco_Secure_FW_TD_1200, Cisco_Secure_FW_TD_4200, Cisco_Secure_FW_TD_6100, and a separate Cisco_Secure_FW_TD_200_Hotfix_R-10.0.0.1-2 for the 200 series), so pull the variant matching your hardware.
Compensating controls
None of these fix the bug, and Cisco offers no workaround, so treat them as exposure reduction while patching proceeds:
- Restrict Remote Access SSL VPN reachability to known source ranges where the business model allows it. For a general-purpose remote workforce VPN it usually does not, but for partner-only or admin-only headends it often can.
- Inventory every ASA and FTD with any of the three trigger configurations enabled, not just the ones with
webvpn. The IKEv2 client-services and FTD ZTNA paths are independently sufficient and are the ones an inventory sweep is most likely to miss.
- Decommission obsolete or duplicate remote access gateways still answering on public addresses.
- For ASA 9.19 and FTD 7.3, where no hot fix exists, plan a train migration rather than waiting, and confirm the target release against the Cisco Software Checker before scheduling.
- Cisco applies Snort rules 46897 and 59654 to this advisory. Neither SID has published rule documentation, so the detection logic behind them is not public, but confirm your Snort deployments carry current rules.
Detection (starter rules, validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.
Cisco published no indicators of compromise for this CVE: no syslog message IDs, no crashinfo signature strings, no forensic commands. That absence shapes everything below. There is no malware, no webshell, no dropped file, and no C2 to look for. The reload is the observable, which means the NOC will very likely know before the SOC does.
Network and log signals
- On-box crash artefact:
show crashinfo and dir disk0: looking for a newly written crashinfo_lina.<pid>.<YYYYMMDD>.<HHMMSS> file (and dir coredumpfsys for core files) with a timestamp matching the outage. This is the strongest single on-box artefact.
- Boot with no preceding operator reload:
%ASA-6-199005 (Startup begin) followed by %ASA-6-199002 (startup completed) with no %ASA-5-199001 (Reload command executed) from the same device in the preceding 30 minutes and no change record. Caveat: the documented text of 199001 is scoped to reloads issued over Telnet, so console or ASDM reloads may emit nothing, which inflates false positives rather than causing misses.
- Repeat reloads and estate-wide correlation: two or more boot completions from one appliance inside 60 minutes, or the same pattern landing on several independent VPN headends in the same window. Maintenance reboots a box once, on a schedule, per device.
- Mass session teardown then reconnection storm: a burst of
%ASA-6-716002 (WebVPN session terminated) and %ASA-6-722023 (SVC connection terminated) across effectively all users at once, then a spike of %ASA-6-716001, %ASA-6-722022, and %ASA-6-722051 as clients reconnect. Every user dropping in the same second is a device event, not user behaviour.
- Unexplained HA activity:
%ASA-1-104001 / 104002 / 104003 (switching to ACTIVE / STANDBY / FAILED), %ASA-1-105005 (lost failover communications with mate), or %ASA-1-105043 (failover interface failed), with no change ticket. In an HA pair the crash often presents to the SOC only as a switchover.
- Availability telemetry: SNMP
sysUpTime.0 resetting to near zero, an ICMP and SNMP polling gap on the management address, and NetFlow showing TCP/443 sessions to the headend accepted before the device goes dark. As a retrospective pivot only, never an alert, %ASA-6-302013 inbound TCP builds on 443 from sources that never generate a subsequent WebVPN or SVC session event in the minutes before a reload. That probe-then-crash shape is far too noisy to alert on, since scanners, health checks, and casual browsers all look identical.
YARA
Omitted. This is an availability-only crash bug with no on-disk artefact to sign: no malware sample, no webshell, no dropped file. A YARA rule here would match nothing useful.
Sigma
title: Cisco ASA/FTD Unexpected Reload or Traceback (Possible SSL VPN DoS, CVE-2026-20349)
id: b7f4a2d1-3c9e-4f8a-9c21-5ad0e6b41f73
name: cisco_asa_unexpected_reload
status: experimental
description: |
Detects a Cisco Secure Firewall ASA or FTD appliance emitting a traceback/watchdog message or
completing a boot sequence, without an operator initiated reload having been logged.
CVE-2026-20349 (CWE-244, CVSS 8.6, AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) lets an unauthenticated
remote attacker force an ASA or FTD device running Remote Access SSL VPN to reload. It is
availability only (C:N/I:N). There is no malware and no dropped file: the reload IS the observable.
LOG SOURCE (read before deploying):
Cisco ASA / FTD Lina syslog forwarded to the SIEM. Level 6 logging is required, because
199002 and 199005 are severity 6 and will be dropped by "logging trap errors".
ASSUMED FIELD NAMES (map these to your parser, do not deploy as is):
message_id : numeric ASA syslog id WITHOUT the "%ASA-<sev>-" prefix, e.g. 199005.
Splunk Cisco ASA TA "message_id"; Elastic ECS "cisco.asa.message_id";
Sentinel CommonSecurityLog "DeviceEventClassID". If your parser keeps the whole
"%ASA-1-199010" token, change these to message_id|endswith. If it stores the id
as an integer, drop the quotes.
message : free text remainder of the syslog line ("msg", "Message", "_raw").
hostname : device identity used for grouping ("host", "dvc", "observer.name").
DISCRIMINATOR AND ITS LIMIT: the real "unexpected" test is temporal absence, no %ASA-5-199001
from the same device in the preceding ~30 minutes. Plain Sigma cannot express absence of a prior
event, so implement that as a suppression/join in the SIEM, and treat filter_main_operator_reload
as a parser guard only.
references:
- https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-dzv4mQFF
- https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/asa-syslog/syslog-messages-101001-to-199021.html
- https://www.cisco.com/c/en/us/support/docs/security/adaptive-security-appliance-asa-software/217663-troubleshoot-asa-or-ftd-unexpected-reloa.html
author: CVE Brief (AI-generated starter rule)
date: 2026-08-14
tags:
- attack.impact
- attack.t1499.004
- cve.2026-20349
logsource:
product: cisco
service: asa
detection:
selection_traceback:
message_id:
- '199010' # Signal N caught in process/fiber at address X
- '199012' # Stack overflow during new_stack_call in process/fiber
- '199021' # Memory utilization reached watchdog trigger level. System will now reload.
selection_boot:
message_id:
- '199005' # Startup begin
- '199002' # startup completed. Beginning operation.
filter_main_operator_reload:
message|contains: 'Reload command executed'
condition: 1 of selection_* and not filter_main_operator_reload
fields:
- hostname
- message_id
- message
falsepositives:
- Planned maintenance windows and scheduled software upgrades or ASA/FTD image installs
- Operator initiated reloads from console, SSH or ASDM, which may not emit %ASA-5-199001 at all
- Power loss, PDU work, UPS transfer and other facility events
- Hardware faults (memory, PSU, fan, ASIC) and RMA hardware replacement
- Unrelated software defects that traceback the box, this rule cannot attribute a crash to a CVE
- HA failover testing, switchover drills and standby unit reboots after config sync
- Memory pressure reloads (199021) driven by capacity or config bloat rather than an attacker
- Lab, spare and non VPN ASA/FTD devices, exclude any device with no Remote Access SSL VPN enabled
- SIEM re-ingestion or replay of historical logs, which can synthesise a fake crash loop
level: medium
---
title: Cisco ASA/FTD Repeated Unexpected Reloads in One Hour (Crash Loop)
id: 0e5c8a34-7d61-4b2f-ae09-3c47d92be518
status: experimental
description: |
Two or more unexpected reload or traceback events from the same ASA/FTD appliance within one hour.
A single reload is ambiguous and mostly benign. A crash loop on an internet facing VPN headend is
not: maintenance reboots a device once, an attacker holding the trigger reboots it repeatedly.
For the estate wide variant (one actor sweeping several headends), remove the group-by or group by
a constant site field instead of hostname, and keep the same timespan.
references:
- https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-vpn-dos-dzv4mQFF
author: CVE Brief (AI-generated starter rule)
date: 2026-08-14
tags:
- attack.impact
- attack.t1499.004
- cve.2026-20349
correlation:
type: event_count
rules:
- cisco_asa_unexpected_reload
group-by:
- hostname
timespan: 1h
condition:
gte: 2
falsepositives:
- Boot sequences that legitimately emit both 199005 and 199002, tune by matching 199002 only if
your pipeline forwards both and the pair alone trips the count
- Upgrade procedures that reboot a device twice (image install then activation)
- Failover pair maintenance where both units are rebooted inside the same window
- Hardware that is genuinely failing and looping on its own
level: high
Rule notes
The base rule fires on ASA crash and boot indicators (199010 traceback, 199012 stack overflow, 199021 memory watchdog reload, 199005 startup begin, 199002 startup completed), and the paired correlation rule escalates when one appliance does it twice in an hour, which is the real signal since a single reload is usually maintenance. All message IDs were verified against Cisco's published ASA syslog message reference. There is no ASA message whose text is "unexpected reload", so the substitute is the boot pair with no preceding operator reload.
Two limitations matter. The rule detects reloads, not exploitation, and it cannot attribute a crash to this CVE: correlate every hit against change tickets and a fresh crashinfo file on the box. And plain Sigma cannot express the absence of a preceding %ASA-5-199001, so the operator-reload suppression has to be built as a temporal join in your SIEM rather than relying on the inline filter.
For scanner-based inventory, Qualys published QIDs 317873 and 317874 for this CVE.
References