CVE-2026-20349: Cisco ASA and FTD DoS Vulnerability Actively Exploited — Detection and Remediation Guide

Cisco has confirmed that a high-severity vulnerability in its Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software is being exploited in the wild. Tracked as CVE-2026-20349 with a CVSS score of 8.6, the flaw stems from insufficient error checking when processing HTTP requests and allows an unauthenticated, remote attacker to trigger a denial-of-service condition on the device.

Let that sink in: an attacker on the internet, with no credentials, can knock your perimeter firewall offline. For organizations where ASA/FTD appliances terminate VPN, AnyConnect, and site-to-site tunnels, a forced reload means dropped sessions, broken tunnels, and — depending on your redundancy design — a full outage window. Worse, adversaries have historically used perimeter-device DoS as a precursor to distraction campaigns or to force failover to less-monitored paths.

If you run ASA or FTD appliances with HTTP-accessible services exposed (AnyConnect/Clientless SSL VPN portals, REST API interfaces, or management web services), treat this as an emergency change, not a routine patch cycle.

Technical Analysis

Affected Products

• Cisco Secure Firewall ASA Software — any release train running web-facing services (webvpn, AnyConnect, ASDM, REST API) on exposed interfaces
• Cisco Secure Firewall FTD Software — managed via FMC or FDM, where threat defense instances process HTTP requests on inspection or remote-access VPN surfaces

These are the same platforms that have absorbed repeated attacker attention over the past two years, from ransomware groups to nation-state actors. Perimeter devices are the crown jewels of initial-access campaigns — and a remote crash primitive is valuable even to actors who can't yet get code execution.

The Vulnerability

CVE-2026-20349 is classified as insufficient error checking when processing HTTP requests. From a defender's perspective, the exploitation model is straightforward and dangerous:

1. The attacker sends a malformed or specially crafted HTTP request to an exposed web service on the ASA/FTD device.
2. The HTTP request-processing code path fails to validate an error condition, sending the device into a fault state.
3. The result is a denial of service — typically a device crash/reload on ASA-class platforms, dropping all transit traffic, VPN tunnels, and inspection functions until the appliance recovers.

Key characteristics that drive the 8.6 severity:

• No authentication required — the attack surface is reachable pre-auth, which is precisely why perimeter web portals are targeted.
• Remote, network-based exploitation — single request class, no user interaction.
• Availability impact only — there is no evidence of code execution or configuration manipulation from this specific flaw, but a reload loop or repeated crashes effectively takes the enforcement point offline indefinitely.

Exploitation Status

Cisco has stated the vulnerability has been exploited in the wild. This is not theoretical. Given the pattern of ASA/FTD targeting in recent campaigns, assume opportunistic scanning is already underway against internet-reachable devices. Check the Cisco Security Advisory and monitor CISA's Known Exploited Vulnerabilities catalog — KEV listing would impose a mandated remediation deadline for federal agencies and a strong signal for everyone else.

Detection and Response

The honest challenge: this vulnerability lives on the network appliance itself, not on an endpoint, so traditional EDR telemetry won't help you. Your detection strategy has to lean on ASA/FTD syslog, upstream web/proxy telemetry, and network flow data. If you're not already forwarding ASA syslog (and ideally FMC eStreamer data) into your SIEM, that gap is now operationally critical.

The highest-fidelity behavioral indicators to hunt for:

• A sudden spike in HTTP requests — particularly single-source or small-source-set floods — against the firewall's web services immediately preceding a device reload
• ASA syslog reload/crash events correlating temporally with inbound connection storms
• Repeated short-lived connections to TCP 443 on the firewall's outside interface from rotating source IPs (automated exploitation attempts)

---
title: HTTP Request Flood Against Cisco ASA or FTD Web Services
id: 3c8f4a21-6b2e-4d19-9c07-5e1a8f3b2d44
status: experimental
description: Detects a high volume of HTTP requests directed at Cisco ASA/FTD web-facing services (AnyConnect, clientless SSL VPN, ASDM, REST API), consistent with exploitation attempts against CVE-2026-20349 which triggers DoS via crafted HTTP requests.
references:
  - https://thehackernews.com/2026/08/cisco-asa-and-ftd-flaw-exploited-in.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.impact
  - attack.t1498
logsource:
  product: cisco
  service: asa
detection:
  selection:
    dst_port: 443
    action: 'built'
    protocol: 'tcp'
  condition: selection | count(src_ip) by dst_ip > 200
  timeframe: 1m
