HowToFixMe
● High · CVSS 8.6 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2024-20353: Denial of Service in Cisco Adaptive Security Appliance (ASA) Software

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 8.6 - High (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H)
Actively exploited?Yes - CISA KEV (added 2024-04-24); used in the ArcaneDoor espionage campaign
Affected productsCisco ASA Software 9.8 through 9.20; Cisco Firepower Threat Defense (FTD) 6.2.3 through 7.4.1 - only when a management or VPN web server is enabled on an interface
Fixed inUpgrade to a release at or above Cisco's First Fixed list in advisory cisco-sa-asaftd-websrvs-dos-X8gNucD2 (e.g. ASA 9.16.4.57, 9.17.1.39, 9.18.4.22, 9.19.1.30, 9.20.2.10; FTD 7.0.6.2, 7.2.5.2, 7.3.1.3, 7.4.1.1). Confirm the exact build for your train in the advisory.
Type (CWE)CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') - unauthenticated remote denial of service, no RCE

Exploitation status

CVE-2024-20353 is actively exploited in the wild. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on as “Cisco ASA and FTD Denial of Service Vulnerability”, which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. Federal agencies were required to remediate it by . If you run an affected system, treat this as an emergency change, not a scheduled one.

Public exploit availability: public exploit code is referenced for this CVE, and its place on the CISA KEV catalog confirms working attack code is in active use in the wild: treat weaponization as certain and patch on an emergency timeline.

Authoritative references:

Patch immediately. CISA's KEV listing means active exploitation is confirmed. Federal agencies must remediate by 2024-05-01.

What is CVE-2024-20353?

CVE-2024-20353 is an unauthenticated, remote denial-of-service vulnerability in the management and VPN web servers built into Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software. Cisco's own description states the cause precisely: incomplete error checking when parsing an HTTP header. When the affected web server receives a crafted HTTP request, the parser enters a state it cannot recover from and the device reloads unexpectedly, dropping every session it was carrying.

The CWE classification is the important part here. This is CWE-835, a loop with an unreachable exit condition - an infinite loop, not memory corruption. There is no remote code execution and no data disclosure in this CVE: the CVSS vector (C:N/I:N/A:H) confirms the only impact is availability. A single malformed request forces the box to reboot, so an attacker who can reach the web server can hold an ASA or FTD firewall in a reboot cycle without ever authenticating. The scope is marked Changed (S:C) because the crash takes down traffic for everything behind the firewall, not just the web server process.

One scoping detail matters for triage: the device is only exposed if a web server is actually running on a reachable interface. That means HTTP/HTTPS management access (ASDM, the web management UI) or any of the clientless/AnyConnect SSL VPN features that stand up a web listener. A firewall with no web management and no SSL-VPN web service enabled does not present the attack surface for this bug.

Why this CVE matters

Denial-of-service flaws in a network gateway or firewall have an outsize operational impact. A single packet that reboots an inline device takes down everything behind it, which is why even a non-RCE availability bug on these products warrants emergency patching.

What pushes CVE-2024-20353 past the usual DoS calculus is the company it keeps. Cisco confirmed exploitation, and this CVE was one of two zero-days (alongside CVE-2024-20359) chained in ArcaneDoor, a state-sponsored espionage campaign that Cisco Talos disclosed in April 2024 targeting perimeter ASA devices. In that campaign the reload was not the end goal - it was used in concert with the persistence implant tracked as that operation, so an unexplained reload on an internet-facing ASA from this window is itself an indicator worth investigating, not just an outage to recover from. Patching closes the door; log review and credential rotation close out the rest of the response.

Spot the symptom

Two conditions must both be true for a device to be exploitable: it runs an affected software train, and a web server is enabled on a reachable interface.

Affected software trains, per Cisco's advisory and the CVE record:

Confirm your running release from privileged EXEC mode:

! On ASA:
show version | include Version

! On FTD via the CLI:
show version

! Check whether a web server is actually exposed (the prerequisite for this bug).
! HTTP/HTTPS management (ASDM):
show running-config http

! AnyConnect / clientless SSL-VPN web services that stand up a web listener:
show running-config webvpn

If show running-config http shows no http server enable line and webvpn has no enable <interface> on a reachable interface, the web attack surface is not present - but you should still patch, because leaving a known-exploited firewall on a vulnerable train is its own risk. If you cannot determine the version, treat the system as affected and follow the upgrade path below.

How to fix CVE-2024-20353

There is no workaround. Cisco was explicit that no configuration change mitigates this flaw - the only fix is to upgrade to a fixed software release. The fix is the same patch that closes CVE-2024-20359, so a single upgrade resolves both ArcaneDoor zero-days.

  1. Open the advisory and read its Fixed Software table: cisco-sa-asaftd-websrvs-dos-X8gNucD2. Find the First Fixed Release for your exact train. For ASA that is a release such as 9.16.4.57, 9.17.1.39, 9.18.4.22, 9.19.1.30 or 9.20.2.10; for FTD, a release such as 7.0.6.2, 7.2.5.2, 7.3.1.3 or 7.4.1.1. Newer maintenance builds in those trains are also fixed.
  2. Use the Cisco Software Download portal (or the Cisco Software Checker on the advisory page) to pull the matching image for your platform. A valid service contract is required for the download.
  3. Back up the running configuration before upgrading (copy running-config to an external store, or export from FMC for FTD).
  4. Apply the upgrade in a maintenance window. For an active/standby or active/active HA pair, upgrade the standby first, fail over, then upgrade the former active unit so the reload does not interrupt traffic.
  5. Reload onto the patched image and verify the running version (see below).

