Cisco ASA and FTD SSL VPN DoS Exploited in the Wild (CVE-2026-76418)

TL;DR

• CVE-2026-76418 is a denial-of-service flaw in the Remote Access SSL VPN service of Cisco Secure Firewall ASA and FTD Software. An unauthenticated, remote attacker sends a crafted request while connecting to the SSL VPN and the device reloads unexpectedly. Cisco rates it High, CVSS v3.1 8.6 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H.
• The CVE record names 209 affected ASA and FTD releases; the table below maps them by line. A device is exposed only when three conditions hold: it runs a vulnerable release, the SSL remote access VPN login service is reachable, and secondary authentication is configured on a tunnel group. A successful VPN login is not required to reach the affected processing path.
• Cisco states that its Product Security Incident Response Team became aware of active exploitation of this vulnerability in October 2026, without giving dates, actors or scale. The flaw is not in the CISA Known Exploited Vulnerabilities catalog as of October 29, 2026.
• Upgrade to the first fixed release for your line now. The table below covers all fifteen affected lines: the advisory gives a fixed release for thirteen, and the note after the table covers ASA 9.19 and FTD 7.3. If you cannot upgrade today, Cisco's mitigation, its two cases and their trade-offs are under "How do I fix it?".

Am I affected?

Your device is exposed only if all of these hold:

• It runs a vulnerable release of Cisco Secure Firewall ASA Software or Cisco Secure FTD Software. Cisco confirmed that Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) and Secure FMC Software are not affected.
• The SSL remote access VPN login service is reachable: the running configuration contains the webvpn keyword with SSL VPN enabled on at least one interface. On FTD, remote access VPN features are enabled from Devices > VPN > Remote Access in Secure FMC or from Remote Access VPN in Secure FDM.
• Secondary authentication is configured in the tunnel group scope. If tunnel-group-list enable is configured, check all tunnel groups, including the default tunnel group DefaultWEBVPNGroup, for secondary-authentication-server-group. If the group list is absent or was removed with no tunnel-group-list enable, check DefaultWEBVPNGroup anyway: disabling the group list does not remove exposure when the default group uses secondary authentication.

Two lines are missing from the advisory's fixed-release table while the CVE record names affected builds in them: ASA 9.19.1 to 9.19.1.42 and FTD 7.3.0 to 7.3.1.2. Operators on either should use the Cisco Software Checker linked in the advisory, which returns the first fixed release for a specific release number. The CVE record names 142 affected ASA releases and 67 affected FTD releases, and every one needs the patch.

In four lines the record also names builds numbered above the advisory's first fixed release: 9.18.4.135, 9.20.4.235, 9.23.1.195 and 9.24.1.155. Neither source explains them, so check the exact release number of such a build in the Software Checker rather than comparing it with the table.

Check the running software and the two configuration conditions on each device:

show version                          # running software release and uptime
show run webvpn                       # webvpn enable <interface> lines: is the SSL VPN service on?
show run tunnel-group | include tunnel-group|secondary-authentication-server-group   # each tunnel group, followed by its secondary authentication line if any
show run tunnel-group DefaultWEBVPNGroup | include secondary-authentication-server-group   # the default group, even without a group list

The last three commands are adapted from the configuration keywords Cisco's advisory names (webvpn enable, tunnel-group-list enable, secondary-authentication-server-group). A secondary-authentication-server-group line that names a server group, not none, means secondary authentication is on for that tunnel group.

On FTD, the tunnel groups live inside the remote access VPN policy that Secure FMC or Secure FDM deploys to the device. Review that deployed policy and the resulting running configuration there. To find the fixed release for your exact build, run it through the Software Checker linked above.

How do I fix it?

Upgrade to the first fixed release for your branch from the table above, following Cisco's ASA or FTD upgrade guides. On FTD devices the upgrade runs through Cisco Secure FMC or Secure FDM, not by hand on the device. Cisco considers any mitigation temporary until the upgrade is in place.

Cisco's advisory states there are no workarounds. It does give one mitigation, which removes the configuration condition the attack needs:

