There is an unwritten hierarchy nearly all of us have fallen into: if data is stolen it is a serious incident, if data is altered it is a serious incident, and if the box goes down… well, that is an outage. You call support, it reboots, you move on. The advisory Cisco published on 11 August picks a fight with that hierarchy, and CISA picked a harder one: two hours and twenty minutes after the advisory went out, the flaw was in the known exploited vulnerabilities catalog with a three-day deadline.
We do not resell Cisco or any other firewall vendor, so this is not about defending anybody. It is about the conversation worth having with anyone who runs a remote access VPN concentrator at the edge of their network: availability is not confidentiality's little sister. It is the one that actually happens to you.
What the flaw actually does
CVE-2026-20349 affects Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD). The cause, according to the advisory, is insufficient error checking while processing HTTP requests: a remote, unauthenticated attacker sends a crafted request to the remote access SSL VPN service and the appliance reloads. Nothing more, and nothing less. The vector says it plainly: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, base score 8.6. Confidentiality, none. Integrity, none. Availability, high.
One thing a technical reader will spot straight away is worth saying out loud: both the advisory and CISA's catalog classify the flaw as CWE-244, an information exposure category, and CISA titles it "Heap Inspection Vulnerability". That sounds like a leak. But the advisory's own description is about error checking while processing HTTP, and the vector shuts the door on the interpretation: C:N/I:N. We go with the vector, which is what Cisco signs its name to on impact.
The advisory sets two conditions at once: an affected version, and one of these three configurations —the ones that can bring the SSL listening sockets up. You check it by looking at the configuration:
- •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.
Cisco has released hot fixes for ASA 9.16, 9.18, 9.20, 9.22, 9.23 and 9.24, and for FTD 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0; for your exact build the advisory points you at its Software Checker. The Management Center (FMC) is not affected. And the sentence that takes improvisation off the table: "there are no workarounds that address this vulnerability." No magic ACL, no setting you can turn off without turning off the service too. Either you patch, or you stop offering VPN.
Cisco published the advisory on 11 August at 16:39 GMT and says its PSIRT became aware of active exploitation in August 2026. It has given no detail: not who is exploiting it, not against whom, not how many. In practice that means exactly one useful thing: somebody already has a working method.
The clock on 11 August
The hours of that day tell the story better than the score does. Cisco published the advisory at 16:39 GMT. The version of the Known Exploited Vulnerabilities (KEV) catalog that includes it is timestamped 18:59 GMT the same day. Three vulnerabilities went in with that version, not one more, and they came out with two different due dates:
- •CVE-2026-20349 (Cisco ASA/FTD) — due: 14 August. Three days.
- •CVE-2026-72898 (Metabase) — due: 14 August. Three days as well, and we wrote about that one on Monday, when it still had no CVE assigned.
- •CVE-2026-68820 (Windows AFD driver) — due: 25 August. Fourteen days.
The catalog's required action points to directive BOD 26-04, which replaced the old flat deadline with risk-based prioritisation: exposure, automatability, impact and evidence of exploitation. Translated: whatever sits at the edge, faces the internet and can be exploited without credentials moves to the short tier. What sets the deadline is no longer the severity of the damage, it is how easily somebody can reach you. And an internet-facing VPN service is, by definition, the easiest place to reach.
Those deadlines bind US federal civilian executive branch agencies, not a company in Manresa or Barcelona. But we have long used the catalog as what it really is: a list of what is already being exploited out there, compiled by people who do not sell patches. When something enters KEV with three days on it, the interesting question is not whether it binds you. It is what CISA knows that nobody has told you.
A reload here is not an annoyance: it is the switch for your entire workforce
A web server going down is a nuisance. A VPN concentrator going down does something else: it locks out everyone who is not physically in the office. Sales people, field engineers, everyone working from home, the supplier who was about to connect for scheduled maintenance, and —this is the one that hurts— the very ops team that needs to get in to fix it. If your management plane runs through the same tunnel that just reloaded, you do not have a network incident: you have a network incident and you are blind on top of it.
It is the same reasoning we apply to zero-days in perimeter VPN portals: the box you installed so nobody could get in without permission is also the single point that switches off everybody's work if it falls over. Almost no other device on your network carries both of those roles.
And the patch cuts you off too
This is the operational trap almost nobody mentions when they write "patch now". Upgrading a VPN concentrator drops active sessions. If you have an HA pair and a well-rehearsed cycle, you get away with a minor inconvenience. If you have a single appliance —which is the norm in a small company— the mitigation costs exactly what the attack costs: your people locked out for a while. The difference is that you get to choose when.
And it pays to read the small print before the window, not during it. Cisco has released hotfixes per train and per platform (FTD has model-specific variants), and it flags one detail that can ruin a night shift: for hotfixes whose numbering starts with "89" you must also install ASDM 7.24.1.374, because earlier ASDM versions do not recognise the revised ASA numbering format. A patched appliance you can no longer manage from the GUI is a brand new problem, created at four in the morning.
What we look at when an advisory like this lands
Patching is the easy part and the part everybody writes about. What separates a busy afternoon from a lost day is everything next to it:
- ✓Which version you actually run, not the one in the inventory. The train and build, compared against the advisory table.
- ✓Whether the socket is genuinely up. An ASA with no remote access VPN enabled is not vulnerable to this, and saying so avoids pointless maintenance windows.
- ✓Who gets locked out during the window and who cannot be locked out. On-call staff, night shifts, people in another time zone, supplier integrations. That list is almost never written down, and it is the one that picks the hour.
- ✓The second path into the management plane, independent of the tunnel you are touching. Out-of-band console, a jump host on another route, something. If the only way in is the thing you are about to reload, you do not have a plan: you have faith.
- ✓What can be detected while you line up the window. The advisory links two Snort rules (46897 and 59654). They are not a workaround —there is none— but they answer the question everybody asks: if I cannot patch until Saturday, will I at least know?
- ✓How long it really takes to come back. Not the estimate: the time measured last time round. If nobody has ever measured it, tonight's window is your chance.
When this does not concern you
We say this because the noise of the last few days has people running for no reason: if you have no ASA or FTD, this does not concern you. If you have them but none of the three configurations in the advisory —site-to-site tunnels only, and no Zero Trust enabled on the FTD— it does not either. And if you are already on a hot-fixed release, you are done. The reading that does apply to everyone is the other one, and it does not expire with this CVE: work out what happens in your company on the day remote access is not there. That rehearsal does not depend on which vendor sits at your edge.
The short version
A flaw that steals nothing has just been given the same deadline as the worst entries in the catalog, because what gets measured is no longer what they do to you but where they can do it from. In your case nobody signs the deadline: you do. And the question this advisory leaves behind, once the hotfix is in, is the usual one: if remote access does not come up tomorrow, how many of your people cannot work, and how long would it take you to know?
Sources (consulted on 14 August 2026): flaw description, CVSS vector, vulnerable configurations, absence of workarounds, affected versions, the ASDM 7.24.1.374 note, the CWE-244 classification, the linked Snort rules and PSIRT awareness of active exploitation — Cisco security advisory cisco-sa-asaftd-vpn-dos-dzv4mQFF; addition dates and due dates for the three 11 August entries, plus the reference to directive BOD 26-04 — CISA KEV catalog (data read directly from the published JSON file); risk-based prioritisation criteria — BOD 26-04. Cisco has published no information about attackers or victims; any claim about specific campaigns today would be speculation.
How long does your company last without remote access?
At everyWAN we treat compliance and continuity as what they are: a rehearsal, not a document. We look at what falls with you, who gets locked out, and how you get in when the usual door is not there.
Talk to everyWAN