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 reached the catalogue the next day

When this piece first went up, CISA's Known Exploited Vulnerabilities list carried no entry for CVE-2026-76418, and we said so. On 29 October, in catalogue version 2026.10.29, it was added with a due date of 1 November. Known ransomware use is recorded as unknown, and forensic triage is not requested for this one.

So the distance between a vendor saying its own response team sees exploitation and the government agreeing in writing was 1 day. The entry links Cisco's advisory and nothing else, which is the usual division of labour: the vendor describes the flaw and the catalogue sets the deadline.

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.
• Whether the catalogue listing rests on Cisco's account or on evidence CISA holds separately. The entry says neither.
• How many deployments actually run secondary authentication, which is the number that would turn this into a population estimate.