Sunday, November 1, 2026
News

Cisco ASA zero-day: the two config checks and the fix, due Nov 1

CVE-2026-76418 needs no VPN login, only SSL VPN switched on and secondary authentication set on a tunnel group. CISA set November 1 as the due date for federal agencies. Both versions of Cisco's stopgap cost you something.

Server rack with blinking green lights

Cisco said on October 28 that attackers are using a flaw in the Remote Access SSL VPN of two Cisco firewall software lines, Secure Firewall Threat Defense (FTD) and Secure Firewall ASA, to reload firewalls from the internet. The bug, CVE-2026-76418, is rated 8.6 on CVSS 3.1. The attacker does not need an account: Cisco says the faulty code runs before any VPN login has to succeed. Cisco's product security team learned of the attacks in October. It has not said who is behind them, who was hit or how many devices. CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 29, and the listed due date is November 1.

A reload drops every remote worker on the VPN, and a firewall that keeps restarting is a network that is down. The result is the same as with CVE-2026-20349, the ASA and FTD VPN flaw Cisco patched in August, which also let attackers force reloads and also went on CISA's list. Cisco has not said whether the same group used both. Teams that patched in August should still check their builds against the October table below.

Are you exposed? Two checks

Cisco says a device is vulnerable only when three things are true: it runs an affected release, the SSL VPN login page is reachable, and secondary authentication is set on a tunnel group. The release is in the table. The other two come from the running config.

First, look for webvpn with enable <interface_name> under it for at least one interface. On FTD, look under Devices > VPN > Remote Access in Management Center, or Remote Access VPN in Device Manager. If SSL VPN is off everywhere, this flaw does not reach you.

Second, look for secondary-authentication-server-group in the tunnel groups. Which ones depends on one line. If tunnel-group-list enable is set, check every tunnel group, including DefaultWEBVPNGroup. If it is not set, check DefaultWEBVPNGroup. Cisco notes that the check is not limited to the profiles users see on the login page, so a forgotten test profile counts.

Cisco's cloud-delivered firewall, cloud-delivered Management Center, Secure Access and Secure Firewall Management Center software are not affected.

First fixed release by train

ASA train First fixed FTD train First fixed
9.16 and earlier 9.16.4.104 7.0 and earlier 7.0.11
9.18 9.18.4.96 7.2 7.2.13
9.20 9.20.4.50 7.4 7.4.9
9.22 9.22.3.200 7.6 7.6.7
9.23 9.23.1.48 7.7 7.7.14
9.24 9.24.1.27 and 9.24.10.1 10.0 10.0.3
10.1 10.1.1

On FTD, do not mix this up with CVE-2026-76489, a separate medium-rated Snort 3 bug that Tech Insider notes is fixed in different builds (7.4.8 for that one, 7.4.9 for this one). Cisco's Software Checker gives the answer for a specific build.

The stopgap, two ways, and what each costs

Cisco's advisory says no workaround is available, then describes a mitigation that depends on the default group:

  • If DefaultWEBVPNGroup has no secondary authentication, turn off the group list with no tunnel-group-list enable in WebVPN configuration mode. The cost: users no longer pick a profile from a list and must know the right connection profile name.
  • If DefaultWEBVPNGroup does use secondary authentication, remove it with no secondary-authentication-server-group. The cost: Cisco says this lowers the security of the remote access VPN.

Cisco says it tested the mitigation in a test environment and tells customers to try it in their own setup first. It still "strongly recommends upgrading to the fixed software."

The deadline

The KEV entry gives November 1, three days after the listing. A mirror of the KEV feed on GitHub shows the split under CISA's Binding Operational Directive 26-04: three days for exposed devices, 14 days for those that are not. The directive binds US federal civilian agencies only, but a VPN login page is internet-facing by design, so most companies running this setup should treat the three-day clock as theirs.

What IT teams should do

  1. List every ASA and FTD appliance, including ones an MSP runs for you, with its train and build.
  2. Run the two config checks above on each one. Devices without SSL VPN, or with no secondary authentication on the relevant tunnel groups, are not exposed to this flaw.
  3. Upgrade exposed devices to the first fixed release for their train, and confirm the build in Cisco's Software Checker. Do not assume an August patch covers it.
  4. If an exposed device cannot be upgraded by November 1, apply the stopgap that matches its default group, tell users what changes, and set a date to undo it after the upgrade.
  5. Look back at firewall reloads since October that nobody can explain, since Cisco learned of the attacks that month.

Related: CISA's earlier Cisco email gateway listing and three VeloCloud zero-days since July.

Sources