Cisco Confirms a Second Exploited ASA and FTD VPN Denial-of-Service Flaw in 11 Weeks, and the Builds That Fixed the First One Do Not Fix It

Cisco said on Wednesday, October 28, that attackers are exploiting CVE-2026-76418, a flaw in the Remote Access SSL VPN service of its Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) software that lets an unauthenticated remote attacker make a firewall reload. It is the second exploited flaw of that kind in 11 weeks. Cisco’s August advisory for CVE-2026-20349 described the same effect through the same VPN service, and we reported on it when CISA gave federal agencies until August 14 to apply the fix.

The build numbers matter more than the headline. In all 13 software rows Cisco publishes, this week’s first-fixed release is higher than the one Cisco lists for August’s flaw, so a firewall that stopped at August’s fix, or at the September hardening release that carries the same builds, is still affected when its SSL VPN login is reachable and a tunnel group uses secondary authentication. SecurityWeek reported the advisory on Thursday morning. When we checked at 10:19 UTC on October 29, Cisco’s advisory was still at version 1.0, the CISA Known Exploited Vulnerabilities (KEV) catalog (version 2026.10.28) did not list the flaw, and NVD had not yet analyzed it.

What Cisco disclosed on October 28

Advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 went out at 19:15 GMT on Wednesday, according to both the advisory page and the CSAF file Cisco attaches to it. It rates the flaw High, with a CVSS 3.1 base score of 8.6 (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H), and lists the weakness as CWE-690, unchecked return value to NULL pointer dereference. NVD carries only that Cisco-supplied score.

• Cause. Cisco says the flaw “is due to logic errors when secondary authentication is configured on a tunnel group,” and that an attacker triggers it “by sending a crafted request when connecting to the SSL remote access VPN.”
• No login needed. “A successful VPN login is not required to reach the affected processing path.”
• Effect. The device reloads unexpectedly, which is a denial of service. Cisco does not say how long a reload keeps a firewall out of service, or whether repeated requests can keep it down.
• Exploitation. “In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability.” Cisco names no attacker, no victim and no indicator of compromise. SecurityWeek’s headline calls the flaw a zero-day; Cisco’s advisory does not use that word and does not say whether exploitation began before fixes were available.
• Discovery. “This vulnerability was found by Eric Fernald during the resolution of a Cisco Technical Assistance Center (TAC) support case.” The advisory does not say whether that case is how Cisco learned of the attacks.
• Not affected. Cisco’s cloud-delivered Firewall and cloud-delivered Firewall Management Center, Secure Access, and Secure Firewall Management Center (FMC) software.

Is your firewall exposed?

Cisco says a device is affected only when three things are true: it runs a vulnerable release, “the SSL remote access VPN login service is reachable,” and “secondary authentication is configured in the tunnel group scope” the advisory describes. In practice that means three checks:

1. Is SSL VPN turned on? If the running configuration contains the webvpn keyword and SSL VPN is enabled on at least one interface, this part of the condition is met. On FTD, Cisco points to Devices > VPN > Remote Access in FMC or Remote Access VPN in Firewall Device Manager (FDM), and says to review the deployed policy and the resulting device running configuration.
2. Does any tunnel group use secondary authentication? Look for secondary-authentication-server-group. If tunnel-group-list enable is configured, Cisco says to check all tunnel groups, including the default one, DefaultWEBVPNGroup, and adds: “This check is not limited to profiles that are displayed in the group list on the login page.” If the list is not enabled, check the default group anyway, “because disabling the group list does not remove exposure when that default group uses secondary authentication.”
3. Which release is running? Compare it with the table below, or use the Cisco Software Checker that the advisory points to.

Cisco’s advisory header reads “No workarounds available,” and its Workarounds section says none addresses the vulnerability, but it then describes a mitigation: take secondary authentication away from the tunnel groups that use it. If DefaultWEBVPNGroup does not use secondary authentication, Cisco says to disable the tunnel group list with no tunnel-group-list enable in WebVPN configuration mode, after which users must know the right profile name instead of choosing it from a list. If the default group does use secondary authentication, the command is no secondary-authentication-server-group, and Cisco warns that “the security posture is lowered for remote access VPN.” Cisco’s own advice is to upgrade: it “strongly recommends upgrading” to a fixed release, and it tells customers to evaluate any mitigation against their own environment first.

The August fixes do not cover it

