Cisco published advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 at 19:15 GMT on October 28, 2026. The same document confirms that Cisco’s Product Security Incident Response Team (PSIRT) had already seen exploitation during October. The bug, CVE-2026-76418, sits in the Remote Access SSL VPN service of Cisco Secure Firewall ASA Software and Secure Firewall Threat Defense (FTD) Software. It has Cisco bug ID CSCwx26625, a CWE-690 classification and a CVSS 3.1 base score of 8.6. An unauthenticated remote attacker sends a crafted request while connecting to the SSL remote-access VPN, and the device reloads. Reaching the flaw takes no credentials, no user interaction and no code execution, and Cisco lists no workaround that addresses it.
What Cisco’s advisory actually says
Early coverage treated this as another generic Cisco firewall DoS bug, and that framing hides the detail that matters. Cisco attributes the defect to logic errors that occur when secondary authentication is configured on a tunnel group. The advisory states that a successful VPN login is not required to reach the affected code path, so the fault sits in the pre-authentication request handling of a service that is reachable from untrusted networks by design.
According to the advisory’s Source section, Eric Fernald found the vulnerability while resolving a Cisco Technical Assistance Center support case. That ordinary origin explains why no exploit code or indicator-of-compromise (IOC) list accompanies the disclosure. SOC Prime’s October 29 analysis confirms that neither Cisco nor third-party reporting had published a working proof of concept or campaign-specific IOCs, such as attacker addresses, domains or payload hashes, at the time of writing. Defenders are left with behavioral and configuration-based hunting, and the rest of this article follows from that.
Am I affected? The three exposure conditions
Cisco says a device is exposed only when all three of these are true:
- It runs a vulnerable ASA or FTD release.
- The SSL remote-access VPN login service is reachable.
- Secondary authentication is configured within the tunnel-group scope the advisory describes.
Remove any one and the exposure goes away, so the configuration audit matters as much as the patch schedule.
How to check your ASA and FTD configuration
Cisco gives administrators two configuration tests. The first shows whether the SSL VPN listener exists. If the running configuration contains the webvpn keyword and SSL VPN is enabled on at least one interface, the configuration is in scope. The advisory writes this as webvpn followed by enable <interface_name>. Cisco’s ASA forensic guide adds a caution that trips people up: webvpn alone does not mean SSL VPN is enabled, because an enable <interface_name> statement has to accompany it. Plenty of estates carry a leftover webvpn block from a decommissioned pilot while the real listener lives on another appliance.
The second test is the tunnel-group check, and the real risk sits here. If tunnel-group-list enable is configured, check every tunnel group, including the default DefaultWEBVPNGroup, for secondary-authentication-server-group. Cisco warns that the check covers more than the profiles shown in the login page’s group list. If tunnel-group-list enable is absent, or was removed with no tunnel-group-list enable, you still have to inspect the default group, because hiding the list does not remove exposure when DefaultWEBVPNGroup itself uses secondary authentication.
Organizations that “fixed” this by hiding the profile dropdown will get caught by that last point. A typical exposed ASA configuration looks like this:
! Listener on the outside interface, profile list published to userswebvpn enable outside tunnel-group-list enable anyconnect enable!tunnel-group ENG-RAVPN type remote-accesstunnel-group ENG-RAVPN general-attributes authentication-server-group RADIUS_PRIMARY secondary-authentication-server-group LDAP_SECONDARY default-group-policy ENG-GroupPolicy!! Often forgotten, never shown in the dropdown, still reachabletunnel-group DefaultWEBVPNGroup general-attributes authentication-server-group LOCAL secondary-authentication-server-group RADIUS_SECONDARY
On FTD the same constructs exist, but the manager is the source of truth. Cisco’s footnote points administrators to Devices > VPN > Remote Access in Secure Firewall Management Center, or Remote Access VPN in Secure Firewall Device Manager, and advises reviewing both the deployed remote-access policy and the resulting device running configuration. The FTD CLI answers show running-config webvpn and show running-config tunnel-group, which is usually faster than clicking through FMC for a fleet-wide check.
Root cause: double authentication and CWE-690
Secondary authentication is Cisco’s name for double authentication. Per the ASA command reference, the command is entered in tunnel-group general-attributes configuration mode with this syntax: secondary-authentication-server-group [interface_name] {none | LOCAL | groupname [LOCAL]} [use-primary-username]. Its default is none, it only matters when double authentication is enabled, and the secondary server group cannot be an SDI server group. It arrived in 8.2(1), so this is old, load-bearing code.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →The feature prompts the user for an additional credential, such as a second username and password, on the login screen. The ASA VPN configuration guide says the secondary server group applies only to AnyConnect VPN connections, and it describes companion commands that each add a branch to the workflow:
tunnel-group ENG-RAVPN general-attributes authentication-server-group RADIUS_PRIMARY secondary-authentication-server-group LDAP_SECONDARY authenticated-session-username secondary authentication-attr-from-server secondary secondary-username-from-certificate ou secondary-pre-fill-username-from-certificate client hide
use-primary-username collapses the login dialog to a single username field. secondary-username-from-certificate pulls the second identity from a DN field on a client certificate. authentication-attr-from-server decides whether authorization attributes come from the primary or the secondary server. authenticated-session-username picks which of the two authenticated identities becomes the session username used for accounting, the session database, syslogs and debug output. That makes two identities, two server groups, two possible attribute sources and one session record that has to reconcile them. It is a lot of conditional state for a service that makes these decisions on requests from strangers.
Cisco has not published the internal call trace, and nobody outside the company should pretend to have it. The classification still tells us something. CWE-690 is “unchecked return value to null pointer dereference”: a function that can fail returns a null pointer, the caller does not test it, and the code dereferences it anyway.
Why a null pointer dereference reboots the firewall
The classic shape of the bug is short. The C below follows the CWE-690 pattern. It is illustrative, not Cisco source code and not a reproduction of CVE-2026-76418:
struct vpn_profile { int secondary_auth_enabled; const char *auth_server_group;};struct vpn_profile *find_vpn_profile(const char *name);int process_secondary_auth(const char *profile_name){ struct vpn_profile *profile = find_vpn_profile(profile_name); /* Unsafe: profile may be NULL when the lookup fails. */ if (profile->secondary_auth_enabled) return start_secondary_auth(profile->auth_server_group); return 0;}
The safe version tests every pointer before use and treats failure as an ordinary outcome:
int process_secondary_auth(const char *profile_name){ struct vpn_profile *profile = find_vpn_profile(profile_name); if (profile == NULL) return ERROR_PROFILE_NOT_FOUND; if (!profile->secondary_auth_enabled) return 0; if (profile->auth_server_group == NULL) return ERROR_INVALID_AUTH_CONFIGURATION; return start_secondary_auth(profile->auth_server_group);}
Returning NULL from a lookup is fine. Dereferencing it is the defect. The gap between the two is a missing precondition check, and in a login service that gap is reachable from the network before any identity exists.
Why does a memory fault there reload the whole device? Because of how ASA and FTD are built. Cisco documents FTD as a unified operating system with two engines, the ASA-derived LINA and Snort, and the CLI exposes LINA as a process (Cisco, “Clarifying the Firepower Threat Defense LINA process”). LINA carries the firewall and VPN functions. Cisco’s root-cause-analysis guide for Secure Firewall says ASA or FTD software can traceback and usually reload because of software defects, hardware exceptions and resource exhaustion. The artifacts it documents are named after that process: crashinfo_lina.14664.20250813.205102 on disk0:, and core files such as core.lina.11.10335.1754311379.gz. When the process that owns the datapath and the VPN service faults, the appliance restarts. Those filenames are also the best forensic artifact this vulnerability leaves, because they show which process died and when.
CVSS 8.6 explained: an availability event with scope change
For reporting and board briefings, keep in mind that a reload is an availability event. The advisory establishes no confidentiality or integrity impact, and Cisco has not described remote code execution, data extraction or authentication bypass through this defect. The scored vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, with the temporal and environmental metrics left as E:X/RL:X/RC:X.
The scope change (S:C) is what lifts the score to 8.6 for a DoS-only outcome. The vulnerable component is the VPN service, but the systems that depend on the appliance behind it are affected too. AV:N means no physical or local access is needed, AC:L means no exotic preconditions beyond the documented configuration, PR:N means no privileges and UI:N means nobody has to click anything. Put together, an internet-reachable firewall that terminates your remote access can be restarted on demand by an anonymous peer, repeatedly, for as long as it stays unpatched.
Fixed releases for Cisco ASA and FTD
Cisco lists the first fixed release for each train, and PSIRT validates only the affected and fixed release information in the advisory. For ASA software, the targets are 9.16.4.104 for 9.16 and earlier, 9.18.4.96 for 9.18, 9.20.4.50 for 9.20, 9.22.3.200 for 9.22, 9.23.1.48 for 9.23, and 9.24.1.27 or 9.24.10.1 for 9.24 depending on the build in use. For FTD, they are 7.0.11 for 7.0 and earlier, 7.2.13 for 7.2, 7.4.9 for 7.4, 7.6.7 for 7.6, 7.7.14 for 7.7, 10.0.3 for 10.0 and 10.1.1 for 10.1.
The August patch trap
These numbers sit very close to the August fixes. Cisco’s August 11 advisory for CVE-2026-20349 lists ASA 9.16.4.103, 9.18.4.94, 9.20.4.49, 9.22.3.26, 9.23.1.47 and 9.24.1.26, with FTD 7.0.10, 7.2.12, 7.4.8, 7.6.6, 7.7.13, 10.0.2 and 10.1.0. A firewall on ASA 9.20.4.49 is patched against the August bug and still fully exposed to this one. In several trains a single build number separates the two. Anyone who ran a Cisco firewall patch cycle in September and marked the estate clean should reopen that ticket.
Version string formats
Version strings add a smaller trap. ASA prints releases as 9.16(4)85 in show version, the advisory writes 9.16.4.85, and image filenames use asa9-16-4-85-lfbff-k8.SPA. Any automated comparison has to normalize all three formats or it will produce confident nonsense.
Other advisories and products not affected
The Canadian Centre for Cyber Security echoed the disclosure in alert AV26-1102, listing the same thresholds and stating that Cisco indicates CVE-2026-76418 is exploited in the wild. Its alert gives the 9.23 fixed release as 9.23.1.4 instead of 9.23.1.48. National advisories aggregate and sometimes truncate, so the vendor document governs when the two disagree. Cisco’s advisory also points administrators to the Software Checker tool and the Recommended Releases documents for ASA compatibility, the ASA upgrade guide and the Threat Defense Compatibility Guide, because the first fixed release for a CVE is a floor and not a considered software choice for a production fleet.
Cisco confirms these products are not vulnerable: Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) and Secure FMC Software. The list applies to this advisory only, so do not extend it to other Cisco products by analogy.
Mitigation and workarounds for CVE-2026-76418
Cisco states that no workarounds address the vulnerability, then documents a mitigation with two cases.
If DefaultWEBVPNGroup does not use secondary authentication, disable the tunnel-group list by entering no tunnel-group-list enable in WebVPN configuration mode. Users lose the dropdown and must know their connection profile name. That adds helpdesk load but does not weaken security.
If DefaultWEBVPNGroup does use secondary authentication, the documented step is no secondary-authentication-server-group in the tunnel-group general-attributes context. Cisco says plainly that this lowers the security posture of remote-access VPN. It also says the mitigation was deployed and proven successful in a test environment, and it tells customers to confirm applicability and effectiveness in their own environment before touching production.
Turning off a second factor to buy time until a maintenance window is a trade, and you should record it as one. Take a configuration backup and open a change record before running the command, so the control gets restored on schedule instead of whenever someone remembers. Where you can, upgrade instead. On a high-availability pair, a rehearsed failover usually costs less business disruption than removing an authentication control that the identity team spent a year wiring into conditional-access policy.
Restricting which source networks can reach the VPN listener is sensible hygiene and shrinks the pool of attackers who can send the crafted request. Cisco does not document it as a workaround for this defect, so do not log it as remediation.
How to audit your Cisco firewall estate for this vulnerability
Manual review works for three firewalls and breaks down at thirty. These commands answer both of Cisco’s tests and collect the crash artifact checks in the same pass:
terminal pager 0show version ! release string and uptimeshow running-config webvpn ! enable <intf>, tunnel-group-list, anyconnectshow running-config tunnel-group ! every group, including DefaultWEBVPNGroupshow vpn-sessiondb anyconnect ! who is connected right nowshow crashinfo files ! last five crash information filesdir disk0: | include crashinfo|core\. ! artifact names and timestampsshow reload ! any scheduled reload pending
On FTD, the same crashinfo files show up in the LINA CLI dir output and, in expert mode, under /mnt/disk0/, with cores under /ngfw/var/data/cores/ and /ngfw/var/common/. Inside an FTD troubleshoot archive they land in dir-archives/var-log/mnt-disk0/, which is the path to grep when you work from a bundle instead of the live device.
The script below reads a CSV inventory, normalizes the ASA build-string format, evaluates all three exposure conditions and compares the installed release with the first-fixed map from the advisory. It runs read-only commands only. Test it on a lab device first, because CLI behavior varies by release and by whether the appliance is managed. Keep credentials in a vault and out of the CSV for anything that outlives the assessment.
#!/usr/bin/env python3"""Estate audit for CVE-2026-76418.Tests the three exposure conditions in Cisco advisorycisco-sa-asaftd-tunnel-dos-s6mgkb75: vulnerable release, reachable SSLremote-access VPN listener, secondary authentication on a tunnel group.inventory.csv columns: host,platform(asa|ftd),username,secretRequires: netmiko"""import csvimport refrom netmiko import ConnectHandlerASA_FIXED = {"9.16": (9, 16, 4, 104), "9.18": (9, 18, 4, 96), "9.20": (9, 20, 4, 50), "9.22": (9, 22, 3, 200), "9.23": (9, 23, 1, 48), "9.24": (9, 24, 1, 27)}FTD_FIXED = {"7.0": (7, 0, 11), "7.2": (7, 2, 13), "7.4": (7, 4, 9), "7.6": (7, 6, 7), "7.7": (7, 7, 14), "10.0": (10, 0, 3), "10.1": (10, 1, 1)}def parse_version(text, platform): """Return a comparable tuple. ASA prints 9.20(4)49; FTD prints 7.4.8.""" m = re.search(r"Version\s+([0-9.()]+)", text) if not m: return None raw = m.group(1) if platform == "asa": paren = re.match(r"(\d+)\.(\d+)\((\d+)\)(\d+)", raw) if paren: return tuple(int(x) for x in paren.groups()) dotted = re.match(r"(\d+)\.(\d+)\.(\d+)\.(\d+)", raw) return tuple(int(x) for x in dotted.groups()) if dotted else None nums = tuple(int(x) for x in re.findall(r"\d+", raw)[:3]) return nums or Nonedef fixed_floor(version, platform): """First fixed release for the train, defaulting to the 'and earlier' row.""" table = ASA_FIXED if platform == "asa" else FTD_FIXED fallback = (9, 16, 4, 104) if platform == "asa" else (7, 0, 11) train = ".".join(str(x) for x in version[:2]) return table.get(train, fallback)def secondary_auth_groups(config): """Tunnel groups whose general-attributes set a real secondary AAA group.""" exposed, current = [], None for line in config.splitlines(): line = line.strip() m = re.match(r"tunnel-group\s+(\S+)\s+general-attributes", line) if m: current = m.group(1) continue if line.startswith("secondary-authentication-server-group"): parts = line.split() if len(parts) > 1 and parts[1].lower() != "none" and current: exposed.append(current) return exposeddef audit(row): device_type = "cisco_asa" if row["platform"] == "asa" else "cisco_ftd" conn = ConnectHandler(device_type=device_type, host=row["host"], username=row["username"], secret=row["secret"]) ver_txt = conn.send_command("show version | include Version") webvpn = conn.send_command("show running-config webvpn") groups = conn.send_command("show running-config tunnel-group") conn.disconnect() version = parse_version(ver_txt, row["platform"]) listener = bool(re.search(r"^\s*enable\s+\S+", webvpn, re.M)) group_list = "tunnel-group-list enable" in webvpn exposed_groups = secondary_auth_groups(groups) default_exposed = "DefaultWEBVPNGroup" in exposed_groups if version is None: return row["host"], "unknown", "version could not be parsed", [] patched = version >= fixed_floor(version, row["platform"]) # Cisco: with the group list off, DefaultWEBVPNGroup still creates exposure. at_risk = (not patched) and listener and (default_exposed or group_list) return (row["host"], ".".join(str(x) for x in version), "AT RISK" if at_risk else ("patched" if patched else "not exposed"), exposed_groups)with open("inventory.csv", newline="") as fh: for row in csv.DictReader(fh): host, ver, state, groups = audit(row) print(f"{host},{ver},{state},{'|'.join(groups) or '-'}")
The at_risk logic encodes what the advisory says instead of the popular summary of it. A device with the tunnel-group list disabled is still exposed if DefaultWEBVPNGroup carries secondary-authentication-server-group. A device with the list enabled is exposed through any group that carries it, whether or not that group appears in the login page dropdown.
Detecting exploitation and preserving evidence after a firewall reload
Detection is awkward here. The trigger is a pre-authentication request, so it does not necessarily produce a failed-password event, a rejected second-factor challenge or an authentication syslog entry. The payload travels inside TLS to the VPN listener, so network sensors that do not decrypt see connection metadata and nothing else. Cisco published no IOCs. The loudest signal available is the reload itself.
The reload also destroys evidence. Cisco’s ASA forensic procedures warn that rebooting a device under triage irrecoverably loses volatile information such as RAM contents, ARP and routing tables, NAT translations and ACL hit and drop counts. With this vulnerability the reboot has already happened, so what survives is whatever landed on flash and whatever your upstream devices kept.
Start on the appliance
show crashinfo displays the latest crash information file, show crashinfo files lists the last five by date and timestamp, and dir reveals whether a crashinfo_lina.<pid>.<timestamp> file exists at all. If a core was written, its filename carries an epoch value that any Linux host can convert, for example date -d @1753342057. Compare that timestamp with the VPN interruption. For traceback root-cause analysis, Cisco asks for raw, unparsed LINA engine syslog covering at least thirty minutes before the event, FMC health monitoring screenshots for the same window, SNMP CPU and memory data and NetFlow records. For high-availability pairs or clusters it asks for all of that from every affected unit. Do not rename core, crashinfo or minidump files, because TAC tooling expects the original names.
Collecting evidence for Cisco TAC
If you plan to hand this to Cisco, the collection path is documented: show tech-support detail on ASA, optionally redirected with show tech-support detail | redirect disk0:/tech-support.txt, plus dir /recursive all-filesystems, image hash verification with verify /sha-512 disk0:/<image>.SPA, and show software authenticity running on Secure Boot platforms. Coredumps are off by default on virtual ASA (show coredump reports no coredump filesystem). Enabling them with coredump enable filesystem disk0: allocates real flash and delays the reload after a software-forced crash, so make that decision during hardening and not during an incident. Never run crashinfo force on a production device. The command reference cautions that it crashes the appliance and forces a reload.
Use upstream telemetry
Upstream telemetry does the work the appliance cannot. Load balancers in front of the VPN listener, edge routers, DDoS mitigation and IDS or IPS platforms keep connection records that survive the reload.
