News report

Cisco SSL VPN flaw can reload vulnerable ASA and FTD firewalls

Cisco says CVE-2026-76418 can make a vulnerable ASA or FTD remote-access firewall reload under specific secondary-authentication settings. Scope, fixed releases and evidence limits are separated below.

A VPN tunnel connects a device to a VPN server; the website connection continues beyond the server.
The VPN tunnel ends at the VPN server. HTTPS separately encrypts the website connection.

### The confirmed impact

Cisco published its advisory for CVE-2026-76418 on 28 October 2026. It rates the flaw High, with CVSS 3.1 score 8.6. The issue is in the Remote Access SSL VPN service of Cisco Secure Firewall Adaptive Security Appliance (ASA) Software and Secure Firewall Threat Defense (FTD) Software. Cisco attributes it to logic errors when secondary authentication is configured for a tunnel group.[1]

An unauthenticated remote attacker can send a crafted request while connecting to the SSL remote-access VPN. Successful exploitation may cause the affected firewall to reload unexpectedly, interrupting VPN service. This is a denial-of-service (DoS) vulnerability. Cisco does not describe code execution, credential theft, or data theft; the CVSS vector records no confidentiality or integrity impact.[1]

Cisco says its Product Security Incident Response Team learned of active exploitation in October 2026. The advisory gives no incident count, actor, victim list, campaign scale, or evidence of data theft. Treat the exploitation notice as a reason to prioritize checks and patching, not proof that every reachable firewall was attacked.[1]

### Check the configuration

Exposure requires an affected ASA or FTD release, a reachable SSL remote-access VPN service, and secondary authentication configured in the relevant tunnel-group scope. Cisco points administrators to the enabled WebVPN interface and secondary-authentication-server-group setting. A successful VPN login is not required for an attacker to reach the affected processing path.[1]

Review all tunnel groups, not just profiles shown on the login page. When tunnel-group-list is enabled, inspect every group, including DefaultWEBVPNGroup. When it is disabled, inspect that default group anyway: disabling the list does not remove exposure if the default group still uses secondary authentication. Cisco says Cloud-delivered Firewall, Cloud-delivered Firewall Management Center, Secure Access, and Secure FMC Software are not affected.[1]

### Mitigation and upgrade

Cisco says there is no workaround that fully fixes the vulnerability. Its temporary mitigations remove secondary authentication from affected tunnel groups. If DefaultWEBVPNGroup does not use it, disabling the tunnel-group list is an option; users will need to know the correct connection profile rather than select it from a list. If the default group does use it, Cisco describes removing its secondary-authentication-server-group setting. Removing a second factor lowers the security posture and can affect service, so assess the local authentication design, test changes in your environment, and treat them only as temporary risk reduction.[1]

The primary remediation is to upgrade to a fixed release. Select a supported target for the exact platform and branch with Cisco Software Checker and compatibility guidance; do not choose solely by the largest version number.[1]

A Korean Internet & Security Agency alert dated 30 October lists the same first-fixed releases. Cisco remains the primary source for exploitability and configuration details.[2]

BranchFirst fixed release
ASA 9.16 and earlier / 9.18 / 9.20 / 9.22 / 9.23 / 9.249.16.4.104 / 9.18.4.96 / 9.20.4.50 / 9.22.3.200 / 9.23.1.48 / 9.24.1.27 or 9.24.10.1
FTD 7.0 and earlier / 7.2 / 7.4 / 7.6 / 7.7 / 10.0 / 10.17.0.11 / 7.2.13 / 7.4.9 / 7.6.7 / 7.7.14 / 10.0.3 / 10.1.1

### Evidence boundary

The confirmed scope, versions, impact, exploitation statement, and mitigations below come from Cisco’s advisory. It does not identify attackers, victims, locations, incident numbers, or data loss. This concerns enterprise network gateways; it does not show that VPN encryption was broken or that consumer VPN apps are vulnerable. Check the deployed release and configuration before labelling a device affected or safe.[1]