One Crafted Request From a Reload: Inside CVE-2026-20349 on Cisco Secure Firewall ASA and FTD
The bug in one sentence
If your ASA or FTD device has IKEv2 Remote Access VPN, SSL VPN, or Zero Trust Network Access enabled, and an attacker can reach it, a single crafted HTTP request to that service is enough to reload the device. No credentials, no user interaction, no clicking anything. Cisco disclosed CVE-2026-20349 on August 11, is already tracking active exploitation, and CISA added it to the Known Exploited Vulnerabilities catalog with a same-week remediation deadline for federal agencies.
What’s actually broken
Cisco’s advisory (cisco-sa-asaftd-vpn-dos-dzv4mQFF) puts the root cause plainly: insufficient error checking when processing HTTP requests to the Remote Access SSL VPN service. Send it a request it doesn’t handle correctly, and instead of rejecting it or logging an error, the device reloads. CVSS 3.1 base score is 8.6, built entirely from an availability impact, there’s no confidentiality or integrity component here. This is a pure denial of service, not a foothold.
The vulnerability lives specifically in the code path that handles SSL listen sockets, which get opened by three different features:
| Feature | What turns the socket on |
|---|---|
| IKEv2 Remote Access VPN (with client services) | crypto ikev2 enable <interface> client-services port <port> |
| SSL VPN | webvpn / enable <interface> |
| Zero Trust Network Access (FTD only) | zero-trust / enable |
If none of those are configured, the device isn’t exposing the vulnerable listener and isn’t affected. If any one of them is, the whole box is a single crafted request away from an unscheduled reboot. Cisco confirmed Secure Firewall Management Center (FMC) software itself is not vulnerable, this is squarely a data-plane appliance problem, not a management-plane one.
Fixed releases, no workaround
There’s no mitigation here beyond patching. Cisco’s advisory is explicit: “There are no workarounds that address this vulnerability.” The fix ships as hot fixes rather than a full version bump, which matters for how you plan the change:
ASA: 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. Note the 89.x naming for the 9.16 and 9.18 hot fixes specifically, and that older ASDM releases won’t recognize that numbering scheme, so ASDM needs bumping to 7.24.1.374 alongside it or the GUI will misreport the version.
FTD: hot fixes exist for 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0, each shipped as a signed .sh.REL.tar package (with separate builds for SSP, FP1K, FP2K, and FP3K chassis variants), installed through FMC rather than the device CLI directly.
Cisco’s own Software Checker tool is the fastest way to confirm which hot fix a given running version needs, since the mapping isn’t a simple “upgrade to the next minor release” and getting it wrong means reapplying the change window.
Why this one’s worth taking seriously even though it’s “just” a DoS
It’s tempting to file an unauthenticated DoS lower on the priority list than an auth bypass or an RCE, and on a lot of devices that instinct is fine. It doesn’t hold up as well for a VPN concentrator. The whole reason an ASA or FTD box runs the Remote Access VPN feature in the first place is that it’s the thing remote users depend on to get in at all. A crafted HTTP request that anyone on the internet can send, with no login and no user interaction, that reliably reloads the device, is an outage an attacker can trigger on demand against every remote worker behind it. Repeatable, remote, unauthenticated denial of service against edge infrastructure is exactly the kind of bug that gets weaponized quickly once it’s public, whether or not it ever escalates past a reload.
It’s also a reminder that “unauthenticated” cuts both ways at the VPN edge. The IPsec Deep Dive series spent three parts on what has to happen correctly before a tunnel comes up, proposals, Diffie-Hellman, SA negotiation, all of it deliberately exposed to the world so a legitimate remote user can reach it without a bootstrap problem. That same exposure is exactly what CVE-2026-20349 abuses. The service has to listen for unauthenticated connections to do its job, and this bug lives in the code that runs before authentication is even attempted.
Cisco credits its own internal testing alongside an independent report from security researcher Valerio Brussani, and hasn’t published indicators of compromise, so there’s nothing specific to hunt for in logs beyond an unexplained reload correlating with VPN traffic. If you’re running any of the affected ASA or FTD releases with RA VPN or ZTNA turned on, the only real answer here is the hot fix. The zero-trust convergence post makes the broader case for collapsing VPN and ZTNA enforcement onto identity-aware policy rather than a flat network perimeter, but that argument is about reducing blast radius after access, not about this class of bug. A pre-authentication crash in the listener itself doesn’t care what your access model looks like once someone’s in.