One Malformed Request Crashes the Firewall. CISA Gave Three Days.

SAN JOSE, 15 AUG 2026 — CISA's deadline for CVE-2026-20349 expired yesterday. The flaw lets an unauthenticated attacker crash a Cisco firewall by sending it one malformed HTTP request, it is being exploited, and there is no workaround.

It is also, on paper, only a denial of service. No code execution, no data theft, nothing read or written. A medium-consequence bug class that has been handed a three-day federal clock and a place in the Known Exploited Vulnerabilities catalogue.

That combination is the story, and it is becoming a familiar one.

What the bug is

The remote access SSL VPN service fails to check errors properly when it processes HTTP requests, so a crafted request that reaches it will reload the device. Anyone who can talk to the VPN listener can do it, which by design is the whole internet.

Affected software covers Cisco Secure Firewall ASA releases 9.16, 9.18, 9.20, 9.22, 9.23 and 9.24, and Firewall Threat Defense releases 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0. The vulnerable condition requires remote-access services to be enabled: SSL VPN, IKEv2 remote access VPN with client services, or Zero Trust Network Access on FTD. A firewall with none of those configured is not exposed to this.

Cisco published on 11 August, said its incident response team had become aware of exploitation, and released branch-specific hot fixes rather than a single upgrade. It found the flaw in internal testing; the researcher Valerio Brussani reported it independently.

Why a crash gets treated like a breach

The instinct to treat a denial-of-service bug as a routine scheduling matter is wrong here, for reasons that have nothing to do with its severity score.

The device being crashed is a firewall that is also a VPN concentrator. Knocking it over takes out both the enforcement point at the perimeter and the path your remote staff use to work. This bug collapses two failures that usually have separate contingencies into a single event.

Consider what that looks like on a Monday morning. Nobody can connect. The security team cannot connect either, because they use the same VPN. The device reboots and comes back, so it looks like an availability incident rather than an attack. And it can be repeated at will, by anyone, from anywhere, as long as the listener is up.

For an attacker, the value is not the outage itself but the noise it creates. A firewall that reloads on a loop generates exactly the alert storm under which other activity is difficult to see, and it removes the appliance whose logs you would use to see it. Denial of service against a security control is rarely the objective; it is a diversion for a different attack.

Three days, and this time they were working days

CISA added the flaw to the catalogue on 11 August and set the federal remediation deadline at 14 August. Three days.

We have measured this trend before. Across all 1,653 catalogue entries the median remediation window fell from 21 days to three, and the change began in March, four months before the directive usually credited with it. Every vulnerability catalogued in the first week of August carried the same three-day clock.

In this case the three-day window was generous. Added Tuesday, due Friday: Wednesday, Thursday and Friday are all working days. Of the 32 three-day clocks we counted after the directive, ten contained a single working day, which is the shape that turns a deadline into a weekend. This one did not.

Even so, three working days to plan, test and apply a firmware update to a perimeter appliance is not generous, and the appliance in question cannot be patched quietly. Updating a VPN concentrator drops every session on it. Because the maintenance window looks exactly like the attack, organisations tend to defer this class of patch. That is the deferral now being taken away from them.

For teams here the federal deadline is not binding, but it is the best available signal of how fast the catalogue's authors think this is moving. If you want the same clock applied to your own estate, our KEV Remediation Deadline Calculator does the working-day arithmetic for a given catalogue date, and the CVSS 3.1 Base Score Calculator will show you how an availability-only impact still reaches 8.6.

Cisco's second entry in a fortnight

On 1 August we covered a hard-coded password in Cisco's Firewall Management Center, CVE-2026-20316, which scored 5.3 and still drew a three-day deadline plus an instruction to hunt for compromise.

Two Cisco security-appliance entries in the catalogue in two weeks, both on the management and access layer rather than in the traffic path. There is a pattern here: the flaws are not in the firewall's packet-filtering engine but in the web services bolted to its side. The management console, the VPN portal and the administrative interfaces are ordinary HTTP applications, with an ordinary HTTP application's security posture, running on a box everyone treats as a hardened boundary.

This should be uncomfortable for anyone whose architecture assumes the perimeter device is inherently trustworthy.

What to do, in order

First, determine whether you are in scope. If ASA or FTD is running without SSL VPN, IKEv2 remote access with client services, or ZTNA, this specific flaw does not apply. Check the configuration rather than assuming from the product name.

Second, patch. Cisco has published hot fixes per branch and there is no workaround, so there is no intermediate step available. Internet-facing VPN gateways go first.

Third, if you cannot patch inside the window, reduce reachability. Restricting which addresses can reach the VPN listener is imperfect for a service whose purpose is to accept connections from anywhere, but it narrows the population that can send the request.

Fourth, look back through your logs for unexplained reloads. An availability event on this device in the last fortnight deserves a second look now that there is a known unauthenticated crash for it.

What we could not establish

Who is exploiting this, against whom, and to what end. Cisco confirmed awareness of exploitation without naming actors or victims, and no public proof-of-concept had been disclosed at the time of the advisory.

It also remains unestablished how many devices are exposed, whether any ASEAN organisations are among the targets, whether the exploitation is targeted or opportunistic, and whether the crash is a diversion or the objective itself. The last of these is analysis on our part rather than a claim anyone has made.

What to watch

Keep an eye out for a public proof-of-concept. This class of bug is straightforward to reproduce once the request shape is known, and publication typically converts targeted exploitation into background noise within days.

Whether the impact assessment changes. Advisories are sometimes revised when the crash turns out to be the visible end of something with more reach, and an HTTP parsing error that reliably reloads a device is a memory-safety question with only one answer published so far.

And whether a third Cisco appliance entry arrives before the end of the month.