Cisco Secure Firewall CVE-2026-20349: What It Is, Who’s Exposed, and How to Patch (with Commands)

Quick answer: CVE-2026-20349 is an unauthenticated, remote denial-of-service (DoS) vulnerability in the remote-access SSL VPN of Cisco Secure Firewall ASA and FTD software, scored CVSS 8.6 (High). A remote attacker with no credentials sends a single crafted HTTP request and the firewall reloads, dropping the VPN for every remote worker. It is being actively exploited in the wild, there is no configuration workaround, and the only fix is to upgrade to a fixed release. The exact steps and commands are below.

What is the Cisco Secure Firewall (ASA and FTD)?

The Cisco Secure Firewall is an enterprise firewall appliance — one of the most widely deployed on Earth. It runs one of two software “brains.” ASA (Adaptive Security Appliance) is the classic, battle-tested firewall and VPN operating system. FTD (Firepower Threat Defense) is the modern one, a next-generation firewall with intrusion prevention, malware defense, and URL filtering built in. Think of the box as both the front door and the guard for a company’s entire network.

It does two jobs almost everywhere it’s deployed. First, it’s the perimeter — the wall between the public internet and everything inside. Second, it’s the remote-access VPN: when someone works from home, they connect through this box. Cisco’s Secure Client — which you may still know as AnyConnect — builds an encrypted SSL/TLS tunnel straight into it. That second job is exactly where CVE-2026-20349 lives.

You’ll find it at the internet edge, in the data center, and in branch offices — guarding banks, hospitals, universities, and Fortune 500 networks. Models range from a small Firepower 1000 for a branch, to a Secure Firewall 4200 for a data center, to a 9300 chassis for a carrier, priced from a few hundred dollars to tens of thousands plus yearly threat-feature licenses. Engineers manage it over a command line, the ASDM desktop app, or — for large fleets — Cisco’s FMC (Firepower Management Center). To turn on the remote VPN, an engineer enables WebVPN on the outside interface. One command, and the front door opens to the internet.

What is CVE-2026-20349?

The flaw is in how the remote-access SSL VPN handles a particular kind of HTTP request. Because one request type isn’t validated carefully enough, an unauthenticated attacker — from anywhere on the internet, with no password — can send a single crafted request that forces the device to reload. Read that again: no login, no malware, no data theft. Just one bad request, and your firewall restarts. Send it again and again, and the box keeps falling over: the VPN goes down, every remote worker is locked out, and the business stops. It’s a knockout, not a break-in.

Cisco’s advisory lists the affected software trains and the fixed release for each. The affected versions below are representative — always confirm your exact build against the Cisco Software Checker on the advisory page, because the specific fixed maintenance release depends on the train you run.

Am I exposed? How to check on the device

You are only exposed if the remote-access SSL VPN (WebVPN) is enabled on an internet-facing interface. Two things decide your risk: your software version, and whether WebVPN is turned on. Check both directly on the box.

On an ASA, from enable mode:

! Current software version
show version | include Version

! Is remote-access SSL VPN (WebVPN) enabled, and on which interface?
show running-config webvpn

! TLS/SSL listeners and the interfaces they answer on
show running-config ssl
show asp table socket | include SSL

If show running-config webvpn shows enable <outside-interface>, the VPN is listening to the internet and this CVE applies to you. On FTD, check the running version and the RA-VPN configuration in FMC (Devices → VPN → Remote Access) or on FTD via the CLI:

> show version
> show running-config webvpn
> show running-config ssl

How to patch Cisco Secure Firewall for CVE-2026-20349

There is no configuration you can change to make this safe — the only fix is to run fixed software. Cisco published fixed releases for every affected train and, for some trains, a hot fix you can apply faster. The workflow below patches an ASA from the CLI, then covers FTD via FMC and FDM. Do this in a maintenance window: the upgrade itself requires a reload, and in a high-availability pair you patch the standby first.

Step 1 — Back up the config and confirm your fixed target

Snapshot the running configuration before you touch anything, and note the exact fixed release Cisco lists for your train (from the Software Checker on the advisory). On an HA pair, run show failover so you know which unit is active.

! Save a copy of the running config to local flash (and, ideally, off-box too)
copy running-config disk0:/backup-prepatch.cfg

! See which images are already on disk
show flash: | include \.SPA

! On an HA pair, identify active vs standby (patch the STANDBY first)
show failover

Step 2 — Download the fixed image from Cisco

Sign in to software.cisco.com with an account entitled to your device’s service contract, open Downloads for Secure Firewall ASA (or FTD), and download the fixed release Cisco lists for your train. Note the SHA-512 checksum shown next to the file — you’ll verify against it in the next step. Copy the image onto the firewall over a management path (FTP/SFTP/TFTP or via ASDM):

! Example: pull the fixed image from an internal SFTP/FTP server to flash
copy ftp://admin@10.0.0.5/asa9-24-1-fixed.SPA disk0:

! Confirm it landed
show flash: | include fixed

Step 3 — Verify the image, set it to boot, and reload

Verify the file integrity against Cisco’s published SHA-512 before you trust it. Then point the boot system at the fixed image, remove the old boot entry so the device can’t fall back to the vulnerable build, save, and reload during your window.

