Tuskira AdvisoryConfirmed (CISA KEV)Last updatedOctober 29, 2026

CVE-2026-76418

Cisco ASA and FTD remote access SSL VPN denial of service, exploited in the wild and on CISA KEV with a Nov 1 deadline; exposed only when secondary authentication is set on a tunnel group

CVE-2026-76418 is a denial of service, not code execution. Someone without a login can send a crafted request to the Remote Access SSL VPN login service on a Cisco Secure Firewall ASA or FTD device and make the device reload, which drops every VPN session and every connection through the firewall until it comes back. Cisco says it is aware of active exploitation, and CISA added it to the Known Exploited Vulnerabilities catalog on October 29, 2026 with a federal due date of November 1. Cisco scores it 8.6, below the 9.0 bar we normally use; it is here because it is on KEV and because the fix is a reboot-and-reload cycle on a device that sits in front of everything else.

A device is exposed only when two things are true. SSL VPN (webvpn) is enabled on an interface that attackers can reach, and secondary authentication is configured on a tunnel group, including the default one. That makes this one of the easiest advisories on this page to check. Cisco has released fixed software for every ASA and FTD train. It says no workaround addresses the flaw and offers a mitigation that removes secondary authentication, which lowers VPN security, so treat that as a last resort.

Vendor
Cisco
Product
Secure Firewall ASA Software and Secure Firewall Threat Defense (FTD) Software
Affected versions
ASA before 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 before 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.1. Only when SSL VPN is enabled and secondary authentication is configured on a tunnel group
Vulnerable component
Remote Access SSL VPN login service (webvpn) with secondary-authentication-server-group on a tunnel group
CVSS
8.6 (Cisco as CNA); NVD has not added its own score. Published here because it is on CISA KEV, not for its score
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H (Cisco)
CWE
CWE-690 Unchecked Return Value to NULL Pointer Dereference
Exploitation
Confirmed (CISA KEV)
CISA KEV added
October 29, 2026
Patch
Cisco advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 (Oct 28, 2026), bug ID CSCwx26625. Fixed releases per train in the body. Cisco says no workaround addresses the flaw; it offers a mitigation that lowers VPN security
Vendor fixResearcher advisory

Is it reachable for you?

What it is. Cisco's advisory describes logic errors in how the SSL VPN login service handles a connection when secondary authentication is configured on a tunnel group. A crafted request during the connection reaches the affected code path before any login succeeds, triggers a NULL pointer dereference (CWE-690), and the device reloads. Cisco credits Eric Fernald, who found it during a TAC support case, and tracks it as bug CSCwx26625. CISA's entry marks forensic triage as not required, unlike the GitLab listing from the same day, since the outcome is an outage rather than access.

Not to be confused with. CVE-2026-20349, the ASA and FTD flaw CISA added to KEV on August 11, 2026, and the September 2025 ASA entries. Those are separate bugs with separate fixes. Being patched for them does not cover this one.

Checks, in order. Run these on devices your organization manages. They read configuration and change nothing.

  1. Is SSL VPN enabled? On ASA, run show running-config webvpn. The device is in scope if the output contains webvpn with enable <interface_name> on at least one interface. If no interface is enabled, stop here; the device is not exposed to this flaw.
  2. Is the login service reachable? The enabled interface is almost always the outside one, because remote access VPN exists to be reached from the internet. Confirm from outside your network that the VPN login page answers.
  3. Is secondary authentication configured on any tunnel group? This is the check that decides it. Run show running-config tunnel-group and look for secondary-authentication-server-group. Per Cisco's advisory, if tunnel-group-list enable is present, check every tunnel group including DefaultWEBVPNGroup, not only the ones shown on the login page. If tunnel-group-list enable is absent or was removed, check DefaultWEBVPNGroup; Cisco says disabling the group list does not remove exposure if the default group uses secondary authentication.
  4. On FTD, check the deployed policy. In FMC, go to Devices, VPN, Remote Access and review each connection profile's secondary authentication setting; in FDM, Remote Access VPN. Then confirm against the running config on the device, since a policy that was edited but not deployed doesn't count.
  5. Which release are you on? show version on ASA, or the device page in FMC or FDM. Compare against the first fixed releases below.
  6. What depends on this device? A reload takes down not just VPN users but every flow through the firewall and any failover pair's active unit. Note what sits behind it and how long a reload takes on your hardware.

