Cisco patches an exploited zero-day DoS in the SSL VPN of its ASA and FTD firewalls

October 29, 2026. Cisco releases fixes for CVE-2026-76418, a denial-of-service flaw in the SSL VPN service of its Secure Firewall ASA and Secure Firewall Threat Defense (FTD) firewalls, already exploited in the wild. 8.6 — the CVSS score of the flaw, which lets an unauthenticated remote attacker force the device to reload. 51,000 — the number of Cisco ASA boxes exposing their SSL VPN to the internet, per Shadowserver. The point that matters: this is the second unauthenticated-triggerable DoS in Cisco’s SSL VPN in three months, and this one fires on a configuration path — secondary authentication on tunnel groups — that many deployments leave enabled.

One request is enough to take the firewall down

The vulnerability lives in the remote access SSL VPN service of ASA and FTD software. Per Cisco’s advisory, it stems from “logic errors when secondary authentication is configured on a tunnel group.” In practice, an attacker can send a crafted request while connecting to the remote access SSL VPN and cause the device to reload unexpectedly — a denial of service that takes down the entire network edge, not just one session.

Two details make the flaw worse than an ordinary robustness bug. First, exploitation requires no authentication: Cisco notes that “a successful VPN login is not required to reach the affected processing path.” Second, Cisco PSIRT says it discovered evidence of active exploitation in October 2026, without providing indicators of compromise or details on targets or attackers. A denial-of-service flaw being exploited blindly against edge equipment is a rare anomaly — most in-the-wild exploitation targets code execution, not rebooting a firewall.

The operational consequence is immediate. On a firewall carrying remote access SSL VPN, a forced reload cuts off every employee’s remote access, drops established sessions, and — depending on topology — degrades the availability of exposed internal services. A repeated attack turns an edge device into a permanent point of failure.

The flaw lives in configuration, not just code

The most misleading thing about CVE-2026-76418 is that it does not affect every ASA and FTD deployment. Three conditions must be met. The device runs a vulnerable software release. The remote access SSL VPN login service is reachable — meaning the webvpn keyword is present in the configuration and SSL VPN is enabled on at least one interface. And secondary authentication is configured in the tunnel-group scope.

That last condition is the key. Cisco recommends checking, if tunnel-group-list enable is configured, all tunnel groups — including the default DefaultWEBVPNGroup — for secondary-authentication-server-group. The advisory stresses a specific trap: if tunnel-group-list enable is absent or has been removed with the no tunnel-group-list enable command, you must still check the default group, because disabling the group list does not remove exposure when that default group uses secondary authentication.

In plain terms, a deployment can believe it is protected because it disabled the group list, while the default group silently keeps secondary authentication active. The flaw rewards legacy configuration — the kind where secondary authentication was added years ago to harden an access path, and forgotten since.

For an administrator who needs to act now, the check is concrete. Run show running-config | include webvpn to confirm the SSL VPN service is present, then inspect each tunnel group — and the default DefaultWEBVPNGroup in particular — for a secondary-authentication-server-group line. If the line is absent, the device is not exposed to this specific flaw even if the VPN is reachable; if it is present and you cannot patch, removing it is the stopgap. And mind the trap Cisco flagged: removing tunnel-group-list enable does not clear the default group, so check it explicitly.

Fixes and workaround

The fixed releases cover all maintained branches. On the ASA side: 9.16.4.104, 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. On the FTD side: 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, and 10.1.1. The 9.16-and-earlier and 7.0-and-earlier branches are only fixed at the listed releases — there is no fix for versions older than those floors.

Cisco offers no workaround that eliminates the vulnerability, but proposes a temporary mitigation for teams that cannot patch right away: disable secondary authentication on the default DefaultWEBVPNGroup or on any user-configured tunnel-group list. On FTD, you should also review the deployed remote access VPN policy and the resulting running configuration in FMC or FDM. Treat this as a short-term stopgap: it shrinks the attack surface by removing the triggering condition, but it also changes your remote-access authentication posture, which carries its own security implications.

Cisco’s message is unambiguous: “Cisco strongly recommends that customers upgrade to a fixed software release to remediate this vulnerability.” The workaround is an emergency measure, not a destination.

An SSL VPN under pressure for months

This flaw is not an isolated event. In August 2026, Cisco had already patched CVE-2026-20349, another DoS zero-day in ASA and FTD firewalls with SSL listen sockets enabled, also exploited in the wild. The year before, the ArcaneDoor campaign chained the CVE-2024-20353, CVE-2024-20359, CVE-2025-20362, and CVE-2025-20333 zero-days against Cisco gear, prompting CISA to issue Emergency Directive 25-03. And earlier in October 2026, Cisco warned of an exploited zero-day in its Secure Email Gateway.

The underlying statistic shows the trend. Since November 2021, CISA has flagged 101 Cisco flaws as exploited in the wild, seven of them also abused by ransomware gangs. Cisco’s SSL VPN has become a recurring denial-of-service surface, and Shadowserver still counts more than 51,000 ASA boxes exposing that service to the internet.

The same day, Cisco Talos revealed that an APT actor tracked as UAT-11473 had exploited CVE-2026-20127, an authentication bypass in Cisco SD-WAN Catalyst Controller, to deploy a malicious framework named KeyDrift (components PolyFlame and LittleFilch) designed to intercept decrypted control traffic and exfiltrate data-plane keying material. The activity, targeting space, defense, and policy-research sectors, shares infrastructure with Volt Typhoon’s Silent Train covert network. The two disclosures, published the same day, draw a single conclusion for network teams: Cisco edge equipment is under active watch, and denial of service is no longer a theoretical nuisance.

Verdict

If you run ASA or FTD firewalls exposing SSL VPN, schedule an upgrade to a fixed release this week: this is a flaw exploited in the wild, triggerable without authentication, and a fix exists for every maintained branch. If you cannot patch immediately, disable secondary authentication on DefaultWEBVPNGroup and on any tunnel-group list — but check the impact on your access policy first: this workaround removes the triggering condition, at the cost of a weaker authentication posture you will have to own. And use the incident to inventory your SSL VPN surface: search your configurations for the webvpn keyword, remove tunnel groups with secondary authentication that are no longer needed, and restrict access to the VPN portal to the addresses that genuinely require it. On a firewall, the best protection against denial of service is not only the patch — it is having less service exposed to be taken down.

References

• The Hacker News — Cisco Patches Actively Exploited ASA and FTD VPN Flaw That Can Crash Firewalls (October 29, 2026)
• BleepingComputer — Cisco warns of firewall zero-day exploited to crash SSL VPN devices (October 29, 2026)
• Cisco Talos — UAT-11473 exploits CVE-2026-20127, deploys KeyDrift keying-material theft framework (October 29, 2026)