They Don’t Break In, They Switch Your VPN Off: The Cisco Firewall Flaw Attackers Already Use, and How to Check Yours

By Thorsten Meyer | October 29, 2026 | ThorstenMeyerAI.com

Buying for a business?Offer from Amazon

Get business pricing on tech for your team

• Business-only prices and quantity discounts
• Tax-exempt purchasing
• Multiple users, one account, clear invoices

Create a free Business account →Free to register

As an affiliate, we earn on qualifying purchases.Hide

Imagine a burglar who never picks your lock. He just walks up to the building, presses a button nobody knew was there, and the front door, the staff entrance and the lights all go dark for a while. Then he does it again.

That is roughly what Cisco disclosed on October 28, 2026. A flaw in the remote-access VPN of its Secure Firewall ASA and Firepower Threat Defense (FTD) software lets an attacker on the internet make the firewall restart. No password, no login, no click by anyone. Cisco says attackers are already doing it. The bug is tracked as CVE-2026-76418, and it is the second exploited “crash the VPN” bug in these products since August. Here is what is confirmed, why a crash at the edge is more than an outage, a four-step check to see whether your firewall is exposed, and what companies and remote workers should do now.

Key takeaways

• Remote crash, no login needed. An unauthenticated attacker can send a crafted request to the SSL VPN login and force the device to reload. “A successful VPN login is not required to reach the affected processing path,” Cisco writes. CVSS 8.6, high (Cisco advisory, October 28).
• Already exploited. Cisco’s security team “became aware of active exploitation” in October 2026. Cisco does not say who, against whom, or how often. On October 29, CISA added the bug to its catalog of exploited vulnerabilities and gave US federal agencies until November 1 (CISA KEV).
• Three conditions, all needed. A vulnerable software release, a reachable SSL VPN login, and secondary authentication configured on a tunnel group, including the often overlooked default group, DefaultWEBVPNGroup.
• Patched in September? Patch again. The fixed releases from Cisco’s September hardening update (for the August VPN crash bug, CVE-2026-20349) appear in this CVE’s list of affected versions. The new first-fixed releases are newer builds.
• The stopgap has a price. There is no workaround, only a mitigation: drop the tunnel group list, or remove secondary authentication. Cisco itself warns that the second option lowers the security of your VPN.

Products Worth Considering

Samsung 27-inch Odyssey OLED G6 QD-OLED QHD Gaming Monitor

AmazonView Latest Price

Samsung 27-Inch Odyssey QD-OLED G8 4K 240Hz Gaming Monitor

AmazonView Latest Price

DJI Osmo Pocket 3 Vlogging Camera with 1-Inch CMOS Sensor and 4K Video

AmazonView Latest Price

As an affiliate, we earn on qualifying purchases.

The short answer

A firewall is a company’s front gate. Its VPN is the staff entrance for everyone working from home, the road or a branch office. When the device reloads, it restarts as a whole, not just the VPN. Until it is back, remote staff are cut off, and in a typical setup the traffic it is meant to pass stops too (my reading of “the device reloads”; a standby unit can take over in high-availability setups, more on that below).

The bug sits in the code that handles the VPN login when a second login check is configured. Cisco calls that second check secondary authentication, or double authentication: the firewall asks for a second set of credentials and checks it against a second server (Cisco ASA command reference). Companies use it, for example, to add a second factor. The irony: a setting that makes the login stronger is what opens the crash path. Cisco classifies the weakness as CWE-690, a missing check before the software uses a result that may be empty. In plain terms: the code assumes something is there, it isn’t, and the device falls over. I will not go further into the mechanics. Cisco has not published them, and nobody needs a recipe.

What Cisco confirmed

• Advisory: cisco-sa-asaftd-tunnel-dos-s6mgkb75, first published October 28, 2026, 19:15 GMT. Bug ID CSCwx26625.
• Score: CVSS 3.1 base 8.6. The vector says: reachable over the network, low complexity, no privileges, no user interaction, and the impact is on availability only. Cisco does not claim data theft or a takeover with this bug.
• Exploitation: “In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability.”
• Who found it: Eric Fernald, “during the resolution of a Cisco Technical Assistance Center (TAC) support case.”
• Not affected: Cloud-delivered Firewall, cloud-delivered Firewall Management Center, Secure Access and Secure Firewall Management Center software.
• Workarounds: none. A mitigation exists (details below), and Cisco “strongly recommends” upgrading.

