Can an attacker take down your firewall without stealing anything at all? Yes — and a Cisco advisory this month is a clean case study. On August 11, 2026, CISA added a Cisco firewall flaw to its Known Exploited Vulnerabilities catalog that exposes no data; it just makes the box reload. If remote workers, site-to-site links, and maybe your phones pass through that one appliance, that reload is a work stoppage, and most incident response plans were never written for it.
CVE-2026-20349 is a heap inspection vulnerability in the Remote Access SSL VPN service on Cisco Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) software. CISA's KEV catalog entry describes it as allowing an unauthenticated, remote attacker to cause the device to reload unexpectedly, resulting in a denial-of-service condition — no credential theft, no data exfiltration, no lateral movement. The entire impact is that the appliance stops working, comes back, and stops again if the attacker keeps sending the request.
Cisco's own advisory attributes the flaw to insufficient error checking when ASA or FTD software processes HTTP requests against the Remote Access SSL VPN service. Devices are reachable this way only if IKEv2 Remote Access VPN, SSL VPN (WebVPN), or Zero Trust Network Access is enabled, which describes most SMB firewalls running a remote workforce. There is no configuration workaround; the fix is a hotfix or upgrade across the affected ASA trains (9.16 through 9.24) and FTD trains (7.0 through 10.0), and Secure Firewall Management Center is confirmed unaffected. Cisco rates it High with a CVSS base score of 8.6, scored entirely on availability impact with no confidentiality or integrity loss — an unusual profile that tells you plainly what kind of failure this is. The NVD record for CVE-2026-20349 confirms the same mechanism but had not published its own score at the time of writing, so Cisco's advisory remains the authoritative figure.
An unauthenticated attacker who can reboot your firewall on demand has taken away your business's ability to operate, and that is a continuity failure, not a confidentiality failure, even though most SMB security programs are built around the second category. The incident response plans I inherit are written to answer "what did they take." They rarely answer "what happens when nothing was taken but nothing works either."
Security programs default to a confidentiality lens because that is where regulatory pressure and breach-notification laws live. A stolen customer record triggers a legal obligation; a rebooted firewall triggers nothing except the phone ringing off the hook from every department that just lost its connection. For a 40-person accounting firm or a regional manufacturer, the firewall is frequently the single device carrying remote access, site-to-site connectivity, and sometimes VoIP trunking. When it reloads, remote staff lose their session, the branch office loses its file-server link, and the phones go quiet too. None of that shows up in a data-loss ledger; all of it shows up in lost billable hours and a help desk queue that fills in minutes.
This is precisely the kind of finding a DoS-only KEV entry gets deprioritized against, because patch triage still asks "was data taken" before it asks "can this take us offline." A vulnerability that only reloads a device does not feel as urgent as one that grants a shell, until you remember the reload is unauthenticated, remote, and repeatable. An attacker does not need to breach anything to make your business unreachable for as long as they keep sending the request.
Ask most SMB owners which device in their network is most critical and they will correctly say the firewall. Ask which device has a live standby ready to take over instantly, and the answer is usually silence. Servers get virtualized and clustered; storage gets mirrored. The firewall, standing between the business and the internet and often carrying VPN and site-to-site traffic besides, is frequently a single box with a single power supply and a single path to the ISP.
Part of the reason is cost: a proper high-availability (HA) pair doubles the licensing and hardware spend on a device that, most days, just sits there passing traffic. Part of the reason is complexity: HA failover across ASA or FTD pairs has to be configured correctly and tested, not just purchased. And part of the reason is that the appliance rarely fails on its own, so it drops off the redundancy conversation in favor of things that fail more visibly. A remotely triggerable reload changes that calculus, converting an appliance that "almost never fails on its own" into one an outsider can fail on command, as often as they like.
A defensible answer has four pieces. First, an actual HA pair for the firewall, configured so the standby can take the primary's IP and session state within seconds, not minutes. Second, a secondary WAN path — a backup ISP circuit or LTE failover — so a firewall event does not also kill the only route to the internet. Third, out-of-band management: a way to reach the device that does not depend on its own primary interfaces being up, since the worst time to discover you cannot manage a reloading firewall is during the reload loop. Fourth, a documented manual fallback naming the specific alternate path and who authorizes it, for people who cannot wait out an outage — the finance lead submitting a wire, the technician needing remote access, the receptionist who needs the phones working. None of this is expensive relative to what an unplanned multi-hour outage costs, and all four belong in standard network design, not bolted on after the first bad day.
The honest answer, from the operations side, is scheduling friction rather than negligence. Patching a firewall means a reload, sometimes a full version upgrade, with real risk a misconfigured rule surfaces only after the device comes back up. For a business with no tested failover, the patch waits for a window when a brief outage hurts least — a weekend, an overnight, a month-end that keeps getting pushed. Every deferral is individually reasonable, and the cumulative effect is a firewall running a release months behind, sitting on the public internet with a VPN service enabled.
CISA's KEV entry set a remediation due date of August 14, 2026 for federal civilian agencies under Binding Operational Directive 26-04, and that date has already passed as of this writing. The point for an SMB is not the calendar date — BOD 26-04 binds federal agencies, not private businesses — it is what the deadline reveals: the government's own patching program assumes an organization can get a fix into production inside about three days for its highest-risk tier. If a maintenance-window culture means your business cannot move that fast on an unauthenticated, remotely exploitable DoS, that gap between having a patch policy and executing it under pressure is the real finding.
Assume nothing that has not been forced to fail on a schedule you controlled. The test that matters is not "does the standby unit exist" — it is a scheduled, announced failover where you manually force the primary offline and time how long users and VPN sessions take to reestablish. Do it again for the secondary WAN path: unplug the primary circuit and confirm the failover connection carries production traffic rather than just showing a green light in a dashboard. Do it a third time for out-of-band management, logging in through that path while primary interfaces are deliberately down — that is the one component nobody remembers to test until the day they need it. The organizations burned worst by an availability event are usually the ones that had every piece of redundant infrastructure on paper and had never once watched it take over.
An underappreciated part of this vulnerability class is what happens to monitoring and logging during the event itself. A firewall that is repeatedly reloading is not reliably shipping logs to your SIEM, and not generating the audit trail you would want later. Your detection tooling goes dark at precisely the moment something is interfering with your perimeter, and if this DoS activity turns out to be a precursor probe rather than the whole story, a gap in your logs during the reload window makes that harder to rule in or out afterward. A device that cannot stay up cannot reliably tell you what happened to it while it was going down.
Yes: availability is an explicit outcome in NIST's Cybersecurity Framework 2.0, which lists "adequate resource capacity to ensure availability is maintained" under its Protect function, alongside identity management and data security. A firewall forced offline by an unauthenticated remote request is a direct gap against that outcome, independent of whether any data was at risk — a framework written by the federal government's own standards body treats availability as a first-class objective, not an afterthought to confidentiality.
The insurance angle has real numbers behind it. Allianz Commercial's claims and risk management analysis reports that business interruption losses account for over 50% of cyber claim values, and that contingent business interruption events in the supply chain made up 15% of large cyber claims above one million euros by value in the first half of 2025, against 6% in 2024. Underwriters are already pricing and paying claims on exactly this failure mode — operational downtime, attack-caused or not — not only on data theft. An unauthenticated, remotely triggerable reload of your primary internet-facing appliance sits close to the textbook example of that claims category.
Confirm whether your ASA or FTD deployment runs an affected release train with Remote Access SSL VPN, IKEv2 remote access, or Zero Trust Network Access enabled, and apply Cisco's hotfix or move to a corrected release — there is no configuration workaround, so patching is the only remediation. Then answer the harder question: if that same appliance reloaded right now, on command, with no attacker credentials involved, what would keep your remote staff, branch connectivity, and phones working, and when did anyone last test that?
If the honest answer is "we are not sure," that is a business continuity gap, sitting alongside the disaster-recovery planning most SMBs already take seriously — the same rigor business continuity planning for your IT systems applies to a ransomware scenario applies just as directly here. Revisit how your business continuity plan accounts for single points of failure at the network edge, since most plans are written around data recovery rather than perimeter uptime, and whether your disaster recovery testing strategy has ever actually forced a failover rather than assumed one.
None of this is unique to Cisco. Any internet-facing appliance carrying VPN, remote access, or voice traffic is a candidate for the same argument — Securafy's AI Lab covers where SMBs should start on AI security risk and controls, and separately, workflow security tooling that helps catch this class of exposure earlier. On the insurance side, revisit what underwriters actually require for cyber insurance readiness in 2026, since availability controls are increasingly part of that conversation.
An unauthenticated attacker who can reboot your firewall on command has found a business continuity exposure, not a data breach, and closing it means testing failover, not just patching a CVE and moving on.
If your team is moving faster with AI than your guardrails are, start with structured training rather than another tool. Securafy AI University gives your people role-based AI training with security built into the material.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk your current AI usage, exposure, and the fastest path to safe adoption.