Cisco says this firewall flaw is being exploited. You are only exposed if you turned on the extra authentication

Cisco published advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75 on 28 October at 19:15 GMT. CVE-2026-76418 scores 8.6 on CVSS 3.1, and the sentence that matters is short: "In October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability."

An unauthenticated remote attacker sends a crafted request to the SSL remote access VPN and the device reloads. No password, no foothold, no user interaction.

The precondition is the hardening

The flaw only applies where 2 things are true: the SSL remote access VPN login service is reachable, and secondary authentication is configured on a tunnel group. Secondary authentication is the setting you add when you want a second authentication server in the path, which is to say it is exactly the setting a careful administrator turns on.

So the devices exposed to this are, by definition, the ones configured more carefully than the default.

The mitigations make the same point from the other side. Cisco offers 2, and both work by taking the hardening away: disable the tunnel group list so the group using secondary authentication cannot be selected, or remove the secondary authentication server group outright.

Cisco says plainly that the second one lowers the remote access VPN security posture, and that neither fully addresses the vulnerability.

What it does, and what it does not

The vector is AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H. Confidentiality none, integrity none, availability high, and the scope changed. Nothing is read, nothing is altered, nothing executes. The weakness class is CWE-690, an unchecked return value reaching a null pointer dereference.

What it costs you is everybody's remote access at once. A firewall that reloads takes every VPN session with it, and a request that can be repeated is an outage that does not end on its own. For an organisation whose staff reach everything through that tunnel, there is not much practical difference between this and a successful intrusion for the hours it lasts.

Found on a support case

The credit is to Eric Fernald, who found it while working a Cisco Technical Assistance Center case.

That is a detail with a shape to it. TAC cases get opened because something is already going wrong, so the likely sequence is that somebody's firewall was reloading, an engineer went looking for the cause, and what turned up was a remotely triggerable flaw rather than a bad config. The exploitation statement in the advisory reads differently once you know where the discovery came from.

It is not on the catalogue

As of catalogue version 2026.10.28, with 1,762 entries, CISA's Known Exploited Vulnerabilities list carries no entry for CVE-2026-76418. The same day's additions were a Linux kernel flaw, CVE-2026-46300, due 31 October with forensic triage requested, and a VMware ESX logging flaw, CVE-2026-41709, due 11 November.

That is a statement about the catalogue, not about the exploitation. Cisco says its own response team is aware of active exploitation, and that is the vendor's own account of its own product, which is the strongest kind of exploitation claim available short of a government listing.

What to do

• Check whether this applies at all. Look for webvpn with SSL VPN enabled on an interface, then look for secondary-authentication-server-group on your tunnel groups, including DefaultWEBVPNGroup.
• Upgrade. On ASA the first fixed releases include 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 and 9.24.1.27. On FTD they include 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 and 10.1.1.
• If you take a mitigation instead, know what you are trading. Removing secondary authentication makes the login path weaker in exchange for making it harder to crash.
• Cloud-delivered Firewall, cloud-delivered management centre, Secure Access and Secure FMC are not affected, so inventory by deployment type rather than by vendor name.
• Treat unexplained reloads on these devices as a security event. That is how this one was found.

What is not established

• Who is exploiting it, and whether the activity is targeted or opportunistic. Cisco names nobody.
• How many devices have been crashed. No count has been published.
• Whether the crashes are an end in themselves or cover for something else. Nothing in the advisory addresses that.
• Why it is not yet on CISA's catalogue, which has listed other vendors' flaws on the strength of less public detail.
• How many deployments actually run secondary authentication, which is the number that would turn this into a population estimate.