Cisco says attackers are actively exploiting CVE-2026-76418, a flaw that lets an unauthenticated remote attacker reload Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD) devices that run the SSL remote access VPN with secondary authentication. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog on October 29, 2026. The impact is denial of service, not takeover. If you run an ASA or FTD VPN with a second authentication server group on a tunnel group, check your config and move to the first fixed release.
A firewall reload is not an AI story. It becomes one for teams where developer laptops, CI runners and coding agents reach internal Git, package mirrors and model gateways only through that tunnel. This post sticks to what Cisco says, then covers what an exploited VPN outage does to agent workflows.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | ASA or FTD with SSL VPN enabled on an interface and secondary-authentication-server-group set in a tunnel group |
| Is it exploited? | Yes. Cisco PSIRT reports active exploitation in October 2026; CISA KEV entry added October 29 |
| What is the impact? | Unauthenticated reload of the device, repeated denial of service. No code execution reported |
| Is there a fix? | Yes. First fixed releases listed below |
| Is there a workaround? | Only a temporary mitigation: disable secondary authentication |
| Not affected | Cloud-delivered Firewall Management Center, Secure Access, Secure FMC Software |
| Does data leave my machine? | No. Patching is local to the firewall |
What the sources say
Cisco's advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 (version 1.0, published October 28, 2026) tracks the bug as CSCwx26625. It rates the flaw High, CVSS 3.1 base score 8.6, with vector AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H: network reachable, low complexity, no privileges, no user interaction, availability impact only. The cause is described as "logic errors when secondary authentication is configured on a tunnel group". An attacker sends a crafted request while connecting to the SSL remote access VPN, and the device reloads.
The weakness class is CWE-690, unchecked return value to NULL pointer dereference. Cisco credits Eric Fernald, who found it during a TAC support case, and says PSIRT became aware of active exploitation in October 2026. CISA's KEV entry lists the date added as 2026-10-29 and the due date as 2026-11-01, with known ransomware use not flagged. You can read the Beam record at and the same entry on NVD.
Neither Cisco nor CISA says who is exploiting it, how many devices were hit, or how long the attacks lasted. We have not tested the exploit and nothing public describes the exact crafted request. Treat the first week of exposure as the window to investigate, since the advisory and KEV listing arrived within a day.
The mechanism, in plain terms
An ASA or FTD SSL VPN can require two credential checks, for example a password against an LDAP server and a one-time code or certificate against a second server. That second check is the "secondary authentication" the advisory means, configured as secondary-authentication-server-group inside a tunnel group.
When that setting is present, a crafted connection request reaches code that does not safely handle a failed lookup, and the process dereferences a null pointer. The device crashes and reloads. Because the request is unauthenticated and the VPN login service must face the internet to be useful, anyone who can reach the portal can trigger it. Repeating the request keeps the device in a reload loop, which is what makes it a practical outage rather than a one-off crash.
Note the irony: the extra security setting is what makes the box vulnerable. That is why the temporary mitigation below is a trade-off, not a free fix.
Who is affected, and how to check
Cisco states two conditions. The device runs a vulnerable ASA or FTD release, and the SSL remote access VPN login service is reachable with secondary authentication in the tunnel group scope. Cisco's check, in the ASA CLI:
- Is the SSL VPN enabled? Look in the running config for
webvpnand anenable <interface_name>line on at least one interface. - Which tunnel groups use a second server group? If
tunnel-group-list enableis configured, check every tunnel group, includingDefaultWEBVPNGroup, forsecondary-authentication-server-group. If it is absent or was removed withno tunnel-group-list enable, still checkDefaultWEBVPNGroup. - On FTD, review the deployed remote access VPN policy and the resulting running config in FMC or FDM.
You can also search the running config directly with show running-config | include secondary-authentication-server-group; that is a standard ASA filter, but confirm it against Cisco's documentation for your release.
Fixed releases
Cisco lists the first fixed release for each train:
| Software | Train | First fixed |
|---|---|---|
| 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 and 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 points to its Software Checker and the ASA and FTD compatibility and upgrade guides for the right path. Do not skip a train: jump to the entry for the train you are on or a later one.
Temporary mitigation
Cisco says no workaround fully addresses the issue, but it offers a mitigation: disable secondary authentication on the tunnel group list or on DefaultWEBVPNGroup.
- Case 1,
DefaultWEBVPNGrouphas no secondary authentication: runno tunnel-group-list enablein WebVPN mode. Users must then know the exact connection profile name to connect. - Case 2,
DefaultWEBVPNGroupuses secondary authentication: runno secondary-authentication-server-group. This lowers the security posture of the remote access VPN.
Cisco is explicit that these are temporary and recommends upgrading. If you must remove the second factor, compensate: restrict the portal by source address where possible, tighten account lockout and alerting, and plan the upgrade within days, not weeks.
Timeline and what is still unknown
- October 2026: Cisco PSIRT becomes aware of active exploitation. The bug itself was found earlier by Eric Fernald while working a TAC support case.
- October 28: Cisco publishes advisory version 1.0 (final) with fixed releases for every supported train.
- October 29: CISA adds CVE-2026-76418 to KEV, with a federal due date of November 1, just three days later.
Several questions remain open and we will not guess at them. Cisco does not say how many devices were reloaded, whether exploitation was opportunistic scanning or targeted, or whether the reloads were paired with any other activity. The advisory lists no indicators of compromise, and it does not report a separate vulnerability that could be chained with this one. If that changes, we will add an update here.
How to tell if you were hit
A successful attack looks like an unexplained reload, so the evidence is in availability and logs rather than in files. Check these on any device that matched the config test above:
- Reload history. Review uptime and crash information on the device. Several unplanned reloads since the beginning of October, especially clustered, are a strong sign.
- Syslog and VPN logs. Look for a burst of SSL VPN connection attempts from one or a few external addresses just before each reload, including attempts that never complete a login.
- Monitoring gaps. Compare VPN session counts and user complaints with the reload times; sudden drops to zero are the pattern.
- Failover behaviour. On an HA pair, a flip to the standby unit can hide the problem. Check both units.
Because the request is unauthenticated, the source addresses will not map to your users. Block repeat offenders at the edge while you upgrade, and keep the logs; CISA's KEV instruction asks for forensic triage on affected assets.
What this means if you run AI coding agents
An availability bug sounds minor next to the Ivanti Connect Secure chain that gives root, but for agent workflows an outage has its own failure modes.
- Agents fail mid-task. A long Claude Code or Codex session that pulls from an internal repo, mirror or model gateway can stall or error halfway through a change. Partial work can then sit in a working tree, so review the diff and run tests before resuming.
- Pressure to bypass the tunnel. When the VPN is down, people paste tokens into personal accounts, open direct cloud access or use a public mirror. Decide in advance what the fallback is, and keep agents on scoped, short-lived credentials instead.
- Outage as cover. Denial of service is sometimes noise while something else happens. Do not assume nothing else changed: check VPN and authentication logs for the same window.
- Patch your gateway before your agents. Coding agents inherit the trust of the network they sit on. The same lesson appears in the GitLab CVE-2026-97229 exploitation, where a compromised piece of infrastructure put every stored token at risk.
Attackers have also been shortening the time from disclosure to use. Our write-up of OpenAI's pipeline of kernel privilege-escalation exploits covers why the patch window keeps narrowing.
What Beam can and cannot do here
Beam does not manage or monitor firewalls, and it cannot stop a crash of a Cisco device. It runs on the developer endpoint: it watches what Claude Code, Codex and similar agents do, flags risky actions such as credential exposure and destructive commands, and keeps data on-device. If a VPN outage pushes someone to improvise, for example pointing an agent at a different endpoint or pasting secrets into a command, those local actions are what Beam can surface. Its deny is hook-based, not a kernel sandbox, and its scans are heuristic. See what Beam watches and how it works.
Where this sits in November's attacks
Exploited gateway and CI/CD flaws keep appearing in the same few weeks. The common thread is internet-facing infrastructure that developer machines depend on. For wider context see our November 2026 attacks timeline.
Frequently asked questions
What is CVE-2026-76418?
It is a high-severity (CVSS 8.6) flaw in the Remote Access SSL VPN service of Cisco Secure Firewall ASA and Secure Firewall Threat Defense (FTD) software. Logic errors when secondary authentication is configured on a tunnel group let an unauthenticated remote attacker send a crafted request that makes the device reload, causing a denial of service.
Is CVE-2026-76418 exploited in the wild?
Yes. Cisco says its PSIRT became aware of active exploitation in October 2026, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on October 29, 2026, with a due date of November 1.
How do I know whether my device is exposed?
The SSL VPN must be enabled on an interface (webvpn with enable on that interface) and secondary-authentication-server-group must be set in a tunnel group. Check every group if tunnel-group-list enable is configured, and always check DefaultWEBVPNGroup. On FTD, review the deployed remote access VPN policy in FMC or FDM.
Is there a workaround?
Cisco says no workaround fully addresses it, but a temporary mitigation is to disable secondary authentication on the affected tunnel group or on DefaultWEBVPNGroup. Removing it lowers your VPN security posture, so treat it as a stopgap before upgrading.
Does this let attackers take over the firewall?
No. Cisco describes only a device reload and denial of service. The advisory does not report code execution or credential theft for this CVE, but repeated reloads still cut off every remote user.
Related reading
- Ivanti Connect Secure zero-day chain exploited
- GitLab CVE-2026-97229 exploited: what to rotate
- November 2026 attacks timeline
- Sources: Cisco advisory, CISA KEV catalog, NVD
Versions and dates are accurate as of November 5, 2026. Cisco may revise the advisory; check it before acting.