• Case 1: if DefaultWEBVPNGroup does not use secondary authentication, disable the tunnel group list. In webvpn configuration mode, enter no tunnel-group-list enable. Users can then no longer choose a connection profile from a list on the login page and must know the profile name to use.
• Case 2: if DefaultWEBVPNGroup uses secondary authentication, remove secondary authentication with the no secondary-authentication-server-group command. That lowers the security posture of remote access VPN, because logins lose their second authentication step.

Both cases state their cost plainly: the mitigation trades a user-facing login feature or a second authentication factor for the removal of the vulnerable processing path. Cisco deployed the mitigation in a test environment and asks every customer to evaluate it in their own environment. Neither case changes the software, so the upgrade is still the fix.

What is the root cause?

The Remote Access SSL VPN service mishandles a request that arrives while secondary authentication is configured on a tunnel group, and the mishandling is an unchecked return value that ends in a NULL pointer dereference.

Cisco assigns CWE-690, Unchecked Return Value to NULL Pointer Dereference, to this flaw. The advisory's causal chain, in its own words, has three links: the vulnerability is due to "logic errors when secondary authentication is configured on a tunnel group"; the attacker exploits it "by sending a crafted request when connecting to the SSL remote access VPN"; and a successful exploit "could allow the attacker to cause the affected device to reload".

Three details from the advisory pin the exposure down. First, the request is part of connecting, not of being authenticated: "A successful VPN login is not required to reach the affected processing path." Second, the trigger is configuration-dependent: without secondary authentication on a tunnel group, the crafted request never reaches the faulty logic. Third, the flaw was found by Eric Fernald during the resolution of a Cisco Technical Assistance Center support case, which suggests the crash was first seen in a customer deployment rather than in research.

Cisco publishes no source code for ASA or FTD Software, so the exact faulty call is not public. What is public is the boundary of the bug: it is reachable before login, it requires the secondary-authentication configuration, and its single documented impact is a device reload.

How is it exploited?

No proof of concept is public, so the steps below follow the advisory's description of the attack.

1. The attacker connects to the device's SSL remote access VPN endpoint, the login page a remote user reaches before any credentials are accepted.
2. During the connection, the attacker sends a crafted request instead of an ordinary login attempt. The request reaches the code path that applies a tunnel group's secondary authentication.
3. That code path handles the crafted request with a logic error: an unchecked return value ends in a NULL pointer dereference inside the VPN service.
4. The dereference crashes the process, and the device reloads. Every VPN session on the appliance drops with it, and the outage lasts through the reboot.
5. Nothing authenticates the attacker at any step, and the advisory names nothing that stops the same crafted request from being sent again once the device is back up, which could turn one reload into a sustained outage.

How does the attack flow?

The chain is short: an unauthenticated crafted request hits the secondary-authentication path, an unchecked value becomes a NULL dereference, and the whole appliance reloads.

What can an attacker do?

The attacker can crash an exposed firewall or VPN appliance remotely, without credentials, and the advisory names no limit on repeating it. The CVSS vector scores the impact as availability only: confidentiality None, integrity None, availability High. The scope is Changed; Cisco does not explain that choice, which is consistent with a flaw in the VPN service that takes down the whole appliance.

The conditions the attack needs are specific, and they narrow who is exposed:

• Network access to the SSL remote access VPN login service. The attacker does not need a VPN account, valid credentials or a successful login.
• Secondary authentication configured in the tunnel group scope, on a user-configured group or on DefaultWEBVPNGroup. A device with no secondary authentication anywhere is not exposed, whatever its release.
• A vulnerable release. The CVE record's affected list starts at ASA 9.16.1 and FTD 7.0.0, and the advisory's fixed-release table also covers ASA 9.16 and earlier and FTD 7.0 and earlier.

Why does the fix work?

The fixed releases for every line ship in the same advisory, and they correct the logic errors in the secondary-authentication path. Cisco validates the affected and fixed release information itself and publishes no patch diff, so the completeness of the fix rests on the vendor's statement that the first fixed releases listed are the first that contain it.

