Cisco ASA and FTD CVE-2026-76418: Exploited VPN Reload Bug
Cisco says CVE-2026-76418 is exploited: a crafted SSL VPN request reloads ASA and FTD firewalls using secondary authentication. CISA due date: Nov 1.
Cisco says CVE-2026-76418 is being exploited against Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software. An unauthenticated remote attacker can send a crafted request to the SSL remote access VPN and force the firewall to reload, but only when secondary authentication is configured on a tunnel group. Cisco published the advisory on October 28, 2026, rates it CVSS 8.6, and offers no workaround. CISA added it to the KEV catalog on October 29 with a November 1 due date.
What CVE-2026-76418 does
The flaw sits in the Remote Access SSL VPN service. Cisco attributes it to "logic errors when secondary authentication is configured on a tunnel group." The CVE record classifies it as CWE-690, an unchecked return value that leads to a NULL pointer dereference. A successful request makes the device reload, which is a denial of service condition for everything that passes through that firewall while it restarts.
The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H. Read that literally: network reachable, low complexity, no privileges, no user interaction, and the impact is availability only. Confidentiality and integrity are both rated None. Neither Cisco nor CISA describes code execution, credential theft or data access through this bug, so treat it as a repeatable outage risk on your VPN edge, not a compromise path.
Cisco also notes that "a successful VPN login is not required to reach the affected processing path." The attacker does not need valid credentials, only reachability to the SSL VPN login service.
Which ASA and FTD configurations are vulnerable
A device is affected only when all three of these are true, according to the advisory:
- It runs a vulnerable ASA or FTD release (see the fixed-release table below).
- The SSL remote access VPN login service is reachable. On ASA, look for the
webvpnkeyword withenable <interface_name>on at least one interface. On FTD, remote access VPN is enabled under Devices > VPN > Remote Access in Secure Firewall Management Center (FMC) or under Remote Access VPN in Secure Firewall Device Manager (FDM). - Secondary authentication is configured in the tunnel group scope Cisco describes.
The tunnel group check has two cases, and the second one catches people out:
- If
tunnel-group-list enableis configured, check every tunnel group, including the defaultDefaultWEBVPNGroup, forsecondary-authentication-server-group. Cisco says this check "is not limited to profiles that are displayed in the group list on the login page." - If
tunnel-group-list enableis absent, or was removed withno tunnel-group-list enable, still checkDefaultWEBVPNGroup. Disabling the group list does not remove exposure when the default group uses secondary authentication.
On FTD, Cisco asks you to review both the deployed remote access VPN policy and the resulting running configuration on the device, not just the policy as it appears in FMC or FDM.
Cisco lists these products as not vulnerable: Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) and Secure FMC Software itself.
Exploitation status and CISA KEV deadline
The advisory's exploitation section reads: "In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability." Cisco does not name an actor, give victim counts or describe the campaign. The bug was found by Eric Fernald while resolving a Cisco TAC support case.
CISA added CVE-2026-76418 to the Known Exploited Vulnerabilities catalog on October 29, 2026 and set a due date of November 1, 2026. That is a three-day window. The entry's required action is to apply mitigations per Cisco's instructions in line with BOD 26-04, or discontinue use of the product if mitigations are unavailable. The KEV entry lists known ransomware campaign use as "Unknown," and neither source attributes the activity to any group.
No workaround, and a mitigation with costs
Cisco is explicit: "There are no workarounds that address this vulnerability." It does describe a mitigation, which is to remove secondary authentication from the exposed tunnel groups:
- Case 1: if
DefaultWEBVPNGroupdoes not use secondary authentication, disable the tunnel group list withno tunnel-group-list enablein WebVPN configuration mode. Users can then no longer pick a connection profile from a list and need to know which profile to use. - Case 2: if
DefaultWEBVPNGroupuses secondary authentication, remove it withno secondary-authentication-server-group. Cisco states plainly that this lowers the security posture of remote access VPN.
Cisco says the mitigation "was proven successful in a test environment," and warns that customers should evaluate applicability and impact in their own environment before deploying it, because any mitigation may affect functionality, performance or security posture. It also says it considers workarounds and mitigations "temporary solutions" until a fixed release is installed.
That trade-off matters. Case 2 removes an authentication factor from your VPN to keep the box from rebooting. If you take that route to buy time, record it as a change with an expiry date and reverse it when the upgrade lands.
CVE-2026-76418 fixed releases
Cisco's first fixed releases for Secure Firewall ASA Software:
- 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 or 9.24.10.1
Cisco's first fixed releases for Secure FTD Software:
- 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
The CVE record also lists ASA 9.19.x and FTD 7.3.x builds as affected, but the advisory's fixed-release tables have no row for those trains. If you run either, use the Cisco Software Checker to find a fixed release on a supported train before you plan the upgrade. Our note on why firmware release trains matter for patching covers that planning problem in more detail.
What to do now
- Inventory every ASA and FTD device with the SSL VPN enabled on an interface.
- On each, check
DefaultWEBVPNGroupand every other tunnel group forsecondary-authentication-server-group, regardless of whether the group list is enabled or the profile is shown on the login page. - Compare the running release against the lists above or the Cisco Software Checker.
- Schedule the upgrade to a fixed release first. For FTD, follow the FMC upgrade guide for your version.
- If you cannot upgrade before November 1, evaluate Cisco's mitigation in your environment, document the reduced authentication posture if you choose Case 2, and set a date to restore secondary authentication.
- Watch for unexpected reloads on VPN-facing firewalls. A reload is the only impact both sources describe, so crash and uptime monitoring is the most direct signal.
While you are in the VPN headend config, it is a good moment to confirm that management access is restricted, as covered in how to restrict firewall management access.