All articles

NewsOctober 29, 20265 min read

Cisco ASA/FTD CVE-2026-76418: who is exposed, how to mitigate

The Cisco ASA and FTD DoS zero-day hits SSL VPN with secondary authentication: conditions, CVSS 8.6, fixed releases, mitigation and the CISA KEV listing.

Hands on a laptop with a glowing VPN icon connected to network symbols

On 28 October 2026 Cisco published its advisory on CVE-2026-76418 in Secure Firewall ASA and Secure Firewall Threat Defense (FTD), already exploited as a zero-day. We covered it on 29 October based on the CERT-FR notice, which only reported the denial-of-service risk and the affected versions. Since then BleepingComputer, SecurityWeek, CSO Online, the Canadian Centre for Cyber Security and INCIBE-CERT have filled in what was missing: the affected component, the configuration conditions, a temporary mitigation and the addition to the CISA KEV catalog.

The flaw: secondary authentication on tunnel groups

According to Cisco’s description as reported by the outlets, the vulnerability is caused by logic errors in the Remote Access SSL VPN service when secondary authentication is configured on a tunnel group. A remote, unauthenticated attacker sends a crafted request while connecting to the SSL VPN and causes the device to reload unexpectedly, resulting in a denial of service. SecurityWeek quotes a clarification from Cisco: a successful VPN login is not required to reach the vulnerable code path.

The CVSS score is 8.6 (high), according to SecurityWeek and CSO Online. The described impact concerns availability: no source mentions code execution or data access. In MITRE ATT&CK terms the technique remains T1499.004 (Endpoint Denial of Service: Application or System Exploitation), as noted in our first article.

Who is actually exposed

Three conditions must all be true (SecurityWeek, CSO Online, INCIBE-CERT):

  • the firewall runs an unpatched ASA or FTD release;
  • the SSL VPN login service is reachable: the running configuration contains the webvpn keyword and SSL VPN is enabled on at least one interface;
  • at least one affected tunnel group uses secondary authentication (secondary-authentication-server-group).

The advisory, quoted by CSO Online, explains how to check tunnel groups. If tunnel-group-list enable is configured, check all of them, including the default DefaultWEBVPNGroup. If the command is absent or was removed with no tunnel-group-list enable, still check DefaultWEBVPNGroup: disabling the group list does not remove exposure when the default group uses secondary authentication.

According to SecurityWeek, cloud-delivered firewall and management offerings, Secure Access and Secure Firewall Management Center (FMC) are not vulnerable.

Fixed releases and one open point

Our first article flagged an unreadable value for the 9.24 branch in the French notice. The Canadian Centre for Cyber Security and CSO Online clear it up: the 9.24 fixes are 9.24.1.27 and 9.24.10.1. The fixed releases are:

  • ASA: 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, the 9.23 branch (see below), 9.24.1.27 and 9.24.10.1;
  • FTD: 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 and 10.1.1.

For the 9.23 branch the sources disagree: the Canadian Centre for Cyber Security lists 9.23.1.4, while CSO Online, like CERT-FR before it, lists 9.23.1.48. Before planning the upgrade, check the exact release in Cisco’s advisory or with Cisco Software Checker.

The same Canadian notice (AV26-1102) also covers Node.js vulnerabilities in Cisco Smart Software Manager On-Prem, fixed in version 10-202610: that is a separate advisory, not to be confused with this CVE.

Exploitation and context

Cisco learned of the exploitation in October but has shared no indicators of compromise and no information on attackers or targets (BleepingComputer, SecurityWeek). On 29 October CISA added CVE-2026-76418 to its Known Exploited Vulnerabilities catalog, as reported by the Canadian Centre for Cyber Security. According to SecurityWeek, the flaw surfaced during a Cisco TAC support case and is credited to Eric Fernald.

This is the second DoS zero-day in the ASA and FTD SSL VPN in a few months, after CVE-2026-20349 in August, which we have already covered. SecurityWeek notes that it is unclear whether the same actor is behind both. As for the attack surface, BleepingComputer reports that Shadowserver tracks more than 51,000 Cisco ASA SSL VPN devices exposed online, without knowing how many are already patched or are honeypots: this figure comes from a single source.

Impact for European and Italian organisations

The affected combination, an Internet-facing SSL VPN with a second factor on the tunnel group, is the typical corporate remote-access setup. An attacker without credentials can therefore reload the firewall and take down both the perimeter and remote work. For NIS2 entities this is an exploited vulnerability on a perimeter device: it must be handled with documented priorities and timelines, and a significant outage must be assessed for notification to CSIRT Italia at ACN. In healthcare, where doctors and suppliers often rely on the VPN, the risk is that clinical services become unreachable.

What to do now

  1. Check the configuration of every ASA and FTD: webvpn, interfaces with SSL VPN enabled, tunnel-group-list enable and secondary-authentication-server-group on all tunnel groups, DefaultWEBVPNGroup included.
  2. Upgrade to the fixed release for your branch, starting with Internet-facing devices; for the 9.23 branch, confirm the version with Cisco.
  3. If you cannot upgrade right away, consider Cisco’s mitigation: disable secondary authentication on DefaultWEBVPNGroup or on the tunnel groups in the list (according to SecurityWeek, depending on the default group’s settings, disabling the group list is also an option). Cisco tested it in a lab environment but warns that it weakens remote access and may affect functionality and performance: it is a temporary measure to be decided and documented, not an alternative to upgrading.
  4. Watch for reloads: with no indicators available, look for unexpected reloads without configuration changes or hardware faults and sudden drops of many VPN sessions, and preserve the device’s diagnostic information before reloading it manually.
  5. Treat any suspicious reload as a security incident, not as a simple fault.

How ARXDOME helps

ARX Expose shows whether your organisation exposes a VPN portal on the Internet and with which known vulnerabilities. ARX Sentry sends firewall logs to a central collector and the NOC map highlights VPN errors, so a reload or a drop in sessions stays recorded outside the device. ARX Radar reports attacks in progress against your public addresses.

Last updated:

Any questions?

Let’s talk about your company’s needs, with no obligation.

Contact us

Related articles