AllTech
On this page
Field notes from the engineering team
On October 28, 2026, Cisco published an advisory for CVE-2026-76418, a flaw in the SSL remote access VPN service of Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software. One day later, CISA added it to its Known Exploited Vulnerabilities catalog.
An attacker on the internet does not need an account. A crafted request to the VPN login is enough to make the firewall reload. That means a dropped connection for every office and remote user behind it, and an attacker can repeat it.
This is a denial of service flaw, not a break-in. It still matters for any organization that depends on one firewall to keep its sites and remote staff online.
The short version
| Item | Detail |
|---|---|
| CVE | CVE-2026-76418 (Cisco advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75) |
| Severity | High, CVSS v3.1 8.6 (Cisco’s rating). Attack type: unauthenticated, remote. |
| What it is | Logic errors in the SSL remote access VPN service when secondary authentication is configured on a tunnel group. A crafted request makes the device reload. |
| Impact | Denial of service. The advisory describes an unexpected reload, not code execution or data theft. |
| Affected | Cisco Secure Firewall ASA and Secure FTD software, when the SSL remote access VPN login is reachable and a tunnel group uses secondary authentication. |
| Not affected | Cloud-delivered Firewall, cdFMC, Secure Access and Secure FMC software. |
| Fix | Upgrade to a fixed release (table below). |
| Workaround | None. Cisco lists a mitigation (below). |
| Exploitation | Cisco says its PSIRT became aware of active exploitation in October 2026. CISA added it to the KEV catalog on October 29, 2026, with a due date of November 1 for federal agencies. |
Are you affected
All three of these need to be true:
- The firewall runs Cisco Secure Firewall ASA or Secure FTD software on a vulnerable release.
- SSL remote access VPN is enabled on at least one interface and its login service can be reached. On ASA, that shows as the
webvpnkeyword withenablefor an interface in the running configuration. On FTD, look under Devices > VPN > Remote Access in Cisco Secure Firewall Management Center, or under Remote Access VPN in Cisco Secure Firewall Device Manager. - A tunnel group uses secondary authentication, meaning
secondary-authentication-server-groupis set.
Cisco says the check is not limited to the profiles that appear in the group list on the login page. If tunnel-group-list enable is configured, check every tunnel group, including the default one, DefaultWEBVPNGroup. If it is absent or has been removed, still check DefaultWEBVPNGroup, because turning off the group list does not remove the exposure when that default group uses secondary authentication.
Cisco also notes that a successful VPN login is not needed to reach the affected code path.
Fixed releases
Cisco lists the first fixed release for each branch:
| Product | Release branch | First fixed release |
|---|---|---|
| ASA | 9.16 and earlier | 9.16.4.104 |
| ASA | 9.18 | 9.18.4.96 |
| ASA | 9.20 | 9.20.4.50 |
| ASA | 9.22 | 9.22.3.200 |
| ASA | 9.23 | 9.23.1.48 |
| ASA | 9.24 | 9.24.1.27 or 9.24.10.1 |
| FTD | 7.0 and earlier | 7.0.11 |
| FTD | 7.2 | 7.2.13 |
| FTD | 7.4 | 7.4.9 |
| FTD | 7.6 | 7.6.7 |
| FTD | 7.7 | 7.7.14 |
| FTD | 10.0 | 10.0.3 |
| FTD | 10.1 | 10.1.1 |
Cisco provides a Software Checker tool that tells you which advisories affect a given release and the earliest release that fixes them. Use it to pick a target version rather than choosing from the table alone.
The mitigation, and its cost
Cisco says no workaround fully addresses the flaw, but it does describe a mitigation that it tested in a lab:
- If
DefaultWEBVPNGroupdoes not use secondary authentication, disable the tunnel group list withno tunnel-group-list enable. Users then cannot pick a connection profile from a list and must know the right profile name. - If
DefaultWEBVPNGroupdoes use secondary authentication, remove it withno secondary-authentication-server-group. Cisco states that this lowers the security of remote access VPN.
Cisco asks customers to check the effect on their own environment before applying either change, and treats both as temporary until the upgrade is done. Removing a second authentication step trades one risk for another, so we would only do it as a short bridge to a planned upgrade.
What to do
1. Find out what you run. Ask your IT provider: “Do we have a Cisco ASA or Secure Firewall (FTD) firewall, which release is it on, and is SSL remote access VPN turned on?” If the firewall is managed by someone else, ask for the version in writing.
2. Check for secondary authentication. Have someone review every tunnel group, including DefaultWEBVPNGroup, for secondary-authentication-server-group.
3. Upgrade to a fixed release. Plan a maintenance window. A firewall upgrade means a reload, and a single firewall means a short outage, so schedule it instead of waiting for an attacker to cause one.
4. Use the mitigation only as a bridge. If the upgrade has to wait, apply Cisco’s mitigation after checking what it changes for your VPN users, and write down that you did, so it gets reversed afterward.
5. Watch for unexplained reloads. Our advice: check the firewall’s uptime and logs for reloads you did not schedule. Repeated restarts around VPN logins point to this flaw. Cisco’s advisory does not describe a way to confirm exploitation from logs, so treat this as a sign to look closer, not as proof either way.
6. Reduce what the internet can reach. Our advice: if staff only use the VPN to reach a few internal applications, moving them to identity-based access takes the VPN login off the internet and removes this kind of exposure.
How we help
Checking firewall releases, planning upgrades, and cleaning up VPN configuration is part of our firewall and routing service, and remote monitoring and patching tracks which version each device runs, so an advisory like this one becomes a short list instead of a search. Unscheduled reloads and odd VPN activity are the kind of signal our managed SOC reviews.
If the real goal is letting staff reach a few internal systems, zero trust access replaces the exposed VPN login with access tied to identity and device.
For municipalities and law firms with one office firewall, a reload during the day stops remote work and access to shared files. If you are not sure which firewall you run, or whether its VPN is exposed, ask us and we will help you find out.
We covered another exploited firewall flaw earlier this month in FortiOS CVE-2025-61624: Admin Bug Leads to Root.
