Extra Login Security Gave Cisco VPNs an Off Switch

Picture a client's whole remote workforce dropping off the VPN at once because a stranger sent one bad request. CISA added CVE-2026-76418 to its Known Exploited Vulnerabilities list on 29 October 2026, a day after Cisco said attackers are crashing ASA and FTD firewalls this way. If you look after Cisco firewalls whose VPN asks for a second login check, check each client's firewall today.

TL;DR

• CISA listed CVE-2026-76418 as exploited on 29 October 2026: attackers are rebooting Cisco ASA and FTD firewalls through the SSL VPN login without logging in.
• A client is exposed if the firewall runs a release below the fixed builds, SSL VPN is on, and a tunnel group uses secondary authentication, per Cisco's advisory.
• Save crash files, then patch to Cisco's fixed release (e.g. ASA 9.22.3.200, FTD 7.6.7); removing the second login check is only a stopgap, Cisco says.
• The impact is outage, not theft: each reload restarts the firewall and drops its VPN sessions, per NVD.

What is CVE-2026-76418 and is it being exploited?

CVE-2026-76418 is a denial-of-service bug (a flaw that crashes a system rather than breaking into it) in the Remote Access SSL VPN of Cisco Secure Firewall ASA (Adaptive Security Appliance) and FTD (Firewall Threat Defense) software, letting an attacker with no login force the firewall to reload, per Cisco's advisory. It is being exploited: Cisco says its product security team "became aware of active exploitation" in October 2026, and CISA added it on 29 October 2026 and set a due date of 1 November 2026 for federal agencies.

The trigger only exists when secondary authentication, a second login server checked after the first, is set on a tunnel group (a VPN connection profile). Cisco scores it 8.6 out of 10.

Which Cisco ASA and FTD versions are affected?

Any ASA or FTD release below the first fixed build for its branch is affected when SSL VPN is enabled on an interface and secondary authentication is set in tunnel-group scope. Cisco lists Cloud-delivered Firewall, cdFMC, Secure Access and Secure Firewall Management Center software as not affected.

Fixed versions from Cisco's advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75.

How do I check if my clients' Cisco firewalls were hit?

