A crafted connection to a Cisco ASA or FTD remote-access SSL VPN can force the firewall to reload when the SSL VPN login service is reachable and secondary authentication is configured on an applicable tunnel group of a vulnerable release. Cisco says it became aware of active exploitation in October 2026. A reload cuts off VPN access while the device comes back up; an attacker needs neither credentials nor a completed login to reach the affected processing path.
The affected deployments run Cisco Secure Firewall ASA or Secure Firewall Threat Defense software with an accessible SSL VPN login service. Cisco tracks the flaw as CVE-2026-76418, rates it high severity at 8.6, and says it arose from logic errors around secondary authentication in tunnel-group processing. Eric Fernald found the flaw while resolving a Cisco Technical Assistance Center support case.
A login path that reloads
For the vulnerable path to exist, three things come together: a vulnerable ASA or FTD release, a reachable SSL VPN login service, and secondary authentication in a tunnel group that the login flow can process. Cisco describes the trigger as a crafted request during connection to that VPN service. The result is an unexpected device reload and denial of service. This is an availability failure, so prioritize internet-facing VPN endpoints and the users and services that depend on them.
The CVE record’s severity vector scores network access, no required privileges or user interaction, and high availability impact; confidentiality and integrity impacts are scored none.
The group list changes which configurations need inspection. With tunnel-group-list enable, inspect every tunnel group, including DefaultWEBVPNGroup, for secondary-authentication-server-group. A group can matter even if it is absent from the profile list shown at login. With the group list disabled, inspect DefaultWEBVPNGroup: removing the list leaves exposure when that default group uses secondary authentication. Look for webvpn and an enabled SSL VPN interface first. On FTD, inspect the deployed remote-access policy in Secure Firewall Management Center or Device Manager and the resulting device running configuration.
Check the firewall and its manager as separate products. Cisco confirms that Cloud-delivered Firewall, cloud-delivered Firewall Management Center, Secure Access, and Secure FMC Software are outside the affected product set. An FTD firewall managed by FMC still needs its own running release and deployed remote-access configuration checked.
Fixed releases for each train
Cisco has released fixes and says, “There are no workarounds that address this vulnerability.” Compare the running release with the first fixed release for its own train. For ASA, Cisco lists 9.16.4.104 for 9.16 and earlier, 9.18.4.96 for 9.18, 9.20.4.50 for 9.20, 9.22.3.200 for 9.22, 9.23.1.48 for 9.23, and 9.24.1.27 or 9.24.10.1 for the 9.24 paths. For FTD, it lists 7.0.11 for 7.0 and earlier, 7.2.13 for 7.2, 7.4.9 for 7.4, 7.6.7 for 7.6, 7.7.14 for 7.7, 10.0.3 for 10.0, and 10.1.1 for 10.1. Use the Cisco advisory’s fixed-release table to select a supported upgrade path for the specific platform and train, then verify the running build after the upgrade.
For a fleet on mixed releases, Cisco’s Software Checker accepts the specific ASA or FTD release and platform and returns the earliest fix for this advisory. It can also calculate a “Combined First Fixed” release across the other advisories it identifies. Use that combined result when planning a broader maintenance window, while retaining the first-fixed build for this flaw as the immediate exposure threshold. For FTD, follow the applicable Secure FMC upgrade guide for the chosen device release.
Temporary changes carry tradeoffs
Cisco describes a conditional temporary mitigation. If DefaultWEBVPNGroup has no secondary authentication, no tunnel-group-list enable removes the selectable connection-profile list. Users then need to know their profile name. If the default group does use secondary authentication, no secondary-authentication-server-group removes it, but that also lowers the security posture of remote access. Evaluate the login and authentication impact before changing either setting; Cisco recommends upgrading to fixed software.
Check tunnel groups and releases
Inventory ASA and FTD VPN endpoints that accept SSL VPN connections. On each, compare the running release with Cisco’s first fixed build and inspect webvpn, the enabled interface, tunnel-group-list enable, and the applicable tunnel groups for secondary-authentication-server-group. For FTD, reconcile the deployed policy with the resulting running configuration rather than relying on the management screen alone. Schedule the fixed release; if service continuity forces a temporary configuration change, record which group was changed and test legitimate profile selection and secondary authentication afterward.
After remediation, verify that the running build is at or beyond the applicable Cisco fixed release and confirm VPN access with a normal authorized connection. A healthy login tests service restoration; the release and tunnel-group checks address the reload path.