! 1) Integrity check — the output must match Cisco's published SHA-512
verify /sha-512 disk0:/asa9-24-1-fixed.SPA

! 2) Boot the fixed image; drop the old (vulnerable) boot entry
configure terminal
 boot system disk0:/asa9-24-1-fixed.SPA
 no boot system disk0:/asa9-24-0-vuln.SPA
end

! 3) Save and reload in your maintenance window
write memory
reload

! 4) After it comes back, confirm the fixed build is running
show version | include Version

On a failover pair, upgrade the standby first, verify it returns healthy, force a switchover so the patched unit becomes active, then upgrade the former-active unit — so the VPN never fully drops during the change.

Step 4 — Patch FTD (via FMC or FDM)

FTD is upgraded through its manager, not by hand-swapping a boot image. If you run FMC (multi-device management):

• In FMC, go to System → Updates → Product Updates and upload the fixed FTD upgrade package (or the hot fix, if Cisco published one for your train).
• Go to Devices → Device Management, select the affected firewalls, and choose Upgrade → Firepower Software.
• Run the Readiness Check, then run the upgrade in your window, and finally Deploy so the fixed configuration is pushed.

If you run FDM (on-box management for a standalone FTD): go to Device → Updates → System Upgrade, browse to the fixed package, and run the upgrade. Either way, confirm the running version afterward with show version.

What if you can’t patch immediately?

Be honest with yourself: Cisco states there is no workaround, so there is no config toggle that removes the risk while the VPN stays internet-facing. Until you patch, reduce blast radius and watch closely. If your remote users all originate from known networks, you can temporarily restrict which source addresses reach the VPN with a control-plane access list — this narrows exposure but is not a fix. Turn up monitoring for unexpected device reloads (syslog reload events and crashinfo files), and treat any unexplained VPN outage as a possible exploitation attempt. Then patch as fast as your change process allows — this bug is being exploited now.

Turn the CVE into a monitored control, not a fire drill

One firewall is easy to reason about. A fleet — plus every other internet-facing service you own — is not. This is exactly the gap attack surface management closes: continuously discovering what you expose to the internet, so a device running remote-access SSL VPN on a vulnerable build surfaces as a finding instead of a surprise. Start with a free external attack-surface scan to see what’s already reachable from the outside.

CATAAM’s discipline is turning a headline CVE into a specific obligation. A confirmed exposure like this maps to the security control it breaks and rides your continuous control monitoring — for SOC 2, it’s a CC7 (system operations / vulnerability management) and CC6 (logical access boundary) concern, evidenced by the patch itself. We track vulnerabilities like this the day they land, map them to your controls, and tell you whether the box on your edge is exposed. It’s the same pattern we walked through for the Oracle E-Business Suite zero-day and the agentic-AI API-key leak.

The internet’s most trusted firewall just became one of its most tempting targets. The device isn’t the problem — an unpatched device is. Confirm your version, apply Cisco’s fixed release, and make sure the exposure never quietly comes back.

Frequently asked questions

What is CVE-2026-20349?

CVE-2026-20349 is an unauthenticated, remote denial-of-service vulnerability in the remote-access SSL VPN (WebVPN) of Cisco Secure Firewall ASA and FTD software, scored CVSS 8.6 (High). An attacker with no credentials sends a single crafted HTTP request and the device reloads, dropping the VPN. It is not remote code execution and does not expose data — the impact is an outage.

Is CVE-2026-20349 being actively exploited?

Yes. Cisco confirmed active exploitation in the wild in August 2026. There is no configuration workaround, so affected organizations should treat patching as urgent and apply Cisco’s fixed release (or the published hot fix) as quickly as their change process allows.

Am I affected by CVE-2026-20349?

You are affected if you run an impacted ASA or FTD software train with the remote-access SSL VPN (WebVPN) enabled on an internet-facing interface. Check with "show version" and "show running-config webvpn" on ASA, or the version and remote-access VPN configuration on FTD via FMC/FDM. If WebVPN is not enabled, this CVE does not apply.

How do I patch Cisco ASA for CVE-2026-20349?

Back up the config, download the fixed release for your train from software.cisco.com, copy it to the device, verify it with "verify /sha-512", set it with "boot system disk0:/<fixed-image>.SPA", remove the old boot entry, run "write memory", and "reload" in a maintenance window. On an HA pair, patch the standby first, switch over, then patch the former active unit. Confirm with "show version" afterward.

How do I patch Cisco FTD for CVE-2026-20349?

FTD is upgraded through its manager. In FMC, upload the fixed package under System → Updates, then use Devices → Device Management → Upgrade → Firepower Software, run the Readiness Check, upgrade, and Deploy. On a standalone FTD managed by FDM, use Device → Updates → System Upgrade. Verify the running version with "show version" when it returns.

Is there a workaround if I can’t patch immediately?

No. Cisco states there is no workaround while the remote-access SSL VPN stays internet-facing. As interim risk reduction you can temporarily restrict which source networks reach the VPN (if your users come from known ranges) and heighten monitoring for unexpected device reloads, but only upgrading to fixed software removes the vulnerability.