Cut-paper illustration of a laptop connected by a dotted line to a firewall box with an arched VPN doorway, circled by a large amber reload arrow

Cisco published the fix on October 28. CISA put the flaw on its exploited list the next day. That speed tells you most of what matters here, and it is not the score. The score is 8.6, high but not critical, because this flaw does not steal data or hand over the device. It restarts it. For a firewall that sits in front of everything, a restart an attacker can trigger from the internet, without logging in, is an outage someone else controls.

The flaw is CVE-2026-76418, in the Remote Access SSL VPN service of Cisco Secure Firewall ASA Software and Secure Firewall Threat Defense (FTD) Software. Cisco says it comes from logic errors when secondary authentication is configured on a tunnel group. An unauthenticated attacker sends a crafted request while connecting to the SSL VPN, and the device reloads. Cisco is explicit on the point that changes how you scope this: a successful VPN login is not required to reach the affected processing path. The login page itself is enough.

What Cisco actually said

Cisco's Product Security Incident Response Team became aware of active exploitation in October 2026. Cisco has not published who is behind the attacks, when they started, how widespread they are, or indicators of compromise. Exploitation was happening before the advisory, so an internet facing device could already have been hit, and the only visible symptom may have been a reload nobody explained.

Cisco rates the flaw CVSS 3.1 8.6: network access, no privileges, no user interaction, availability only. The weakness is CWE-690, an unchecked return value leading to a null pointer dereference. The VPN service mishandles a request in a specific configuration and falls over. There is no workaround. The fix is a software upgrade.

On October 29, CISA added CVE-2026-76418 to its Known Exploited Vulnerabilities catalog, alongside a separate GitLab flaw. The KEV entry gives federal civilian agencies a November 1 remediation due date under Binding Operational Directive 26-04. That deadline binds federal agencies. It does not bind the rest of us. The risk is the same either way, and November 1 is a useful planning date even if no regulator is watching your firewall.

Why a restart is not a small problem

While the device reloads, internet access, site to site links, and every remote worker on the VPN drop together. If the attacker can trigger the reload once, they can trigger it again, because nothing about the first reload changes the configuration that made it possible. Secondary authentication is the second factor in this setup, and the flaw lives in how that second factor is handled. The setting meant to make VPN access safer is the one that exposes the device.

Because this is availability only, on the evidence Cisco has published, do not go hunting for a compromise the advisory does not describe. No data theft and no device takeover have been reported for this flaw. What deserves a look is the reload history: an unexplained reload on an exposed ASA or FTD box in October is worth checking against crash and reload records.

Exposure numbers need the same care. BleepingComputer, citing Shadowserver, reported more than 51,000 Cisco ASA SSL VPN devices exposed online. That counts exposed endpoints, not vulnerable devices. It does not say how many have secondary authentication configured, are already patched, or are honeypots.

Are you exposed? Three conditions have to line up

All three conditions must be true. If any one is false, this flaw does not apply to that device.

Condition What to check
A vulnerable release Compare your ASA or FTD version against the fixed releases below.
A reachable SSL VPN login SSL VPN is enabled on at least one interface, shown by the webvpn keyword and enable on an interface in the running configuration.
Secondary authentication on a tunnel group A tunnel group used for remote access has a secondary authentication server group configured.

The third condition has a trap. If tunnel-group-list enable is configured, check every tunnel group, including the default group, DefaultWEBVPNGroup. If the group list is not enabled, still check DefaultWEBVPNGroup: disabling the group list does not remove exposure when the default group uses secondary authentication. On FTD, review the deployed policy and the resulting running configuration in Firewall Management Center or Firewall Device Manager.

Fixed releases, from Cisco's advisory:

Product line First fixed release
ASA 9.16 and earlier 9.16.4.104
ASA 9.18 9.18.4.96
ASA 9.20 9.20.4.50
ASA 9.22 9.22.3.200
ASA 9.23 9.23.1.48
ASA 9.24 9.24.1.27 and 9.24.10.1
FTD 7.0 and earlier 7.0.11
FTD 7.2 7.2.13
FTD 7.4 7.4.9
FTD 7.6 7.6.7
FTD 7.7 7.7.14
FTD 10.0 10.0.3
FTD 10.1 10.1.1

Check your own train. Do not assume a newer looking version on a different train covers you. Cisco also notes this flaw does not affect Cloud-delivered Firewall, Cloud-delivered Firewall Management Center, Secure Access, or Secure Firewall Management Center software itself.

The mitigation is a trade, not a fix

If you cannot upgrade right away, Cisco recommends a temporary mitigation: turn off the tunnel group list if DefaultWEBVPNGroup does not use secondary authentication, or disable secondary authentication on the affected tunnel groups. Disabling secondary authentication removes a layer of authentication. It reduces exposure, but it changes how users prove who they are, and it should not be done quietly or permanently. It is a bridge to the upgrade, with a clear owner and revert date. Write down what changed and who approved it, then upgrade and restore the setting as part of the same change, verified after the upgrade.

The upgrade is the fix. The mitigation buys time at a cost. Inventory first, upgrade the exposed devices in a planned window with a configuration backup and rollback plan, and verify VPN logins, including secondary authentication, before you call it done. Schedule the window now, while the flaw is known and exploited, instead of discovering the reload pattern during someone else's working day.

A firewall that restarts on command is a firewall that cannot be relied on. Patching closes that door. Checking the configuration first tells you whether the door was open in the first place.

Sources