First fixed releases, from Cisco's advisory.

  • ASA: 9.16 and earlier, 9.16.4.104. 9.18, 9.18.4.96. 9.20, 9.20.4.50. 9.22, 9.22.3.200. 9.23, 9.23.1.48. 9.24, 9.24.1.27 and 9.24.10.1.
  • FTD: 7.0 and earlier, 7.0.11. 7.2, 7.2.13. 7.4, 7.4.9. 7.6, 7.6.7. 7.7, 7.7.14. 10.0, 10.0.3. 10.1, 10.1.1.
  • Not vulnerable, per Cisco: Cloud-delivered Firewall, cloud-delivered FMC, Secure Access, and Secure FMC Software itself.

Compensating controls until you patch

Upgrading is the fix, and Cisco says no workaround addresses the vulnerability. What follows is Cisco's mitigation and the limits it comes with. Test on one device before rolling out.

  • Cisco's mitigation, case 1. If DefaultWEBVPNGroup does not use secondary authentication, run no tunnel-group-list enable. Users then have to know their connection profile name instead of picking it from a list. Per the advisory this only helps when the default group is clean; it does nothing for a default group that has secondary authentication set.
  • Cisco's mitigation, case 2. If DefaultWEBVPNGroup uses secondary authentication, run no secondary-authentication-server-group. Cisco says plainly that this lowers the remote access VPN security posture. You are removing a second factor from VPN login to avoid an outage. Decide that with whoever owns the risk, not in a change ticket at 2 AM.
  • Restrict who can reach the login page. If your VPN population comes from known networks, a control-plane ACL or upstream filter on the webvpn interface reduces who can send the crafted request. Most remote access deployments can't do this, which is why Cisco doesn't list it.
  • Prepare for the reload, not just against it. Confirm failover pairs are healthy, know the reload time, and make sure monitoring alerts on an unexpected reload rather than waiting for users to call.

Cisco says the mitigation was tested in a lab and customers should evaluate its effect in their own environment. It strongly recommends upgrading to a fixed release.

What to look for in logs

  • Unexpected reloads of an ASA or FTD device with SSL VPN enabled. Check show version for the last reload reason and uptime, and show crashinfo on ASA.
  • Crash files or core dumps on the device following connection attempts to the VPN login page.
  • Bursts of SSL VPN connection attempts that never complete a login, especially shortly before a reload.
  • A failover pair switching active units without a planned change.

How Tuskira helps

Tuskira is an agentic cyber defense platform that connects to the 200+ security and IT tools you already run. When a new critical vulnerability lands, Tuskira answers three questions.

Is there a reachable path? For example, whether an ASA or FTD device in the affected range has webvpn enabled on an internet-facing interface and secondary-authentication-server-group set on any tunnel group, including DefaultWEBVPNGroup.

Would your controls stop it? Tuskira tests the controls you already run, such as your WAF, firewall rules and EDR, against the path.

Can you close the gap now? Quell stages the compensating control change through your existing tools, with your approval, then re-tests to confirm the path is closed.

The vendor patch is the complete fix. Quell reduces exposure and proves your controls work in the meantime.

See how Quell handles emerging threats

FAQ

Does CVE-2026-76418 let an attacker into my network?

No. It is a denial of service. The device reloads, which drops VPN sessions and traffic through the firewall until it recovers. It does not give an attacker access or code execution.

Is CVE-2026-76418 being exploited?

Yes. Cisco's advisory says the Cisco PSIRT became aware of active exploitation in October 2026, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 29, 2026 with a November 1 due date.

Am I exposed if I don't use secondary authentication on my VPN?

Per Cisco, no. The flaw is reached only when secondary authentication is configured on a tunnel group, including the default group. Check every tunnel group, not only the ones users see on the login page.

Why is an 8.6 on this page?

Our bar is Critical or on CISA KEV. This one is on KEV with confirmed exploitation, and the thing that goes down is the device everything else sits behind.

Is there a workaround for CVE-2026-76418?

Cisco says no workaround addresses the vulnerability. Its mitigation is to remove secondary authentication from the affected tunnel group or disable the tunnel group list, and it says the first of those lowers your VPN security. Upgrade to the fixed release for your train instead.

Updates

Oct 29, 2026. First published, the day CISA added the CVE to KEV. Cisco published the advisory Oct 28.

Sources

We publish an advisory when a vulnerability is Critical or on CISA KEV, has one identifiable component to check, and has a public proof of concept or reported exploitation. Advisories are updated as exploitation status changes.