Vulnerabilities
Cisco ASA and FTD VPN flaw exploited to reboot firewalls
CVE-2026-76418 lets an unauthenticated attacker reload Cisco ASA and FTD firewalls running SSL VPN with secondary authentication. Fixes and checks.
Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software have a high-severity flaw, CVE-2026-76418, rated CVSS 8.6. An attacker with no account sends a crafted request to the SSL remote access VPN login service and the firewall reloads. It only affects devices where at least one VPN connection profile (Cisco calls these tunnel groups) uses secondary authentication, a second login server checked after the first, which is how many organisations add a token or one-time password to AnyConnect and Secure Client logins.
Cisco published the advisory on October 28 and says its Product Security Incident Response Team (PSIRT) became aware of exploitation this month. CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on October 29 and gave US federal agencies until November 1 to act, a three-day window. If your firewall terminates remote access VPN and you use double login on any connection profile, patch this weekend or apply the mitigation below.
How it works
When a VPN user connects, the firewall looks up the tunnel group they selected or were placed in, and runs its authentication steps in order. With secondary-authentication-server-group set, the firewall checks a second AAA server (authentication, authorisation and accounting, usually RADIUS or LDAP) after the primary one. Cisco describes the bug as logic errors in how that secondary step is handled. The weakness class is CWE-690: a function returns NULL when something goes wrong, the caller does not check for it, and the code then reads through that empty pointer. On an appliance that is a fatal error, so the whole device restarts.
The attacker never has to log in. Cisco says a successful VPN login is not required to reach the vulnerable code, and the CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H) reflects that: network reachable, low complexity, no privileges, no user interaction. The impact is limited to availability. There is no code execution or data access in this advisory, but a reload drops every VPN session and, unless a failover peer takes over, every connection routed through the box. An attacker can keep repeating the request.
Three conditions must all be true. The running configuration has webvpn with SSL VPN enabled on at least one interface, the SSL VPN login service is reachable by the attacker, and secondary authentication is set in a tunnel group the attacker can reach. That last point has a catch. If tunnel-group-list enable is on, any tunnel group counts, including DefaultWEBVPNGroup and groups hidden from the login page drop-down. If the list is off, DefaultWEBVPNGroup alone decides it, so turning off the list does not help when the default group uses secondary authentication.
Cloud-delivered Firewall, cloud-delivered Firewall Management Center (cdFMC), Cisco Secure Access and Secure Firewall Management Center (FMC) Software are not affected. Cisco credits Eric Fernald, who found the flaw while working a Technical Assistance Center (TAC) support case.
What attackers are doing
Public detail is thin. Cisco confirms exploitation in October 2026 but has not named an actor, a start date or a victim count, and CISA lists ransomware use as unknown. Cisco has not published indicators of compromise or crash signatures.
This is the second exploited denial of service in the ASA and FTD remote access VPN this year. CVE-2026-20349, also rated CVSS 8.6, was disclosed on August 11 and is already in KEV. An attacker who can reboot your VPN headend at will can cut off remote staff during an incident, or force a reload while they work on something else. Teams that patched in August still need this fix, since the two are separate bugs with separate fixed builds.
What to do
1. Check whether you are exposed
On ASA, run show running-config webvpn to see whether SSL VPN is enabled on an interface, then show running-config tunnel-group | include tunnel-group|secondary-authentication-server-group to list which tunnel groups use secondary authentication. Check DefaultWEBVPNGroup explicitly. On FTD, review the remote access VPN policy in FMC under Devices > VPN > Remote Access (or in Firewall Device Manager under Remote Access VPN) and the resulting running configuration. If no reachable tunnel group uses secondary authentication, you are not exposed to this flaw, but patch anyway at the next window.
2. Upgrade to a fixed release
For ASA the first fixed releases are 9.16.4.104 (which covers 9.16 and earlier trains), 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, and 9.24.1.27 or 9.24.10.1. For FTD they are 7.0.11 (covering 7.0 and earlier), 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 and 10.1.1. Run your exact version through the Cisco Software Checker, which also shows fixes for other advisories. In a failover pair, upgrade the standby unit first, fail over, then upgrade the other.
3. If you cannot patch today
Cisco lists no workaround, but gives a mitigation that removes the vulnerable condition. If DefaultWEBVPNGroup does not use secondary authentication, enter no tunnel-group-list enable in webvpn configuration mode. Users then have to know their connection profile name (through a group URL or alias) instead of picking it from a list. If DefaultWEBVPNGroup does use secondary authentication, remove it there with no secondary-authentication-server-group. Cisco notes this weakens remote access security, so treat it as a short bridge to the upgrade and test it outside peak hours. On FTD, make the equivalent change in the remote access VPN policy and deploy it.
4. Check whether you were hit
Because the result is a reload, the evidence is a restart you did not plan. Run show version and compare the uptime against your change records, and run show crashinfo to see whether a crash file was written. In your SIEM, look for gaps in the firewall's syslog stream and for failover events since early October, and correlate them with inbound connections to the VPN login on TCP 443 from unfamiliar addresses. These checks come from standard operating practice, since Cisco has not published specific indicators. If you find unexplained reloads, open a TAC case with the crash file attached.
The wider lesson
Denial-of-service bugs on edge devices get patched later than code execution bugs, and this one shows why that ordering is risky. The remote access VPN headend is a single point that the whole remote workforce depends on, it faces the internet by design, and its exposure here depends on a login setting most teams added for security. Keep an inventory of which features each edge device actually runs, so that an advisory with a conditional configuration can be checked in minutes instead of hours.
Our attack surface management work tracks which VPN and management services you expose to the internet, and our network penetration tests check how those edge devices hold up. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: Cisco security advisory, CISA KEV catalog, NVD, OpenCVE, SecurityOnline, Qualys ThreatPROTECT on CVE-2026-20349, Canadian Centre for Cyber Security.