Independent coverage adds no new facts from Cisco. SecurityWeek and BleepingComputer both note that Cisco shared no details on the attacks, and SecurityWeek writes that it is unclear whether the same actor is behind both crash bugs this year. BleepingComputer cites the internet scanning project Shadowserver, which tracks more than 51,000 Cisco ASA SSL VPN devices exposed online, without saying how many are patched or are decoys. That number counts exposed logins, not vulnerable devices, and I could not check it myself.

Why a crash at the edge is more than an outage

“Only” a denial of service sounds harmless next to the data-theft bugs of the past weeks. It isn’t, for four reasons.

1. The people outside are cut off. When the VPN goes down, remote staff lose access to internal systems, branch offices may lose their link to headquarters, and support lines fill up. That part is simple: no gate, no entry.

2. It can be repeated. A device that can be crashed with one request can, in principle, be crashed again as soon as it is back up. Cisco does not describe how the attackers used the bug, so the pattern of the attacks is unknown. But the ability to repeat is what turns a hiccup into an outage (my reading).

3. Failover is not a fix. Many companies run firewalls in pairs: if the active unit fails, the standby takes over. That protects against broken hardware. Against this bug, it may only buy minutes, because the standby normally runs the same software with the same VPN settings and can be hit the same way (my reasoning, not a Cisco statement).

4. A reboot can be part of a bigger plan. This is not speculation from me; it has happened on these exact products. In the ArcaneDoor espionage campaign that Cisco Talos exposed in April 2024, attackers used a crash bug, CVE-2024-20353, to force a reboot, which then installed their persistent backdoor (Cisco Talos). Their in-memory implant also made the device skip its crash dump and reboot straight away, so investigators would have less evidence. In the follow-up campaign in 2025, Cisco saw the same actor “intentionally crashing devices to prevent diagnostic analysis” (Cisco event response). To be clear: there is no public evidence that CVE-2026-76418 is being used this way. But it is why a security team should treat an unexplained firewall reload as a security event, not just an IT ticket.

Not the first time: Cisco firewalls keep getting hit

Edge devices sit on the internet by design, so attackers love them. Cisco Talos put it bluntly in 2024: perimeter network devices “are the perfect intrusion point for espionage-focused campaigns.” The history of ASA and FTD over the last two and a half years shows a pattern, and crashes are a recurring part of it:

• April 2024, ArcaneDoor. A state-sponsored actor, tracked as UAT4356 by Talos and STORM-1849 by Microsoft, targeted ASA devices on government networks. Cisco patched CVE-2024-20353 (crash) and CVE-2024-20359 (persistence) and confirmed exploitation (Cisco advisory).
• October 2024, VPN brute force. Large waves of login attempts against remote-access VPNs could exhaust resources and knock the VPN service over; Cisco was aware of malicious use of that bug, CVE-2024-20481 (Cisco advisory).
• September 2025, ArcaneDoor returns. Zero-days CVE-2025-20333 and CVE-2025-20362 were used against older ASA 5500-X devices. The US cybersecurity agency CISA issued Emergency Directive 25-03 the same day and gave federal agencies about a day for the first steps (CISA).
• November 2025, a crash variant. Cisco saw a new attack variant that “can cause unpatched devices to unexpectedly reload.” A week later, CISA reported that some agencies had marked devices as “patched” that were still on vulnerable versions.
• April 2026, deeper persistence. According to a CISA update summarized by Cisco, the ArcaneDoor actor had built a persistence mechanism that survives upgrades to the September 2025 fixes and had widened its targets to any device running ASA or FTD software.
• August 2026, the first VPN crash bug of this year. CVE-2026-20349 let unauthenticated attackers force a reload through the same Remote Access SSL VPN service. Cisco “became aware of active exploitation” in August (Cisco advisory).
• October 2026, the second. CVE-2026-76418.