The two flaws look alike on paper. Both are rated High with the same vector and the same 8.6 score, both sit in the Remote Access SSL VPN service, and in both cases Cisco says its security team learned of active exploitation, in August and in October. They differ underneath. August’s CVE-2026-20349 is, in Cisco’s words, due to “insufficient error checking when processing HTTP requests,” and is listed under CWE-244, improper clearing of heap memory before release, which CISA’s catalog calls a heap inspection vulnerability. This week’s flaw is a logic error tied to secondary authentication. August’s advisory lists three feature settings that can enable the SSL listen sockets (IKEv2 remote access VPN with client services, SSL VPN and, on FTD, Zero Trust Network Access), while this week’s needs SSL VPN plus secondary authentication, which is a narrower set of devices.

Cisco revised the August advisory on September 16 (version 1.1) to update its fixed-release table and to point to the Secure Firewall hardening release it published that day, which it rates Critical. We compared the first-fixed builds in the August advisory, the September hardening advisory and this week’s advisory. The August table and the hardening advisory list the same builds, and this week’s advisory lists a higher one in every row:

Read the table by train. A firewall running ASA 9.20.4.49 has Cisco’s August fix and is still below 9.20.4.50, the first fixed release for this flaw; the same is true of FTD 7.4.8 against 7.4.9. Cisco prints 9.22.3.200 for the 9.22 train, up from 9.22.3.26, and two fixed releases for the 9.24 train. Do not compare hot-fix builds by number. Cisco’s September advisory lists ASA hot-fix builds such as 9.20.4.235 as affected by that month’s vulnerabilities, even though the number is higher than the fixed 9.20.4.49, and says customers on them “must install the listed first fixed release.” This week’s advisory does not discuss hot fixes, so check those builds with the Software Checker instead of by eye.

Why the advisory arrived out of cycle

Cisco’s risk-based disclosure model, in effect since July, schedules advisories for the first and third Wednesday of each month at 16:00 UTC, and says that “in exigent circumstances (such as observed exploitation of greater-severity vulnerabilities),” advisories continue to appear outside that schedule. October 28 was the fourth Wednesday of the month and the firewall advisory appeared at 19:15 GMT; August’s was published on a Tuesday, August 11, at 16:39 GMT. Three hours and 15 minutes earlier on October 28, Cisco posted its advance notification for November 4, which lists Identity Services Engine, UCS Central and Unified Communications Manager, not Secure Firewall. The same notice says Cisco “does not plan to publish any more security hardening advisories” for the rest of 2026, with the next planned for January 20, 2027. Nothing on Cisco’s published calendar offers a scheduled firewall release before then, so plan the upgrade as an emergency change rather than waiting for a scheduled window.

What defenders can do now

• Work out exposure first. Run the three checks above on every ASA and FTD device that terminates SSL VPN, including the default tunnel group.
• Upgrade to at least the first fixed release for your train, and treat August’s builds as not enough. Cisco lists no workaround that addresses the flaw.
• If you cannot upgrade today, weigh Cisco’s mitigation against its cost, since removing secondary authentication lowers the security of the VPN, and test it before you roll it out.
• Look for unexplained reloads. Cisco lists no indicators and, unlike its August advisory, which links Snort rules 46897 and 59654, links no Snort rule to this one. The only effect Cisco describes is an unexpected reload, so unexplained reloads on firewalls with SSL VPN and secondary authentication are worth a look. That is our inference, not Cisco guidance.
• Watch the KEV catalog. CISA listed August’s flaw on the day Cisco published it, August 11, with a due date of August 14, and its catalog already holds 14 Cisco ASA and FTD entries by our count. This flaw was not in the catalog version we read, which was released at 19:00 UTC on October 28, 15 minutes before Cisco’s advisory. A listing would give U.S. federal agencies a due date.

What is still unknown

Cisco has not said who is behind the attacks, how many devices were hit, or what the attacks looked like. SecurityWeek writes: “It’s unclear whether both flaws were exploited by the same threat actor.” Cisco gives no count of exposed devices, and we did not use outside scan figures. NVD’s record was still at status Received when we looked, so the 8.6 score is Cisco’s own.

Sources and method

We read Cisco advisories cisco-sa-asaftd-tunnel-dos-s6mgkb75, cisco-sa-asaftd-vpn-dos-dzv4mQFF and cisco-sa-hardening-asaftdfmc-uvpPROhN, the CSAF file for the first of them, the advance notification for November 4, Cisco’s risk-based disclosure page and its advisory RSS feed, the NVD records for CVE-2026-76418 and CVE-2026-20349, MITRE’s CWE-690 and CWE-244 pages, CISA’s KEV feed (catalog version 2026.10.28) and SecurityWeek’s report. We parsed the first-fixed tables out of the three advisories’ HTML and compared them row by row, and the count of 14 Cisco ASA and FTD entries in KEV (Firepower Management Center excluded) is ours, from the feed. The checks were made between 10:00 and 10:20 UTC on October 29. We have not tested anything against a firewall.