HIGH: Cisco ASA and FTD VPN Bug Under Active Attack Crashes Firewalls

There is a special kind of dread that comes from watching your perimeter firewall reboot itself in the middle of a Tuesday afternoon while two hundred remote workers suddenly lose their VPN sessions. Cisco just confirmed that somebody out there is doing exactly that to other people on purpose.

On October 28, 2026, Cisco published advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 for CVE-2026-76418, a denial of service flaw in the SSL remote access VPN login path of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Cisco Secure Firewall Threat Defense (FTD) Software. The bug lets an unauthenticated, remote attacker send a crafted request while connecting to the VPN and force the device to reload. Cisco's PSIRT says it became aware of active exploitation of this vulnerability in October 2026, which moves this one out of the "schedule it for next maintenance window" pile and straight into the "do it tonight" pile.

What the Bug Actually Is

Cisco scores CVE-2026-76418 at 8.6 on CVSS 3.1, with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H. Translated out of CVSS dialect, that means it is reachable over the network, trivial to trigger, requires no credentials and no user interaction, and the impact lands squarely on availability. The scope change in that vector matters too. When the firewall goes down, it is not just the firewall that suffers. Everything sitting behind it and everyone tunneling through it goes down with it.

Cisco attributes the root cause to logic errors when secondary authentication is configured on a tunnel group, and the advisory maps it to CWE-690, the class of bugs where a function's return value goes unchecked and the code ends up dereferencing a null pointer. In other words, the VPN login process wanders into a code path that assumes something exists when it does not, and the appliance falls over. Nobody is getting a shell out of this one. No data is being read or modified. But for a device whose entire job is to stay up and keep traffic flowing, a remotely triggerable reboot is about as bad as it gets short of code execution.

The good news, such as it is, is that exposure depends on configuration. A device is vulnerable only if three things are true at once. It has to be running an affected ASA or FTD release, the SSL remote access VPN login service has to be reachable, and secondary authentication has to be configured in the tunnel group scope. Cisco notes that a configuration containing the webvpn keyword with SSL VPN enabled on at least one interface is the starting point for exposure. On FTD, Cisco adds a detail that should make every admin a little uncomfortable, which is that a successful VPN login is not required to reach the affected processing path. The attacker just needs to start knocking.

There is also a trap hiding in the configuration logic that deserves its own paragraph. Plenty of admins will assume that turning off the tunnel group list makes them safe. It does not, at least not automatically. Cisco warns that if tunnel-group-list enable is absent or has been removed, you still need to check the default tunnel group, DefaultWEBVPNGroup, for a secondary-authentication-server-group setting, because disabling the group list does not remove exposure when that default group uses secondary authentication. This is precisely the sort of nuance that gets lost in a hurried change ticket, so read it twice.

Affected Versions and Fixed Releases

Cisco has shipped fixes across every supported train. On the ASA side, releases 9.16 and earlier are fixed in 9.16.4.104, the 9.18 train in 9.18.4.96, the 9.20 train in 9.20.4.50, and the 9.22 train in 9.22.3.200 for anyone still on it. Customers on 9.23 should move to 9.23.1.48, while the 9.24 train has two fixed builds in 9.24.1.27 and 9.24.10.1 depending on which branch you are tracking.

For FTD, anything at 7.0 or earlier needs to land on 7.0.11, the 7.2 train is fixed in 7.2.13, and 7.4 is fixed in 7.4.9 as well. The 7.6 train moves to 7.6.7, the 7.7 train to 7.7.14, and the newer 10.0 and 10.1 trains are fixed in 10.0.3 and 10.1.1 respectively. Cisco confirms that Cisco Defense Orchestrator's cloud delivered firewall, cloud delivered FMC, Cisco Secure Access, and on premises Secure Firewall Management Center are not affected by this particular flaw.

What Exploitation Looks Like

Cisco has been characteristically tight lipped about the attacks themselves. The advisory confirms active exploitation but does not say when it began, who is behind it, or how widespread it is. That silence is frustrating but not unusual for Cisco PSIRT, and it should not be read as reassurance.