By my count of CISA’s Known Exploited Vulnerabilities catalog (version of October 29, 2026), 15 ASA and FTD vulnerabilities are listed as exploited in the wild, out of 102 Cisco entries. CISA added CVE-2026-76418 on October 29 and set November 1 as the deadline for US federal agencies. In the same week, Cisco Talos also described an espionage group that used a different, older bug in Cisco’s SD-WAN controllers (CVE-2026-20127) to steal encryption keys (Cisco Talos); that is a separate case with a separate fix, covered in They Came for the Keys, Not the Data.

Thorsten Meyer AI

Pattern

Infographic 01 · Cisco firewalls under fire

Crashes keep showing up in attacks on Cisco firewalls.

Edge devices sit on the internet by design. On ASA and FTD, forced reboots have been an outage, a step in an implant chain and a way to hide evidence.

8.6CVSS score, high. Impact: availability only

2exploited VPN crash bugs in ASA and FTD this year: August and October

15ASA and FTD bugs in CISA’s exploited catalog, this one included (my count, 29 Oct)

51,000+ASA SSL VPN logins exposed online, reported (exposed ≠ vulnerable)

• Apr 2024ArcaneDoor: a crash to plant a backdoorState-sponsored actor; crash bug CVE-2024-20353 forced a reboot that installed the persistent implant. The implant also skipped crash dumps.
• Oct 2024Brute force knocks VPNs overMass login attempts could exhaust the VPN service (CVE-2024-20481); Cisco aware of malicious use.
• Sep 2025ArcaneDoor returns, emergency directiveZero-days CVE-2025-20333 and -20362; crashes “to prevent diagnostic analysis”; CISA ED 25-03 the same day.
• Nov 2025A crash variant, and “patched” devices that were notNew variant reloads unpatched devices; CISA finds agencies on still-vulnerable versions.
• Apr 2026Persistence that survives the fixCISA update: implant survives upgrades to the 2025 fixes; any ASA or FTD device now in scope.
• Aug 2026VPN crash bug no. 1 of 2026CVE-2026-20349, exploited; fixed in September’s hardening releases.
• Oct 2026VPN crash bug no. 2: CVE-2026-76418Exploited; no details on attackers or scale. Added to CISA’s catalog on 29 Oct; US federal deadline 1 Nov.

History, not proof: nothing public links this bug to ArcaneDoor. It is why an unexplained reload deserves a security look.Thorsten Meyer · my reading

Sources: Cisco advisory, 28 Oct 2026; Cisco advisory CVE-2026-20349 (v1.1, 16 Sep 2026); Cisco Talos, 24 Apr 2024; Cisco advisory CVE-2024-20481; Cisco event response (updated 24 Apr 2026); CISA ED 25-03; CISA KEV catalog, version 29 Oct 2026 (count: Thorsten Meyer); BleepingComputer citing Shadowserver, 29 Oct 2026 (reported only).
Powered by Thorsten Meyer AI

Am I exposed? A four-step check

Your device is exposed only if all three of Cisco’s conditions are true. Work through them in this order. The commands below are read-only show commands on the ASA command line; on FTD, use Firewall Management Center (FMC) or Firewall Device Manager (FDM) as noted.

1. Which software release is running? On ASA, show version. On FTD, the device view in FMC or FDM. Compare the release with the table in the next section, or enter it into Cisco’s Software Checker, which the advisory links. If you are on or above the first fixed release of your train, this bug is fixed. If you only patched in September, you are not.
2. Is SSL VPN switched on? Cisco’s test: the running configuration contains the webvpn keyword and SSL VPN is enabled on at least one interface (enable <interface_name> under webvpn). On ASA, show running-config webvpn. On FTD, check Devices > VPN > Remote Access in FMC, or Remote Access VPN in FDM.
3. Is the VPN login reachable? If the interface with SSL VPN faces the internet, assume yes. A quick check from outside the network: does your VPN address show a login page in a browser?
4. Is secondary authentication configured where it counts? Look for secondary-authentication-server-group in your tunnel groups (show running-config tunnel-group). Which groups count depends on one setting, explained right below.

Which tunnel groups to check, per Cisco:

• If tunnel-group-list enable is configured: check all tunnel groups, including the default group DefaultWEBVPNGroup, even those not shown in the list on the login page.
• If it is absent or was removed: check DefaultWEBVPNGroup anyway. Cisco is explicit that switching the list off “does not remove exposure when that default group uses secondary authentication.”
• On FTD: review the deployed remote-access VPN policy and the resulting running configuration in FMC or FDM.

If steps 1 to 4 are all yes, you are exposed. If any one is no, this bug does not apply, but read the next section anyway; most companies patch for more than one advisory at a time.

Thorsten Meyer AI

Exposure check

Infographic 02 · CVE-2026-76418 · am I exposed?

Three conditions. All three must be true.

A crafted request to the SSL VPN login makes an ASA or FTD firewall reload. Cisco knows of active exploitation since October 2026.

Condition 1

Vulnerable release

ASA or FTD software below the first fixed release of its train. September’s fixed builds count as vulnerable.

show version · FTD: FMC or FDM

AND

Condition 2

SSL VPN login reachable

The config has webvpn and SSL VPN is enabled on at least one interface, which users can reach.

show running-config webvpn

AND

Condition 3

Secondary auth on a tunnel group

secondary-authentication-server-group on a group that counts, including DefaultWEBVPNGroup.

show running-config tunnel-group

All three true = exposed. Any one false = this bug does not apply.No successful VPN login is needed to reach the crash, says Cisco.

Which tunnel groups count

• Group list on (tunnel-group-list enable): check all groups, also those not shown on the login page, and DefaultWEBVPNGroup
• Group list off or removed: check DefaultWEBVPNGroup anyway. Turning the list off does not remove that exposure
• FTD: review the deployed remote-access VPN policy and the resulting running config in FMC or FDM

Not affected, per Cisco

• Cloud-delivered Firewall
• Cloud-delivered Firewall Management Center
• Secure Access
• Secure Firewall Management Center software

Read-only show commands. Confirm your exact release in Cisco’s Software Checker.

Source: Cisco advisory, 28 Oct 2026; Cisco ASA command reference. Layout: Thorsten Meyer.
Powered by Thorsten Meyer AI

The fix, and the trap

Cisco’s first fixed releases, per software train:

• ASA: 9.16 and earlier → 9.16.4.104 · 9.18 → 9.18.4.96 · 9.20 → 9.20.4.50 · 9.22 → 9.22.3.200 · 9.23 → 9.23.1.48 · 9.24 → 9.24.1.27 or 9.24.10.1
• FTD: 7.0 and earlier → 7.0.11 · 7.2 → 7.2.13 · 7.4 → 7.4.9 · 7.6 → 7.6.7 · 7.7 → 7.7.14 · 10.0 → 10.0.3 · 10.1 → 10.1.1

The trap. In September, Cisco published hardening releases that fixed the August crash bug: ASA 9.24.1.26, 9.23.1.47, 9.18.4.94 and so on, FTD 7.4.8, 10.1.0 and so on. Every one of those versions appears in the list of affected versions in the CVE record for CVE-2026-76418 (NVD, data from Cisco). A team that dutifully patched in September is exposed again today and needs the next build. This is the same trap CISA saw in November 2025, when agencies marked devices “patched” that were still on vulnerable versions. The CVE record also lists releases from trains without an entry in Cisco’s fixed table, such as ASA 9.19 and FTD 7.3; for those, my reading is that the path is a move to a listed train. Cisco’s Software Checker is the authority here, not my reading of a table.

The mitigation, if you cannot patch tonight. Cisco offers two cases:

• Case 1: DefaultWEBVPNGroup does not use secondary authentication. Then disable the tunnel group list (no tunnel-group-list enable in WebVPN configuration mode). Side effect: users can no longer pick a connection profile from the list and must know the right one.
• Case 2: DefaultWEBVPNGroup does use secondary authentication. Then remove it (no secondary-authentication-server-group). Cisco’s warning, word for word: “With secondary authentication disabled, the security posture is lowered for remote access VPN.”

Case 2 is a real trade-off. In 2023, Cisco itself warned that the Akira ransomware group was going after VPNs without multi-factor authentication and said that enabling it “can significantly reduce the risk” (Cisco advisory for CVE-2023-20269). Taking a login check away to stop a crash means accepting more risk of a break-in for a few days. Cisco also says to evaluate any mitigation in your own environment first and treats it as temporary. My advice: if you must use Case 2, keep the window short, put a date on restoring the check, and patch.