falsepositives:
  - Legitimate AnyConnect connection bursts during shift changes or mass VPN reconnects
  - Load balancer health checks targeting webvpn portals
level: high
---
title: Cisco ASA or FTD Device Reload Following Inbound Connection Storm
id: 8d2e6c45-1a9f-4b38-8e62-7c4d9f1a5e23
status: experimental
description: Detects ASA/FTD reload or crash events in syslog that may indicate successful exploitation of CVE-2026-20349. Correlate with preceding inbound HTTP request volume for confirmation.
references:
  - https://thehackernews.com/2026/08/cisco-asa-and-ftd-flaw-exploited-in.html
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.impact
  - attack.t1499
logsource:
  product: cisco
  service: asa
detection:
  selection:
    message|contains:
      - 'Reload requested'
      - 'crashinfo'
      - 'reboot'
      - 'System reload'
      - 'Unrecoverable error'
  condition: selection
falsepositives:
  - Scheduled maintenance reloads
  - Power events or UPS-triggered restarts
level: critical

Tune the count threshold in the first rule against your baseline AnyConnect portal traffic — 200 requests/minute per destination is a starting point, not gospel. If you run a heavily used clientless portal, raise it; the anomaly you care about is a traffic spike from a narrow source set immediately before an availability event.

// Hunt: HTTP request bursts against ASA/FTD web services followed by reload events
// Requires ASA syslog ingestion into Sentinel via CEF/Syslog connector
let lookback = 24h;
let web_requests =
    CommonSecurityLog
    | where TimeGenerated > ago(lookback)
    | where DeviceVendor == "Cisco"
    | where DeviceProduct has_any ("ASA", "Firepower", "FTD")
    | where DestinationPort == 443
    | where Message has_any ("Built", "built", "Teardown", "HTTP")
    | summarize RequestCount = count(), DistinctSources = dcount(SourceIP)
        by DestinationIP, bin(TimeGenerated, 5m)
    | where RequestCount > 500;
let reload_events =
    Syslog
    | where TimeGenerated > ago(lookback)
    | where SyslogMessage has_any ("Reload requested", "crashinfo", "System reload", "Unrecoverable")
    | project ReloadTime = TimeGenerated, HostIP, SyslogMessage;
web_requests
| join kind=inner (reload_events)
    on $left.DestinationIP == $right.HostIP
| where ReloadTime between (TimeGenerated .. TimeGenerated + 15m)
| project DestinationIP, Window = TimeGenerated, RequestCount, DistinctSources, ReloadTime, SyslogMessage
| order by ReloadTime desc

This query is deliberately correlation-based rather than volume-only: a request storm alone might be legitimate, and a reload alone might be maintenance. The 15-minute window between an anomalous request burst and a reload on the same device is your high-confidence exploitation signal. If your ASA logs don't carry per-request granularity, adapt the first leg to count Built inbound TCP connection events to 443 instead.

-- Velociraptor: hunt ASA syslog archives on log collectors for DoS exploitation indicators
-- Run against syslog aggregation hosts where ASA/FTD logs are archived
-- Adjust the glob path to your collector layout (rsyslog, Splunk UF, Graylog sidecar, etc.)
SELECT File, Line,
       timestamp(string=split(string=Line, sep=':')[0]) AS LogTime,
       Line AS RawEvent
FROM foreach(
    row={
        SELECT FullPath AS File
        FROM glob(globs='/var/log/remote/**/*.log')
    },
    query={
        SELECT Line, File
        FROM parse_lines(filename=File)
        WHERE Line =~ '(Reload requested|crashinfo|System reload|Unrecoverable error)'
           OR Line =~ '443.*built.*inbound'
    })
ORDER BY RawEvent DESC

The VQL artifact assumes you've been collecting ASA syslog to a central Linux collector — if you haven't, deploying Velociraptor to your log host and running this hunt is a fast forensic look-back for prior crashes that may have been quietly dismissed as hardware flakiness. In my IR experience, "the firewall randomly rebooted twice last month" is frequently the first retroactive indicator of perimeter exploitation.

#!/bin/bash
# CVE-2026-20349 exposure inventory and hardening check for Cisco ASA/FTD
# Requires: sshpass or SSH keys, admin access to ASA devices
# Usage: ./asa_cve_2026_20349_check.sh devices.txt
# devices.txt format: one management IP or hostname per line