Upgrade a standalone ASA appliance

ASA images are upgraded by staging the .SPA image to flash, pointing the boot variable at it, and reloading. FMC-managed FTD is upgraded through the FMC System > Updates workflow instead of the ASA CLI shown here.

! Stage the fixed ASA image (replace with the First Fixed build for your train)
copy ftp://<fileserver>/asa9-16-4-57-smp-k8.SPA disk0:

! Point the boot variable at the patched image
configure terminal
boot system disk0:/asa9-16-4-57-smp-k8.SPA
end
write memory

! Reload in the maintenance window
reload

! After reload, confirm the patched release is running
show version | include Version

Verify the fix landed

! 1. Confirm the running release is at or above the First Fixed Release for your train.
show version | include Version

! 2. Confirm the web servers came back cleanly (only relevant if they are enabled).
show running-config http
show running-config webvpn

! 3. Look for the unexpected reloads that are the symptom of this bug,
!    and for the crashinfo files an exploit attempt can leave behind.
show crashinfo
dir disk0:/coredumpfsys/

! 4. Re-scan the device with your vulnerability scanner (Nessus, Qualys, Tenable).
!    It should no longer flag CVE-2024-20353 once the release is fixed.

If you cannot patch immediately

Cisco published no configuration workaround, so the honest answer is that you cannot fully mitigate this without upgrading. The only meaningful interim step is to shrink exposure: restrict which source addresses can reach the HTTP management interface (http <mgmt-subnet> <mask> <interface>) and the SSL-VPN portal to known administrative networks or a VPN-only management plane, so an unauthenticated attacker on the open internet can no longer reach the vulnerable web server. This reduces who can send the crafted request; it does not remove the underlying loop. Patch as soon as a window allows.

Full fix path

If your installation was internet-reachable during the disclosure window, treat log review as part of the remediation rather than an optional follow-up. Look for unexpected device reloads, crashinfo files, and core dumps generated around the time of any anomalous HTTP traffic to the management or VPN web server - the visible symptom of this infinite-loop bug is exactly that unscheduled reload. Because this CVE was used in the ArcaneDoor campaign, also follow Cisco's exploitation guidance from the advisory: monitor system logs for indicators of undocumented configuration changes, unscheduled reboots, and any anomalous credential activity, and pull the indicators of compromise published in the Cisco Talos ArcaneDoor write-up and CISA's KEV entry. If you find evidence of compromise rather than just a clean reload, rotate device credentials and certificates as part of recovery, since the reload in this campaign accompanied an attempt at persistence.

Frequently asked questions

Can CVE-2024-20353 be used for remote code execution?

No. This is a denial-of-service vulnerability classified as CWE-835 (a loop with no reachable exit - an infinite loop). The CVSS vector shows no confidentiality or integrity impact, only availability (C:N/I:N/A:H). A crafted HTTP header forces the ASA or FTD device to reload; it does not run attacker code. The catch is that it was chained with CVE-2024-20359 in the ArcaneDoor espionage campaign, so an unexplained reload on an exposed device is worth investigating, not just restarting past.

Is there a workaround for CVE-2024-20353 if I cannot upgrade yet?

Cisco published no configuration workaround. The only durable fix is upgrading to a fixed release. As interim risk reduction you can restrict which source networks can reach the HTTP management interface and the SSL-VPN web portal, which limits who can deliver the crafted request, but it does not remove the underlying loop.

Which release fixes CVE-2024-20353, and does it also cover CVE-2024-20359?

Upgrade to the First Fixed Release for your train from the Cisco advisory - for example ASA 9.16.4.57, 9.18.4.22 or 9.20.2.10, or FTD 7.0.6.2, 7.2.5.2 or 7.4.1.1. The same patched build also fixes CVE-2024-20359, the second ArcaneDoor zero-day, so one upgrade closes both. Always confirm the exact build for your specific train in the advisory before scheduling the change.

References

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Other CVEs touching related code paths, worth patching together with this one:

People also ask

Can CVE-2024-20353 be used for remote code execution?

No. It is a denial-of-service vulnerability (CWE-835, an infinite loop) with no confidentiality or integrity impact - the CVSS vector is C:N/I:N/A:H. A crafted HTTP header reloads the ASA or FTD device but does not run attacker code. It was chained with CVE-2024-20359 in the ArcaneDoor campaign, so investigate any unexpected reload on an exposed device.

Is there a workaround if I cannot upgrade yet?

Cisco published no configuration workaround; upgrading is the only fix. As interim risk reduction, restrict which source networks can reach the HTTP management interface and the SSL-VPN portal so an unauthenticated attacker on the open internet cannot deliver the crafted request.

Which release fixes CVE-2024-20353, and does it cover CVE-2024-20359?

Upgrade to the First Fixed Release for your train from advisory cisco-sa-asaftd-websrvs-dos-X8gNucD2 - for example ASA 9.18.4.22 or 9.20.2.10, or FTD 7.2.5.2 or 7.4.1.1. The same build also fixes CVE-2024-20359, the second ArcaneDoor zero-day, so one upgrade closes both.