What we can say is that this lands in a very busy month for Cisco edge gear. The same day this advisory dropped, Cisco Talos published research on UAT-11473, an APT actor that exploited CVE-2026-20127 in Cisco SD-WAN Catalyst Controller instances to deploy a custom framework called KeyDrift, built for long term persistence and automated theft of encryption keying material. Talos ties that activity to infrastructure overlapping Volt Typhoon's "Silent Train" covert network and says it targeted space and satellite services, defense and aerospace technology, and policy research organizations. Nothing in Cisco's advisory links the two campaigns, and I am not going to pretend otherwise. But the broader pattern is impossible to ignore. Nation state operators have spent the last several years treating Cisco ASA and FTD as one of their favorite front doors, and this is the second actively exploited ASA and FTD remote access VPN denial of service bug of 2026, after CVE-2026-20349 landed in CISA's Known Exploited Vulnerabilities catalog back in August.

Why would a sophisticated attacker care about a crash bug? A few reasons, none of them comforting. Forcing a firewall to reload can wipe volatile logs and in memory forensic artifacts at an inconvenient moment. It can knock a primary unit offline to push traffic through a failover peer the attacker has better visibility into. It can serve as a distraction while something quieter happens elsewhere. And sometimes it is just extortion or hacktivism, where taking down a company's remote access for an afternoon is the whole point. In practice, the first sign most victims will see is an unexpected reload on a device that was otherwise healthy, followed by a crash file and a flood of VPN reconnects.

What to Do Right Now

Patching is the answer, and Cisco is blunt about it. There are no workarounds that fully address the vulnerability, and Cisco strongly recommends upgrading to a fixed release. If you run ASA or FTD with SSL remote access VPN, pull the fixed build for your train and get it onto your HA pairs tonight, starting with the standby unit so you can fail over cleanly and keep users connected during the upgrade.

If you genuinely cannot patch immediately, Cisco offers a mitigation that removes the exposure by disabling secondary authentication. If the default tunnel group does not use secondary authentication, running no tunnel-group-list enable will close the hole. If DefaultWEBVPNGroup does use it, or if you have user configured tunnel groups that rely on it, you will need to remove secondary-authentication-server-group from those groups. Be honest with yourself about what that costs, because secondary authentication is often the thing standing between a stolen password and a working VPN session. Cisco itself acknowledges the mitigation lowers your VPN security posture. Treat it as a short bridge to the patch and not as a destination.

FTD shops need to do their homework in the management plane. Cisco advises reviewing the deployed remote access VPN policy and the resulting device running configuration in Secure FMC or Secure FDM, rather than trusting what you think the policy says. On ASA, start with show running-config tunnel-group and look at every tunnel group, including DefaultWEBVPNGroup, for secondary-authentication-server-group.

For detection, Cisco has not published indicators of compromise, so you will be working from behavior. Watch for unexpected reloads on ASA and FTD devices and check show version for reload reasons that do not line up with a planned change. Look for new crashinfo files, correlate reload times against your VPN authentication logs, and flag bursts of SSL VPN connection attempts from unfamiliar sources immediately before a crash. If you forward syslog to a SIEM, a simple alert on device uptime resets for perimeter firewalls is cheap and catches this class of attack regardless of the specific CVE. And while you are in there, it is worth confirming you are on top of the earlier 2026 ASA and FTD advisories as well, because attackers clearly are.

The MSP Angle

Every client with a Cisco ASA or FTD running AnyConnect style remote access is a potential victim here, and plenty of them have no idea whether secondary authentication is configured at the tunnel group level or at the default group. That makes this a perfect opening for a fast, fixed price perimeter firewall health check that covers firmware currency, VPN configuration review, and uptime alerting, and it is a natural on ramp to a managed firewall or managed detection agreement for clients who just learned the hard way that "set it and forget it" is not a patching strategy.