Cisco's 28 October advisory says two things on the same page. One: "there are no workarounds that address this vulnerability". The other, further down: you can mitigate it by removing secondary authentication from the tunnel group, and the advisory itself acknowledges that this reduces your security posture. Both are there, and the advisory doesn't choose for you.
This is CVE-2026-76418, in the Remote Access SSL VPN service of Cisco Secure Firewall ASA and FTD. An unauthenticated attacker sends a crafted request and the firewall reloads. It scores 8.6, and the PSIRT says it became aware of active exploitation before publishing the advisory. On what it means for a flaw in this service to hit availability only, we wrote about it then, when something very similar happened in August; this post is about the part that didn't exist in August.
What the advisory requires for you to be vulnerable
Three conditions, and all three come from the running configuration, not from the inventory:
- 1There is a
webvpnblock in the configuration. - 2Inside it there is an
enable <interface>, meaning Remote Access SSL VPN is enabled on at least one interface. - 3Some tunnel group has
secondary-authentication-server-group.
If any of the three doesn't hold, the advisory doesn't apply to you. That's more people than it looks, which is why the third condition deserves its own section: it's being misread almost everywhere.
secondary-authentication is not the same as "having MFA"
The condition is that command, literally, not the idea of having a second factor. And they are different things. In many deployments two-factor is handled by a single authentication server group —a RADIUS that internally does the password and the push, or SAML against the identity provider— and then no secondary-authentication-server-group exists in the configuration at all. That setup does not meet the third condition, however much MFA your users have.
We say this because the reading going around —"if you set up two-factor, this hits you"— is going to send people into a maintenance window they don't need. What decides isn't your identity policy: it's whether that command shows up when you read the configuration. Check before you move anything.
The group nobody created by hand
There's one instruction in the advisory that almost everyone skips. If you have tunnel-group-list enable, Cisco asks you to review every tunnel group, and names DefaultWEBVPNGroup explicitly. It's the group that ships with the box, the one nobody created on purpose and the one that doesn't come up when you ask the team which groups are configured. If somebody put secondary authentication on it at some point —or a migration six years ago left it there— you meet the third condition without knowing it.
What each option costs you
If you meet all three conditions, the advisory's menu is this:
| Option | What it costs you | What it leaves you |
|---|---|---|
| Upgrade | A maintenance window, with its outage | The bug closed and authentication as it was |
| Mitigate | Secondary authentication on that tunnel group | A box that no longer reloads, and a door with one lock fewer |
| Wait | Nothing today | The same outage, at a time somebody else picks |
The middle row is the one worth looking at twice. Cisco offers it and at the same time recommends upgrading, because it knows what it costs. If you use it, make it a step lasting hours, with an expiry date written into the ticket and into the calendar of somebody with a name. Two-factor removed "in the meantime" is the kind of change that's still there two years later because nobody remembers why it was made.
The second one in this service since August
On 11 August 2026 Cisco warned about CVE-2026-20349: same product, same Remote Access SSL VPN service, same 8.6 score, same unauthenticated attacker, also exploited before the advisory, caused by insufficient error checking when processing HTTP requests. 78 days passed between that advisory and this one. The deadlines CISA set in both cases were three days —this one expires on 1 November, which falls on a Sunday— and on that weekend arithmetic we already counted the days against CISA's own file.
Two advisories aren't a statistical trend, and we won't sell it to you as one. But they do change the planning question: if the same service has demanded an emergency window twice in eleven weeks, the patching calendar you had written for it has turned out to be too thin.
If you're reconciling identifiers for a report
A practical note we ran into while downloading CISA's catalog, and that we haven't seen quoted anywhere: the two sources don't call the same bug the same thing. The catalog titles the CVE-2026-76418 entry as an "unchecked return value to NULL pointer dereference", while the prose in Cisco's advisory talks about "logic errors". The same happens with the August one: CISA files it as a "heap inspection vulnerability" and Cisco describes something else. It isn't contradictory —one can be the root cause of the other— but if you're building a report that crosses both sources, expecting the same wording will cost you a while.
On the figure going around these days: Shadowserver sees more than 51,000 Cisco ASA devices with SSL VPN exposed to the internet. The outlet publishing it makes the point itself and it's worth repeating: that counts visible services, not vulnerable devices. It doesn't distinguish version, doesn't know which ones have secondary authentication configured —the third condition— and doesn't separate decoys. It's a measure of surface, not a count of victims.
What the patch doesn't change
The fixed ASA releases are 9.16.4.104 for the 9.16 branch and earlier, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48 and 9.24.1.27 (or 9.24.10.1) depending on which branch you live on. Patch. But when the window closes you'll still be facing two questions the patch doesn't touch:
- →How you get in to fix it. If the management path runs through the device you need to manage, you don't have emergency access. An out-of-band path exists for exactly this kind of night.
- →What else terminates in that box. Remote users, site-to-site tunnels and supplier access tend to end up in the same place out of convenience, and then they go together. And a backup link terminating on the same device with the same software version isn't a second path: we've written about why two paths only count as two if they share nothing.
Spreading those pieces out —user access and site access not living in the same box, the management plane having its own door— is network and communications design work. When several sites are involved, it's the conversation behind a properly designed SD-WAN: multiple paths, automatic failover and the policy written in one place.
How we look at it
We're not resellers for any firewall vendor: we recommend based on the case, not on the commission. We're a network operator with our own network —BGP, transit and peering, with a public looking glass at lg.everywan.com— and we build remote access and site interconnection with WireGuard and SD-WAN depending on the case. When an advisory like this drops, two things save us the night: the network documented in NetBox, which turns "how many of our sites does this hit?" into a query instead of a round of emails; and monitoring —Zabbix and SmokePing, with alerts that matter rather than noise— that tells a device that reloaded apart from a device that answers a ping.
And one thing we'd do even if you don't meet all three conditions: read the full tunnel group configuration this week. Not because of this bug, but because if it has to be read in a hurry on Sunday morning, you've already lost the hard part.
Sources (verified on 30 October 2026): Cisco security advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75, published 28-10-2026 at 19:15 GMT, version 1.0 Final — the source of CVE-2026-76418, the 8.6 base score with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H, the cause ("logic errors when secondary authentication is configured on a tunnel group"), the three vulnerable-product conditions (webvpn with enable on an interface, secondary-authentication-server-group, and reviewing every group including DefaultWEBVPNGroup when tunnel-group-list enable is set), the sentence "there are no workarounds that address this vulnerability" along with the mitigation and its security-impact warning, the fixed releases (9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 / 9.24.10.1) and the note on active exploitation in October 2026. Details of the August bug: advisory cisco-sa-asaftd-vpn-dos-dzv4mQFF (CVE-2026-20349, 11-08-2026, 8.6, insufficient error checking when processing HTTP requests to the Remote Access SSL VPN service). Catalog dates and deadlines: CISA's Known Exploited Vulnerabilities catalog, version 2026.10.29 with 1,764 entries, downloaded and read by us — CVE-2026-76418 added 29-10-2026 with a 01-11-2026 deadline, titled there "Unchecked Return Value to NULL Pointer Dereference"; CVE-2026-20349 added 11-08-2026, deadline 14-08-2026, titled "Heap Inspection Vulnerability". The figure of more than 51,000 exposed ASA SSL VPN devices, and the caveat that it doesn't equate to vulnerable devices, come from BleepingComputer (29-10-2026). The 78 days between 11 August and 28 October and the note on the naming difference between CISA and Cisco are our own arithmetic and reading. The distinction between secondary-authentication-server-group and "having MFA", the options table and the two design questions are also ours.
Do you know today which tunnel groups you have and what authentication each one carries?
At everyWAN we design and operate remote access and site interconnection for companies that can't afford an afternoon in the dark. We map out what depends on what and tell you where the single point of failure is.
Talk to everyWAN
Microsoft 365
ES 
CAT 
EN