Somebody can reboot your office VPN from the internet, and there is no workaround
CVE-2026-20349 lets an unauthenticated attacker crash a Cisco ASA or Secure Firewall Threat Defense box with one crafted HTTP request to the remote access VPN. Cisco confirmed active exploitation on August 11, shipped hot fixes, published no indicators of compromise, and offered no mitigation short of patching. Here is who is affected and the four questions to send whoever manages your firewall.
If your staff connect to the office over a VPN and the box terminating that VPN is a Cisco firewall, this one is yours to deal with this week.
On August 11, 2026, Cisco disclosed CVE-2026-20349, a flaw in the remote access SSL VPN service of Secure Firewall ASA and Secure Firewall Threat Defense. An attacker with no account, no credentials, and no foothold sends one crafted HTTP request and the firewall reloads. Cisco rates it 8.6, confirmed it was already being exploited when the advisory went out, and said plainly that there are no workarounds. CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave US federal agencies until August 14 to fix it.
What the bug is, and what it is not
The cause is unglamorous: insufficient error checking while processing HTTP requests. Send the VPN service a request it handles badly and the device falls over and restarts.
The important qualifier is that this is denial of service only. It does not give an attacker a shell, it does not read your traffic, and it does not get anyone onto your network. Nobody is stealing your data with this bug.
That is a real limit and it is worth being clear about, because the security press does not always distinguish. But do not file it as harmless either. The device it crashes is the device your remote staff go through to work, and the crash is repeatable by anyone who can reach the VPN, which by definition is the entire internet. A vulnerability that lets a stranger take your remote workforce offline on demand, with no way to make them stop except patching, is an operational problem even if it is not a breach.
Whether you are affected
Two things have to be true.
A vulnerable version. ASA 9.16, 9.18, 9.20, 9.22, 9.23, and 9.24. FTD 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0.
A remote access service turned on. The device is only exposed if it is running at least one of: IKEv2 remote access VPN with client services, SSL VPN, or, on FTD, Zero Trust Network Access. Exploitation goes through the SSL listen sockets those features open.
If your Cisco firewall is doing site-to-site VPN only, or is purely a perimeter filter with no remote access configured, you are not in the blast radius of this particular bug. If your team uses AnyConnect or Secure Client to get to the office, you almost certainly are.
Cisco has released hot fixes across the affected trains. There is no configuration change, no ACL, and no vendor-blessed mitigation that closes this without the update. Turning off remote access VPN technically removes the exposure, and for most businesses that is the same as turning off work.
The part that makes this annoying
Cisco published no indicators of compromise. It has not said who is exploiting it, how widely, or what a hit looks like in your logs.
So there is no hunt to run. If you want to know whether someone has been knocking your firewall over, the only signal you have is the one your monitoring already gives you: unexplained device reloads. Check your syslog for reboots you cannot account for over the last few weeks. That is thin, and it is what there is.
The vulnerability was found by Cisco’s own product security team during internal testing, and independently reported by security researcher Valerio Brussani.
Why a DoS bug on this hardware deserves more attention than usual
Cisco firewalls have had a rough two years, and the pattern matters more than this individual bug.
In September 2025, CISA issued Emergency Directive ED 25-03 over two ASA and Firepower zero-days: CVE-2025-20333, a 9.9-severity remote code execution flaw, and CVE-2025-20362. Federal agencies were given roughly a day to inventory every ASA platform they owned, take core dumps, and submit them for analysis. The activity was attributed to the state-sponsored actor behind the ArcaneDoor campaign, which had been running against network edge devices since 2023. That actor’s tooling disabled logging, suppressed crash dumps, and modified ROMMON, the code that runs before the operating system, so the backdoor survived reboots.
CVE-2026-20349 is the twelfth Cisco bug with a 2026 identifier to land in CISA’s exploited-vulnerability catalog this year.
The lesson is not that Cisco is uniquely bad. It is that internet-facing network appliances have become one of the most reliably productive targets there is, for a structural reason: they sit at the edge by design, they are exposed by definition, they typically run no endpoint detection agent, and the people who own them patch on a slow cycle because taking the firewall down interrupts everyone. That combination is why VPN concentrators and edge gateways from every vendor keep showing up in the KEV catalog.
If you take one thing from this post, it should not be about Cisco. It should be that the appliance nobody logs into for months is exactly the appliance an attacker is counting on.
What to do
If you manage the firewall yourself:
- Get the running version.
show versionon ASA, or the FTD equivalent through FMC. Compare it against the affected list above. - Check whether remote access VPN is enabled at all. If it is not, you are not exposed here, and you have just learned something useful about your own configuration.
- Apply the hot fix in a maintenance window this week, not this quarter. The device reloads either way. Better on your schedule than someone else’s.
- Look back through syslog for unexplained reloads. It is the only detection signal available.
If someone else manages it, which is the more common case for a small business, send them four questions:
- Are any of our firewalls running an ASA or FTD version affected by CVE-2026-20349?
- Do any of them have remote access VPN, SSL VPN, or ZTNA enabled?
- When will the hot fix be applied, and can we have the maintenance window in writing?
- Have any of our devices logged unexplained reloads in the last month?
Those are answerable in an afternoon by anyone who has an accurate inventory. If they cannot answer question one quickly, the inventory problem is the bigger finding, and it is worth raising as its own conversation. We made the same point about the N-central compromise this month, and it keeps being the same point: when a third party patches your equipment, your only real control is asking specific questions and expecting specific answers.
The habit, not the emergency
We wrote earlier this year about why a small shop still needs a patch cadence, and the argument holds here with one adjustment.
Servers and workstations mostly patch themselves now if you let them. Network appliances do not. Nobody sets a firewall to auto-update, and for good reason, so the update happens when a human decides it happens. That means an edge device is only as current as the last time someone looked, and “someone looked” needs to be a recurring calendar entry rather than a response to a news cycle.
Once a month, check the vendor advisories for every internet-facing appliance you own. Firewall, VPN concentrator, NAS, remote-access gateway, the camera recorder somebody port-forwarded in 2021. It takes twenty minutes. It is the single highest-yield security routine available to a business without a security team, and this month it would have caught this before we wrote about it.
If you are not sure what is sitting on your network edge, who patches it, or whether it should be reachable from the internet at all, send us a note. An inventory and an honest look at what is exposed is usually a short engagement and it is the one we recommend first.