Thorsten Meyer AI

Fix + trap

Infographic 03 · Fixed releases

Patch to the October builds, even if you patched in September.

There is no workaround. The mitigation trades the crash risk for a weaker VPN login.

ASA: first fixed release

Train → upgrade to at least

• 9.16 and earlier9.16.4.104
• 9.189.18.4.96
• 9.209.20.4.50
• 9.229.22.3.200
• 9.239.23.1.48
• 9.249.24.1.27 or 9.24.10.1

FTD: first fixed release

Train → upgrade to at least

• 7.0 and earlier7.0.11
• 7.27.2.13
• 7.47.4.9
• 7.67.6.7
• 7.77.7.14
• 10.010.0.3
• 10.110.1.1

The trap: patched in September?

September’s fixes for the August crash bug are listed as affected by this one. Examples:

ASA 9.24
9.24.1.26→9.24.1.27

ASA 9.23
9.23.1.47→9.23.1.48

ASA 9.18
9.18.4.94→9.18.4.96

FTD 7.4
7.4.8→7.4.9

FTD 10.1
10.1.0→10.1.1

Trains without a row in Cisco’s table (e.g. ASA 9.19, FTD 7.3) appear as affected too; my reading: move to a listed train.

Can’t patch tonight? Cisco’s mitigation

Case 1 · DefaultWEBVPNGroup has no secondary auth: no tunnel-group-list enable

costs convenience users must know their connection profile

Case 2 · DefaultWEBVPNGroup uses secondary auth: no secondary-authentication-server-group

costs security “the security posture is lowered for remote access VPN” (Cisco)

Temporary only. Test first, put a date on undoing it, then patch.

Sources: Cisco advisory, 28 Oct 2026; Cisco advisory CVE-2026-20349 (v1.1, 16 Sep 2026); NVD record CVE-2026-76418 (data from Cisco). Comparison of the two tables: Thorsten Meyer.
Powered by Thorsten Meyer AI

What this means for companies

In order of priority:

1. Run the four-step check today, on every ASA and FTD device, including the default group DefaultWEBVPNGroup. Exposure hides in defaults.
2. Patch to Cisco’s listed fixed release, even if you patched in September. CISA gave US federal agencies three days; that is a sensible yardstick for everyone else too (my suggestion). Plan the restart: a patch also reboots the firewall, so announce the window to remote staff.
3. If you cannot patch at once, choose the mitigation consciously. Case 1 costs convenience; Case 2 costs security. Write down who decided, why, and when it will be undone.
4. Treat an unexplained reload as a security event. Cisco’s advice from the 2024 campaign still fits: “monitor system logs for indicators of undocumented configuration changes, unscheduled reboots, and any anomalous credential activity.” Keep crash information and open a case with Cisco support if a device restarts without reason.
5. Do not rely on failover alone. A standby unit with the same software and settings is not a defense against a repeatable crash (my reasoning). The defense is the patched release on both units.
6. Have a plan for “the VPN is down.” How do you tell remote staff what is going on if the VPN is the problem? A status page, a phone tree or a messaging channel that does not depend on the VPN.
7. Check old hardware. Cisco lists the end of support for the ASA 5506-X, 5508-X and 5516-X as August 31, 2026, and earlier dates for older 5500-X models (Cisco event response). Devices past their support date are a standing risk; this year’s bugs are a reason to plan the replacement now.

For the bigger picture on why patch windows keep shrinking, see CVEs Are Going to the Moon, Anthropic’s AI Built Five Working Attack Chains and last week’s security package. If you run Fortinet firewalls as well, this week’s security roundup covers their fixes and the FortiBleed campaign.

What this means for users

If you work remotely, this is what a VPN crash looks like from your desk: the connection drops, reconnecting fails or hangs, internal tools stop loading, and maybe it works again a few minutes later. Often, that is your Wi-Fi. This week, it could also be the firewall at the other end.

