Cisco says attackers are exploiting an ASA and FTD flaw to crash firewalls. Updates are available, with disabling secondary authentication as a temporary mitigation.
Attackers are exploiting a Cisco Secure Firewall flaw that can remotely force vulnerable devices to reload, interrupting service. The issue affects the SSL VPN service in Adaptive Security Appliance (ASA) and Threat Defense (FTD); Cisco rates it 8.6 in severity. The immediate consequence is a denial of service: a device that reloads can’t continue handling traffic normally while it’s unavailable. That makes this an operational problem for organizations that rely on affected firewalls to provide remote access.
The severity rating signals a serious vulnerability, but it doesn’t by itself tell administrators whether a particular device is exposed. Cisco’s configuration conditions matter. A firewall must be running the relevant SSL VPN service, and the vulnerable secondary authentication setup must be present in a tunnel group. In practice, that means checking the configuration rather than assuming that every ASA or FTD system is affected—or that a system is safe simply because it’s running a particular product family.
How the flaw can interrupt service
Tracked as CVE-2026-76418, the vulnerability stems from logic errors involving secondary authentication on a tunnel group. An unauthenticated attacker can send a crafted request while connecting to the SSL remote access VPN, triggering a device reload and denial of service, according to Cisco’s advisory.
The unauthenticated aspect changes the practical risk assessment: the attacker doesn’t first need valid VPN credentials, according to Cisco’s description. The failure is tied to how the service handles a particular authentication configuration, rather than to a user successfully signing in. This is more significant than it looks. For exposed systems, the relevant question is whether the vulnerable service and configuration are in place, not whether an attacker already has an account.
A forced reload is a denial-of-service mechanism, not evidence that the attacker has gained control of the firewall or accessed data. The source describes service interruption. Administrators should keep that distinction clear when assessing the incident: the documented effect is disruptive, and response planning should focus on exposure, availability, and getting to a fixed release.
Check tunnel group configuration
Exposure depends on the running configuration. Cisco says systems are vulnerable when webvpn appears in the configuration and SSL VPN is enabled on at least one interface. Administrators should check for secondary-authentication-server-group in tunnel groups, including the default DefaultWEBVPNGroup.
These checks are connected. Finding webvpn alone doesn’t establish that a system meets every condition Cisco identifies, and a quick review of one named tunnel group may miss another applicable group. The useful result is a configuration review that answers both questions: is SSL VPN enabled as described, and does a relevant tunnel group use secondary authentication?
When tunnel-group-list enable is configured, check every tunnel group. If the setting is absent or has been removed with no tunnel-group-list enable, Cisco says to inspect the default group: disabling the group list doesn’t remove exposure if that group still uses secondary authentication.
That detail makes the default group an important part of the review. A setting that changes which groups are listed shouldn’t be treated as proof that the underlying authentication configuration has disappeared. If you’re working in this space, verify what’s actually present in the running configuration and document which groups were checked; that gives the update team a clear basis for prioritizing affected devices.
Install a fixed release
Cisco says there are no workarounds. ASA fixes are available in versions 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27, and 9.24.10.1. For Secure FTD, patched versions are 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, and 10.1.1.
The release list spans multiple product versions, so teams need to match each device to the correct product and software branch. A version number from the ASA list won’t answer the question for an FTD system, and the presence of a newer-looking number alone isn’t enough to establish that a device has the relevant fix. Check the applicable branch and confirm the installed release against Cisco’s guidance.
The Cisco Software Checker can identify affected software and the earliest release that fixes each advisory. Cisco urges customers to update promptly.
That recommendation carries particular weight because attackers are already exploiting the issue. The practical task is to identify systems that meet the exposure conditions, select the fixed release for each, and schedule the update with service availability in mind. Cisco’s listed fixes give administrators a concrete destination; the remaining work is matching that destination to their own deployments.
Temporary mitigation and operational tradeoffs
Until they can install a fix, customers can disable secondary authentication on configured tunnel group lists or on DefaultWEBVPNGroup. Cisco tested this measure successfully, but advises administrators to assess it in their own environments because it may affect network functionality, performance, or security. The active exploitation makes checking exposed configurations and planning an update the immediate priority.
Disabling secondary authentication changes how the affected VPN configuration works, so it shouldn’t be treated as a cost-free switch. Cisco’s warning leaves the impact to be assessed in each environment: the same change may have different consequences depending on how a network uses that authentication setup. Here’s the thing: a temporary mitigation can reduce exposure while an update is pending, but administrators still need to understand what access behavior they’re changing.
Until the update is installed. That’s the gap teams need to manage: identify exposure, weigh the temporary configuration change, and keep the fix on the near-term schedule. The source provides no broader claim about attacker objectives or effects beyond device reloads and service interruption, so incident teams should anchor their response in the behavior Cisco has described.
Discussion
Sign in to join the discussion.