All four steps run on the firewall itself (the ASA command line, or FTD's > prompt and expert mode) or from an outside laptop; none needs a server shell, and no server scan clears a firewall. Cisco gives no start date beyond "October 2026" and an ASA keeps only its latest crash file, so also search the client's oldest retained syslog; earlier crashes can't be ruled out.

1. Preserve evidence. Save the config, logging setup and crash files before the device reboots again, using Cisco's crash data guide and troubleshoot file note.

   # On your evidence server
   D=/srv/evidence/client-fw-2026-10-30; sudo mkdir -p "$D"
   

   ! ASA: save the output of the first three to the ticket
   show running-config
   show run logging
   dir disk0:
   ! copy each crashinfo_lina.* file; give "$D"'s path at the scp prompt
   copy flash:/<crashinfo-file> scp:
   ! FTD, at the > prompt
   system generate-troubleshoot all
   file secure-copy <evidence-host> <user> /srv/evidence/client-fw-2026-10-30 <troubleshoot-file>
   

   # Back on the evidence server
   sudo find "$D" -type f -exec sha256sum {} + | sudo tee "$D.sha256"
   

   Pass: $D.sha256 lists every copied file.

2. Check exposure. Read the release, then look for the two settings Cisco names: an enable <interface> line under webvpn, and secondary-authentication-server-group on a tunnel group (only DefaultWEBVPNGroup counts when tunnel-group-list enable is absent). On FTD, run show version system and open FMC's Devices > VPN > Remote Access (FDM: Remote Access VPN).

   show version | include Version
   show running-config webvpn
   show running-config tunnel-group
   

   Pass: the release is at or above the table's fixed build, or either setting is missing.

3. Look for crashes. A crash file, a short uptime or the First Crash in tid marker means an unplanned reload, per Cisco's unexpected reload guide.

   ! ASA
   show crashinfo
   show version | include up
   dir coredumpfsys
   

   # FTD: type expert at the > prompt first
   sudo grep -a "First Crash in tid" /ngfw/var/log/ASAConsole.log
   ls -l /mnt/disk0/ /ngfw/var/data/cores/
   

   Pass: none of these since the last planned reboot. A crash on a device step 2 marks exposed is a likely hit: open a Cisco TAC case quoting CVE-2026-76418 and attach step 1's files.

4. Test from outside. Cisco's ASDM and WebVPN note shows the ASA login page at /+CSCOE+/logon.html; this checks port 443 only, so use the client's asset inventory as the main list.

   nmap -Pn -p 443 <vpn-host>
   curl -sk -o /dev/null -w '%{http_code}\n' https://<vpn-host>/+CSCOE+/logon.html
   

   Result: an open port with a 200 means the VPN login faces the internet; patch that firewall first.

How do I fix Cisco ASA and FTD CVE-2026-76418?

Close the hole first; there is no implant to clean up, because Cisco reports reloads, not break-ins.

1. Preserve evidence with check step 1 before upgrading, since the upgrade reboots the device and Cisco's crash data guide warns that files rotate.

2. Patch each firewall to the first fixed build in the table. Pass: step 2 shows that build or later.

3. Stopgap if the upgrade can't go in today (agree it with the client first). Use case 1 if DefaultWEBVPNGroup has no secondary authentication, case 2 if it does.

   ! Case 1
   webvpn
    no tunnel-group-list enable
   ! Case 2
   tunnel-group DefaultWEBVPNGroup general-attributes
    no secondary-authentication-server-group
   

   Case 1 means users must know the right connection profile name; case 2 weakens VPN login security, per Cisco. Pass: rerun step 2 and no in-scope tunnel group shows the setting.

4. Remove footholds. Cisco reports no code execution, so nothing is planted; if step 3 found a crash, send step 1's files to TAC and ask Cisco to confirm the cause.

5. Rerun checks 2 to 4. Pass: fixed build, no new crash, same port state.

Where KinoSec fits

An autonomous external network pentest from KinoSec maps what each client exposes to the internet, so a Cisco SSL VPN login sitting on a client's edge lands in the report with its remediation next to it. That matters here because CVE-2026-76418 needs no login: a reachable VPN page on a vulnerable build is the attacker's whole starting point. Because it runs continuously and on demand, it also tests what an attacker could reach from the outside after someone re-exposes a firewall. It does not read tunnel-group settings; check steps 2 and 3 do that. Offer it to clients as the outside view that tells you which firewalls to check first.

Frequently Asked Questions

Does CVE-2026-76418 affect Cisco's cloud-delivered firewalls?

No. Cisco's advisory lists Cloud-delivered Firewall, cdFMC, Secure Access and Secure Firewall Management Center software as not affected. The bug sits in ASA and FTD software running the SSL VPN, so the firewall itself needs checking even when FMC manages it.

How do I check if my clients' Cisco ASA was hit by CVE-2026-76418?

Run show running-config tunnel-group and look for secondary-authentication-server-group. Run show crashinfo to see whether the ASA crashed. On FTD, run the expert-mode grep in step 3 of "How do I check if my clients' Cisco firewalls were hit?".

Does turning off tunnel-group-list break VPN logins?

It changes them. Cisco says that after no tunnel-group-list enable, users must know the correct connection profile name. Cisco's group drop-down note adds that users who connect with a group URL never saw the drop-down, because the URL picks the group. Keep it only until the fixed build is in.

Can attackers steal data with CVE-2026-76418?

Cisco's score says no: its vector rates confidentiality and integrity impact as none and availability as high, per NVD. The risk is outage, since each reload drops the firewall's VPN sessions until it restarts. SecurityOnline reports no public proof-of-concept exploit yet.