How to Audit Cisco ASA and FTD Exposure to CVE-2026-76418

To audit Cisco ASA and FTD exposure to CVE-2026-76418, confirm three conditions on every device: it runs a release Cisco lists as vulnerable, its SSL remote access VPN login service is reachable, and secondary authentication is configured on a tunnel group in the scope Cisco describes. A device is exposed only when all three are true. Cisco says the flaw is being exploited, and CISA set a November 1, 2026 due date.

Our news report on CVE-2026-76418 covers what happened. This guide is the device-by-device audit. When you know which devices are exposed, the companion guide on planning the ASA or FTD upgrade covers the fix, and what an unchecked return value and NULL pointer dereference mean explains the bug class.

What makes a device exposed to CVE-2026-76418?

A device is exposed when it runs a vulnerable ASA or FTD release, its SSL remote access VPN login service is reachable, and secondary authentication is configured on a relevant tunnel group. If any one of the three is false, Cisco's advisory does not treat the device as vulnerable.

The impact is a device reload, which is a denial of service for everything that passes through the firewall. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, so confidentiality and integrity are rated None. Cisco also says a successful VPN login is not required to reach the affected code path, so valid credentials are not a prerequisite for an attacker.

Step 1: list every ASA and FTD device

Build the list from your management platforms and asset records, not from memory. Include:

• Standalone ASA appliances and ASA virtual (ASAv) instances.
• FTD devices managed by Secure Firewall Management Center (FMC) or by Secure Firewall Device Manager (FDM).
• Both units of every failover pair and every cluster member.
• Lab and disaster recovery units that still carry production-like VPN configuration.

Cisco lists these products as not vulnerable: Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) and Secure FMC Software. Note the last item carefully. The FMC software itself is not affected, but the FTD devices it manages can be.

Step 2: check the running release

Record the exact running release of each device and compare it with Cisco's fixed-release tables. A device on a release earlier than the first fixed release for its train is vulnerable.

• 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

Two gaps need attention. The CVE record lists ASA 9.19 and FTD 7.3 builds as affected, but the advisory's tables have no row for either train. If you run one of them, mark the device as vulnerable and use the Cisco Software Checker to find a fixed release on a supported train. Do not assume a fix exists on those trains.

Step 3: confirm the SSL VPN login service is reachable

On ASA, Cisco's advisory defines the vulnerable configuration as a running configuration that contains the webvpn keyword with SSL VPN enabled on at least one interface, shown as enable followed by the interface name inside the webvpn section. Review the running configuration on each device for that pattern and note which interfaces have it.

On FTD, remote access VPN is enabled from Devices, then VPN, then Remote Access in FMC, or from Remote Access VPN in FDM. Check both the policy and what was actually deployed.

"Reachable" is about who can get to the login service, not only internet exposure. Record each interface the service is enabled on and which networks can reach it. An internal interface still counts if untrusted users can reach it.

Step 4: check tunnel groups for secondary authentication

This is the step most likely to be done wrong. Cisco gives two cases:

• If tunnel-group-list enable is configured, check every tunnel group, including the default DefaultWEBVPNGroup, for secondary-authentication-server-group. Cisco notes the check is not limited to profiles displayed in the group list on the login page.
• If tunnel-group-list enable is absent, or was removed with no tunnel-group-list enable, still check DefaultWEBVPNGroup for secondary-authentication-server-group.

On FTD, Cisco asks you to review the deployed remote access VPN policy and the resulting device running configuration in FMC or FDM, not only the policy as designed.

Does disabling the tunnel group list remove exposure?

Not by itself. Cisco says disabling the group list does not remove exposure when the DefaultWEBVPNGroup tunnel group uses secondary authentication.

That is why Cisco's mitigation has two cases. Disabling the group list only helps when the default group does not use secondary authentication. When it does, the mitigation is removing secondary authentication, which Cisco says lowers the security posture of remote access VPN. Cisco calls mitigations temporary until a fixed release is installed, and says there are no workarounds.

How do you record the audit result for each device?

Give each device one of three verdicts, exposed, not exposed or unknown, and write down the evidence for each of the three conditions. A device stays unknown until all three are checked.

A minimal record per device:

• Hostname, platform, management method (FMC, FDM or CLI) and failover or cluster role.
• Running release and whether it is below the first fixed release for its train.
• Interfaces with SSL VPN enabled and which networks can reach them.
• Tunnel groups with secondary authentication, including whether DefaultWEBVPNGroup is one of them, and whether the group list is enabled.
• Verdict, date checked, who checked, and the planned action with a date.

Both units of a failover pair should get their own row. They should match, but an audit is where you find out whether they do.

After the audit

Prioritise exposed devices for an upgrade to a fixed release, and only consider Cisco's mitigation where you cannot upgrade in time, recorded as a change with an expiry date. The upgrade planning guide covers the window, failover order and rollback.

Neither Cisco nor CISA names an actor, victims or a campaign; Cisco says only that its PSIRT became aware of active exploitation in October 2026, and CISA lists ransomware use as unknown. The only impact either source describes is a reload, so watch exposed devices for unexpected reloads until they are upgraded. While you are reviewing the configuration, confirm that management access is limited, as covered in how to restrict firewall management access.

Sources

• Cisco Security Advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75
• CISA Known Exploited Vulnerabilities catalog
• CVE-2026-76418 record on CVE.org
• Cisco Software Checker