Cisco Fixes Exploited Firewall VPN Bug That Lets Unauthenticated Attackers Force Reboots

Cisco has released software updates for a high-severity flaw in its Secure Firewall Adaptive Security Appliance (ASA) and Secure Firewall Threat Defense (FTD) products. The flaw is tracked as CVE-2026-76418. A remote attacker who has no account on the device can use it to force a firewall to restart, which cuts off the network traffic the firewall protects. Cisco described the bug in an advisory published on a Wednesday. The company says attackers are already exploiting it, and that it learned of the attacks in October 2026.

What happened

The problem sits in the Remote Access SSL VPN service built into ASA and FTD software. A VPN, or virtual private network, lets remote staff connect securely to their organisation's internal network. "SSL VPN" means the connection is protected with the same kind of encryption that secures websites.

Here is the sequence of events, based on the available reporting:

• In October 2026, Cisco became aware that the vulnerability was being actively exploited.
• In a Wednesday advisory, Cisco disclosed the flaw and made fixed software releases available.
• Along with the patches, Cisco published conditions that admins can use to check whether a device is exposed, plus temporary workarounds for organisations that cannot update right away.
• The ITVedas CVE database, which draws on NVD and CISA records, lists the flaw as known exploited in CISA's Known Exploited Vulnerabilities (KEV) catalogue. KEV is the US government's list of bugs confirmed to be used in real attacks.

The disclosure came alongside a separate Cisco report on a more advanced campaign, covered below, that targeted a different product line.

Who is affected

Cisco says a device is vulnerable only when all three of these conditions are true:

• It runs a vulnerable release of Cisco Secure Firewall ASA Software or Cisco Secure FTD Software.
• The SSL remote access VPN login service can be reached by the attacker.
• Secondary authentication is configured at the tunnel group level.

A "tunnel group" is a set of rules and settings applied to a particular type of VPN connection. "Secondary authentication" adds a second login check on top of the first one, for example a second username and password checked against another server.

Cisco published a list of fixed software versions, but the specific version numbers were not included in the source material available to us. The ITVedas CVE database also lists affected versions as unknown. Administrators should take exact version numbers directly from Cisco's advisory.

The sources do not say which industries or regions were hit by the attacks on this specific flaw.

How it works

Cisco attributes the bug to "logic errors" in how the VPN service handles secondary authentication on a tunnel group. An attacker who sends a specially crafted request while connecting to the SSL VPN can cause the device to reload, meaning it reboots unexpectedly. While the device restarts, it stops passing traffic. This is called a denial-of-service (DoS) condition: the service becomes unavailable to legitimate users.

The CVE record classifies the weakness as CWE-690. This category describes code that fails to check whether an operation returned a valid result and then tries to use an empty (null) value. That kind of mistake typically makes software crash.

The most concerning detail is that an attacker does not need valid credentials. In Cisco's words, "A successful VPN login is not required to reach the affected processing path." In practice, anyone who can reach the VPN login page from the internet could trigger the crash.

Configuration also matters, and Cisco highlighted a subtle trap. Some ASA devices let users choose a tunnel group from a list at login, through a setting called tunnel-group-list enable:

• If this list is turned on, admins should check every tunnel group for a secondary authentication server group. That includes the built-in default group, named DefaultWEBVPNGroup.
• If the list is turned off, or was removed with the no tunnel-group-list enable command, admins must still check DefaultWEBVPNGroup. Cisco warns that turning off the list does not remove the exposure if the default group uses secondary authentication.

On FTD devices, Cisco advises reviewing both the deployed remote access VPN policy and the device's resulting running configuration. Admins can do this in Cisco Secure Firewall Management Center (FMC) or Cisco Secure Firewall Device Manager (FDM).

How serious is it?

The flaw carries a CVSS score of 8.6 out of 10, rated High. CVSS is the industry's standard way to score how severe a vulnerability is. The verified CVE data and the published reporting agree on this score.

Several factors raise the urgency:

• It is being exploited in the wild. Cisco confirmed this, and the CVE data shows the flaw in CISA's KEV catalogue.
• No login is needed. The attacker only has to reach the VPN login service.
• Firewalls sit at the network edge. When a firewall reboots, it can disrupt remote access and other traffic for a whole organisation.

There are limits to the impact. Based on the available information, the bug causes crashes and reboots. Cisco has not said it allows data theft or a takeover of the device. Exposure also depends on a specific configuration, secondary authentication on a tunnel group, so not every ASA or FTD deployment is affected.

The sources do not contradict each other on any of these points.

A separate, more advanced campaign

In the same period, Cisco Talos, the company's threat intelligence unit, described a different and more serious operation. An advanced persistent threat (APT) group it tracks as UAT-11473 exploited CVE-2026-20127. This is an authentication bypass flaw in Cisco SD-WAN Catalyst Controller instances, which help manage wide-area networks. The group used it to get into affected systems without valid credentials.

According to Talos, the attackers targeted three sectors:

• space and satellite services
• defence and aerospace technology
• policy research

Talos also found infrastructure overlaps with the "Silent Train" covert network associated with Volt Typhoon.

After getting in, the attackers deployed a custom malware framework that Talos calls KeyDrift. It includes components named PolyFlame and LittleFilch. Talos says KeyDrift runs inside SD-WAN control-plane processes, which are the parts of the system that manage how traffic is routed. From there it can do the following:

• intercept decrypted control traffic
• pull out session metadata and encryption keying material
• send the stolen data out in encrypted form
• act as a backdoor and as a relay for the attackers' command-and-control servers

The sources do not link UAT-11473 to exploitation of CVE-2026-76418.

What to do now

For network administrators:

• List every ASA and FTD device you run and check whether its SSL remote access VPN service is reachable, especially from the internet.
• Check every tunnel group for a configured secondary authentication server group. Always include DefaultWEBVPNGroup, even if the tunnel group list is turned off.
• On FTD, review the deployed remote access VPN policy and the device's running configuration in FMC or FDM.
• Upgrade to the fixed releases listed in Cisco's advisory as soon as you can.
• If you cannot patch right away, use Cisco's temporary workarounds. One is to turn off the tunnel group list, if DefaultWEBVPNGroup does not use secondary authentication. The other is to disable secondary authentication on affected user-configured tunnel groups or on the default group. Keep in mind that removing secondary authentication weakens your login security, so treat it only as a stopgap.
• Look for unexpected firewall reloads in your logs, as they could point to exploitation attempts.
• If you run Cisco SD-WAN Catalyst Controller, review Cisco's guidance on CVE-2026-20127 separately.

For everyday users:

• If your work VPN drops unexpectedly or keeps failing, report it to your IT team instead of repeatedly trying to reconnect.
• Be wary of unexpected messages asking you to install "VPN fixes" or new login tools. Updates should come from your IT department.

What we still don't know

• When exploitation began, who is behind it, and how widespread it is. Cisco did not share these details.
• The exact affected and fixed version numbers, which were missing from the material we reviewed.
• Whether the crashes are used on their own, or as a distraction or stepping stone in larger intrusions.
• Whether there is any connection between this activity and the UAT-11473 campaign against SD-WAN systems.

ITVedas analysis: A bug that only causes reboots can look minor, but attackers repeatedly target edge devices like VPN firewalls, and taking one offline can cut an organisation off from its remote workforce. Because the flaw is confirmed as exploited and needs no login, organisations that rely on Cisco remote access VPNs should treat patching as an emergency task.