1. Check your side first, then tell IT. Restart your connection once or twice. If it still fails, report it with the time it happened. Unexplained drops are useful information for your security team right now.
2. Do not install “fix” tools or unofficial VPN clients. Outages are a classic moment for fake emails and chat messages: “your VPN needs an update, download here.” Use only the VPN software your company provides, through the channel it normally uses.
3. Do not route around the VPN. No private VPN apps, no sending work files to your personal email, no USB sticks to keep working. That turns a short outage into a data problem.
4. Be suspicious of calls from “IT”. If someone calls during an outage and asks for your login or a code from your phone, hang up and call back on the number you know.
5. Expect a planned restart. When your company patches, the VPN will be down briefly. A short, announced outage is the good kind.

Honest limits

• Cisco gives no details on the attacks: no attacker, no targets, no start date, no scale, no indicators. Everything about how the bug is being used is unknown.
• No evidence of a bigger chain. The ArcaneDoor reboot trick is history on the same products, not evidence for this case. SecurityWeek notes it is unclear whether the August and October bugs were exploited by the same actor.
• The exposure count is second-hand. The figure of more than 51,000 exposed ASA SSL VPN devices comes from BleepingComputer citing Shadowserver. It says nothing about how many are vulnerable or already patched.
• Official records lag. CISA’s automated triage in the NVD record, dated October 28, still said exploitation “none”; CISA’s own catalog added the bug a day later. Neither adds facts about the attacks. Cisco’s statement remains the primary evidence.
• Failover and repetition are my reasoning, based on how high-availability pairs work in general. Cisco has not described either for this bug.
• Version analysis: the “patch again” finding comes from comparing Cisco’s fixed tables with the affected versions in the CVE record. Before you upgrade, confirm your exact release in Cisco’s Software Checker.

Verdict

Nobody needs to break into your network to hurt you. Switching off the staff entrance is enough, and with this bug it takes no password. Check your tunnel groups, especially DefaultWEBVPNGroup, patch to the October builds even if you patched in September, and treat every unexplained firewall reload as a question your security team must answer.

Sources

• Cisco Security Advisory, “Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability” (cisco-sa-asaftd-tunnel-dos-s6mgkb75), October 28, 2026
• NVD, CVE-2026-76418 (record data from Cisco; accessed via the NVD API, October 29, 2026)
• CISA, Known Exploited Vulnerabilities catalog (version 2026.10.29: CVE-2026-76418 added October 29, 2026, due date November 1, 2026)
• Cisco Security Advisory, Remote Access SSL VPN Denial of Service Vulnerability, CVE-2026-20349 (cisco-sa-asaftd-vpn-dos-dzv4mQFF), August 11, 2026, updated September 16, 2026
• Cisco Event Response, “Continued Attacks Against Cisco Firewalls”, first published September 25, 2025, last updated April 24, 2026
• CISA, Emergency Directive 25-03, “Identify and Mitigate Potential Compromise of Cisco Devices”, September 25, 2025, with implementation note of November 12, 2025
• Cisco Talos, “ArcaneDoor: New espionage-focused campaign found targeting perimeter network devices”, April 24, 2024
• Cisco Security Advisory, Web Services Denial of Service Vulnerability, CVE-2024-20353, April 24, 2024
• Cisco Security Advisory, Remote Access VPN Brute Force Denial of Service Vulnerability, CVE-2024-20481, October 23, 2024
• Cisco Security Advisory, Remote Access VPN Unauthorized Access Vulnerability, CVE-2023-20269, September 6, 2023
• Cisco Secure Firewall ASA Series Command Reference, S commands (secondary-authentication-server-group)
• Cisco Talos, “Inside KeyDrift: Analyzing historical UAT-11473 activity on Cisco SD-WAN”, October 28, 2026
• SecurityWeek (Eduard Kovacs), “Attackers Exploit Second Cisco Firewall VPN Zero-Day Since August”, October 29, 2026
• BleepingComputer (Sergiu Gatlan), “New Cisco firewall zero-day exploited to crash SSL VPN devices”, October 29, 2026

Related on ThorstenMeyerAI.com: Cisco SD-WAN: They Came for the Keys, Not the Data · This Week in Security: Firewall Fixes and More · Attackers Now Go After Your AI Tools · CVEs Are Going to the Moon: AI, bug hunters and the patch gap · AI has taken the clock off cyberattacks: what companies and users should do now