The mitigation works on the configuration instead. Case 2 removes secondary authentication, the third condition of exposure, so the crafted request has no faulty logic to reach. Case 1, offered only when DefaultWEBVPNGroup has no secondary authentication, disables the tunnel group list instead. Cisco reports that the mitigation was proven successful in a test environment and still treats it as temporary, and it stops working the moment the configuration is reverted.

How do I check if I was compromised?

Cisco states the flaw is being exploited but has not published indicators, attack details, dates or scale, so there are no vendor IOCs to hunt for. What an administrator can check is the crash itself, because a NULL pointer dereference leaves a restart behind:

show version          # uptime since the last reload
show crashinfo        # the crash dump from the last software fault, when one was written

If a device that matches the three exposure conditions reloaded on its own or has a crash dump pointing into the remote access VPN service's code, treat it as a possible exploitation attempt. Capture the crashinfo, note the source addresses in the VPN logs around the reload, and report the case to Cisco PSIRT, which states it is aware of active exploitation. An attempt that did not crash the device leaves no reload or crash dump, so a clean uptime does not prove the device was never targeted.

Timeline

• October 2026: Cisco PSIRT becomes aware of active exploitation of this vulnerability. Cisco has not published a more precise date than the month.
• 2026-10-28: Cisco publishes the advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 with the first fixed releases for thirteen software lines and the CVSS v3.1 8.6 rating. The same day, the CVE-2026-76418 record is published with CWE-690.
• 2026-10-29: The Hacker News reports the advisory and the active exploitation statement.

FAQ

Is my device exposed if I never configured secondary authentication?

No. The exposure needs all three conditions: a vulnerable release, a reachable SSL remote access VPN login service, and secondary authentication configured in the tunnel group scope. Without the last condition the crafted request never reaches the faulty logic, and Case 2 of Cisco's mitigation is precisely to remove it.

Does the attacker need valid VPN credentials?

No. The advisory states that "a successful VPN login is not required to reach the affected processing path", and the CVSS vector carries Privileges Required: None. The attack happens during connection, before any credential could be checked.

Does turning off the tunnel group list remove the exposure?

Not by itself. Cisco warns that if tunnel-group-list enable is absent or was removed with no tunnel-group-list enable, the default tunnel group DefaultWEBVPNGroup still exposes the device when it uses secondary authentication. Check the default group for secondary-authentication-server-group regardless of the group list setting.

Is this vulnerability in the CISA KEV catalog?

No. The CISA Known Exploited Vulnerabilities catalog does not list CVE-2026-76418 as of October 29, 2026, checked against the catalog's JSON feed on that date. The active-exploitation statement comes from Cisco's advisory of October 28, 2026.

Which fixed release should I upgrade to?

The advisory lists one first fixed release per branch, except 9.24, which has two: 9.24.1.27 and 9.24.10.1. Cisco's Software Checker takes a specific release number and returns the first fixed release across every advisory that affects it, which is the safest way to pick a target for a device running an unusual build.

Find exposed ASA and FTD VPN endpoints with Ostorlab

Use Ostorlab Attack Surface Discovery to inventory the internet-facing hosts you own and find the ASA and FTD devices exposing the SSL remote access VPN login service, so you know which ones to check for secondary authentication and upgrade first.

References

• Cisco security advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75, "Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability", first published October 28, 2026, 19:15 GMT: the summary, the three exposure conditions, the tunnel-group configuration guidance, the two mitigation cases, the fixed-software tables, the active-exploitation statement and the Eric Fernald TAC-case credit: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-tunnel-dos-s6mgkb75 (checked October 29, 2026)
• CVE-2026-76418 record, published October 28, 2026 by the Cisco CNA, with the CVSS v3.1 8.6 base vector, CWE-690, and the per-release affected list: https://www.cve.org/CVERecord?id=CVE-2026-76418 (checked October 29, 2026)
• The Hacker News, "Cisco Patches Actively Exploited ASA and FTD VPN Flaw That Can Crash Firewalls", October 29, 2026: https://thehackernews.com/2026/10/cisco-patches-actively-exploited-asa.html (checked October 29, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, checked for CVE-2026-76418 on October 29, 2026 (not listed): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json