DEVICE_LIST="${1:-devices.txt}"
SSH_USER="${SSH_USER:-admin}"
REPORT="asa_cve_check_$(date +%Y%m%d).csv"

echo "device,version,webvpn_enabled,http_exposed_outside,rest_api,notes" > "$REPORT"

while read -r DEVICE; do
  [ -z "$DEVICE" ] && continue
  echo "[*] Checking $DEVICE"

  VERSION=$(ssh -o ConnectTimeout=10 -o StrictHostKeyChecking=no "${SSH_USER}@${DEVICE}" \
    "show version | include Cisco Adaptive Security Appliance" 2>/dev/null)

  WEBVPN=$(ssh -o ConnectTimeout=10 "${SSH_USER}@${DEVICE}" \
    "show run webvpn | include enable" 2>/dev/null)

  HTTP_SRV=$(ssh -o ConnectTimeout=10 "${SSH_USER}@${DEVICE}" \
    "show run http" 2>/dev/null)

  REST=$(ssh -o ConnectTimeout=10 "${SSH_USER}@${DEVICE}" \
    "show run rest-api" 2>/dev/null)

  echo "${DEVICE},${VERSION:-unknown},${WEBVPN:+enabled},${HTTP_SRV:+configured},${REST:+enabled},review-against-cisco-advisory" >> "$REPORT"
done < "$DEVICE_LIST"

echo "[+] Report written to $REPORT"
echo "[!] Cross-reference all discovered versions against the Cisco Security Advisory fixed-release table for CVE-2026-20349"
echo "[!] For FTD: verify fixed versions via FMC > System > Updates, and confirm managed device upgrade state"

The script inventories your ASA fleet's version strings and HTTP-facing configuration (webvpn enablement, HTTP server config, REST API status) so you can quickly scope exposure. For FTD, version verification and upgrades flow through FMC — the script's reminder line stands; automate FMC API checks if you have more than a handful of managed devices.

Remediation

1. Patch immediately. Consult the official Cisco Security Advisory for CVE-2026-20349 at sec.cloudapps.cisco.com/security/center/publicationListing.x for the fixed-release table — fixed versions vary by release train, and I will not quote specific build numbers here because they must come from Cisco's advisory for your exact train. For FTD, apply the hotfix or upgrade through FMC and verify managed devices complete the deployment.

2. Reduce the attack surface today — before the patch window. If the vulnerable HTTP-processing path is reachable via AnyConnect/webvpn, ASDM, or the REST API, restrict who can reach it:

• Disable ASDM/HTTP server access from any interface where it is not operationally required (no http server enable or scoped http <network> <mask> <interface> rules).
• Disable the REST API agent if unused (no rest-api agent).
• If clientless SSL VPN is enabled but unused, disable it; keep only the AnyConnect profile you actually need.
• Place upstream ACLs on your edge router limiting inbound 443 to the firewall to known egress geographies or partner ranges where feasible.

3. Check CISA KEV and your sector obligations. If CVE-2026-20349 lands in the Known Exploited Vulnerabilities catalog, federal civilian agencies face a Binding Operational Directive deadline — and any organization treating KEV as its patch-priority signal (as it should) moves this to the front of the queue.

4. Monitor for pre-patch compromise indicators. Review the last 60–90 days of ASA logs for unexplained reloads, crashinfo files, and request bursts. A history of "mysterious reboots" on an internet-facing ASA warrants a deeper forensic look — pull the crashinfo, review running-config drift against known-good, and check for unauthorized local accounts or certificates. Cisco Talos incident response guidance covers ASA integrity checks in detail.

5. Verify failover actually works. Organizations frequently discover during a DoS event that their standby unit was misconfigured, out of license compliance, or running a divergent software version. Test stateful failover this week, not during the incident.

6. Forward your logs. If ASA syslog and FMC events are not flowing into your SIEM with alerting on reload events, you are blind to exactly the exploitation pattern described above. That is the single most durable lesson of this advisory.

The Bottom Line

CVE-2026-20349 is the latest entry in an unbroken pattern: perimeter appliances are the most contested terrain in enterprise security, and Cisco ASA/FTD specifically remains a favored target because of its ubiquity and its position as both enforcement point and VPN concentrator. An 8.6 unauthenticated remote DoS with confirmed in-the-wild exploitation is not a "next maintenance window" item. Scope your exposure, patch on an emergency cadence, restrict HTTP-facing services in the interim, and make sure your telemetry would actually catch the crash when it happens.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub