Cisco ASA and FTD CVE-2026-76418: exploited SSL VPN crash when secondary authentication is configured
An exploited flaw lets anyone reload Cisco ASA or FTD firewalls running SSL VPN with secondary auth. Upgrade to a fixed release or remove secondary auth.
- Published
- Updated
- Ecosystem
- Network edgeEnterprise software
- Fixed in
- ASA 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27, 9.24.10.1; FTD 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.1
- Exploitation
- Yes. Cisco PSIRT became aware of exploitation in October 2026; in CISA KEV since 29 October 2026
Live scores
CVE-2026-76418- EPSS
- 0.008
low predicted chance of attack - VEDAS
- 0.742
some exploit evidence - On CISA KEV
- Yes, since 2026-10-29
- Detection rule
- None yet
What happened
On 28 October 2026, Cisco published an advisory for CVE-2026-76418 (bug ID CSCwx26625) in the remote access SSL VPN service of Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software. Logic errors when secondary authentication is configured on a tunnel group let an unauthenticated, remote attacker send a crafted request while connecting to the VPN and make the device reload. The attacker does not need a successful VPN login. Cisco rates it High, CVSS 3.1 8.6 (Cisco).
It is a denial of service only: the CVSS vector has no confidentiality or integrity impact (Cisco). For a VPN headend, a reload drops every remote user and every tunnel through the box.
It is exploited. Cisco says “In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability.” CISA added it to the KEV catalog on 29 October, with a federal due date of 1 November (CISA KEV). Cisco has not named the attackers or the number of targets (The Hacker News) and has published no indicators of compromise (Cisco).
Eric Fernald found the flaw while resolving a Cisco TAC support case (Cisco).
A separate Cisco flaw, CVE-2026-76519, a path traversal in Secure Email Gateway that lets an unauthenticated attacker write files, has been in KEV since 14 October (CISA KEV). It is a different product and needs its own patch.
Am I affected?
A device is affected only if all three are true (Cisco):
- It runs a vulnerable ASA or FTD release.
- The SSL remote access VPN login service is reachable (
webvpnwithenable <interface>on at least one interface). - Secondary authentication (
secondary-authentication-server-group) is set in a tunnel group that matters.
Which tunnel groups matter depends on the group list. If tunnel-group-list enable is configured, check every tunnel group, including DefaultWEBVPNGroup and profiles not shown on the login page. If it is absent, check DefaultWEBVPNGroup.
On ASA, from the CLI:
show version | include Software Version
show running-config webvpn
show running-config tunnel-groupOn FTD, check Devices > VPN > Remote Access in FMC, or Remote Access VPN in FDM, and review the deployed remote access VPN policy (Cisco).
The CVE record lists affected ASA releases in 9.16, 9.18, 9.19, 9.20, 9.22, 9.23 and 9.24, and FTD in 7.0, 7.2, 7.3, 7.4, 7.6, 7.7, 10.0 and 10.1 (CVE record). Cisco’s fixed-release tables have no row for ASA 9.19 or FTD 7.3, so devices on those releases need to move to a train that has a fix.
Cloud-delivered Firewall, cdFMC, Cisco Secure Access and Secure FMC software are not affected (Cisco).
Signs you were hit: Cisco gives no indicators. Unexpected reloads of a VPN headend since October are the obvious symptom. On ASA, show version gives the uptime and show crashinfo shows the last crash.
What to do now
- Upgrade to a first fixed release (Cisco):
| Software | Your release | First fixed |
|---|---|---|
| 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 |
| 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 |
- If you cannot upgrade today, remove the trigger. Cisco says no workaround fixes the flaw, but it tested this mitigation in its lab (Cisco). If
DefaultWEBVPNGroupdoes not use secondary authentication, runno tunnel-group-list enablein webvpn configuration mode; users then have to know their connection profile name, because the drop-down list goes away. IfDefaultWEBVPNGroupdoes use secondary authentication, runno secondary-authentication-server-groupon it; Cisco warns this lowers your remote access VPN security. - Upgrade anyway after mitigating. Cisco says disabling the tunnel group list does not remove exposure if the default group uses secondary authentication, and it strongly recommends the fixed release over the mitigation.