← Back to Feed CACHED · 2026-10-28 22:02:20 · CACHE_KEY CVE-2026-76418
CVE-2026-76418 · CWE-690 · Disclosed 2026-10-28

Cisco ASA/FTD SSL VPN secondary auth NULL pointer dereference DoS

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

The lock you added to your front door is the exact thing that lets someone knock the whole house over

CVE-2026-76418 is a denial-of-service vulnerability in the Remote Access SSL VPN service of Cisco Secure Firewall ASA Software (versions 9.16.1 through 9.24.10) and Cisco Secure Firewall Threat Defense Software (versions 7.0.0 through 10.1.0). The root cause is a logic error in the code path that processes secondary authentication on VPN tunnel groups — specifically, an unchecked return value leads to a NULL pointer dereference (CWE-690). When an unauthenticated attacker sends a crafted request during the SSL VPN connection process, the device crashes and fully reloads. No credentials are required; the vulnerable code path is reached *before* authentication completes. The cruel irony: organizations that configured secondary-authentication-server-group — typically RADIUS-based MFA — to *harden* their VPN are the only ones exposed to this crash. Cisco tracks this as Bug ID CSCwx26625 under advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75.

Cisco rates this HIGH at 8.6, and that baseline is broadly defensible for the access profile. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C) reflects the worst-case attacker position — unauthenticated, remote, low complexity, with scope change because crashing the firewall disrupts every service behind it. However, the 8.6 does not account for the configuration prerequisite: only devices with secondary-authentication-server-group set on at least one tunnel group are vulnerable. This meaningfully narrows the exposed population — the feature is common in security-mature enterprises but far from universal across the installed base. We adjust to 7.8 to reflect that friction. Critically, Cisco PSIRT confirmed active exploitation in October 2026, the same month as disclosure. This is not theoretical. Attackers have working exploits, and the mandatory upgrade cadence should reflect that reality regardless of the decimal in the score.

"The MFA you added to harden VPN is exactly what lets attackers crash your firewall with one packet"
02 · The Attack Path

5 steps from start to impact.

STEP 01

Identify internet-facing ASA/FTD SSL VPN endpoints

The attacker uses Shodan, Censys, or FOFA to enumerate Cisco ASA/FTD devices with SSL VPN enabled on internet-facing interfaces. Banner analysis on port 443 reveals characteristic Cisco WebVPN responses — the webvpn cookie, HTML title strings, and TLS certificate patterns uniquely fingerprint these devices. Shadowserver data from 2025 showed approximately 48,800 internet-exposed ASA/FTD instances.
Conditions required:
  • Target organization runs Cisco ASA or FTD with webvpn enabled on a public interface
Where this breaks in practice:
  • The target pool is large — tens of thousands of internet-facing devices — so this step is trivial for any motivated attacker
Detection/coverage: Passive recon via Shodan/Censys is invisible to defenders. Active port 443 scanning may be logged at the firewall or by GreyNoise-style sensors.
STEP 02

Probe for secondary authentication presence

The attacker navigates to the SSL VPN login portal. If tunnel-group-list enable is configured, connection profiles are visible in the login dropdown and can hint at secondary auth configurations. Even without the list, DefaultWEBVPNGroup may use secondary auth. The attacker can infer the feature by observing a secondary credentials prompt during the login flow — or simply spray the exploit blindly, since the crash occurs pre-authentication.
Conditions required:
  • At least one tunnel group has secondary-authentication-server-group configured
  • SSL VPN service is reachable
Where this breaks in practice:
  • Not all ASA/FTD deployments use secondary authentication — this is the primary population-narrowing factor
  • Attacker must either know or guess the configuration, or attempt blind exploitation
Detection/coverage: Looks identical to legitimate VPN login attempts. No distinguishing network signature at this stage.
STEP 03

Send crafted request triggering NULL pointer dereference

The attacker sends a specially crafted request during the SSL VPN connection handshake that hits the logic error in secondary authentication processing. The unchecked return value causes a NULL pointer dereference in the SSL VPN service, which runs in the firewall's data plane. No valid credentials are needed — the vulnerable code path is reached before authentication completes. No public PoC exists, but Cisco PSIRT confirmed threat actors have working exploits.
Conditions required:
  • Working exploit for the secondary auth logic error (no public PoC as of October 2026)
  • Network path to the SSL VPN listener
Where this breaks in practice:
  • No public PoC or Metasploit module reduces the attacker pool to those with custom exploit development capability
  • However, active exploitation is confirmed — at least some threat actors have crossed this barrier
Detection/coverage: Cisco has not published IOCs or Snort signatures specific to CVE-2026-76418. Device crashinfo logs and syslog messages showing unexpected reloads correlated with SSL VPN connections are the primary indicators.
STEP 04

Device crashes and reloads — firewall and VPN offline

The ASA/FTD device performs a full reload, dropping all active VPN sessions, stateful firewall connections, NAT translations, and routing adjacencies. Every user behind the device loses connectivity. In standalone deployments, the outage lasts 2–5 minutes depending on hardware model and configuration size. The attacker achieves complete denial of service against the perimeter.
Conditions required:
  • Successful delivery of the crafted request from step 3
Where this breaks in practice:
  • Active/standby HA pairs may failover in under 1 second, limiting single-crash impact
  • Active/active clustering provides additional resilience
Detection/coverage: Syslog crashinfo events, SNMP coldStart or warmStart traps, VPN session count dropping to zero, BGP/OSPF adjacency flaps visible to upstream peers.
STEP 05

Repeat to sustain persistent denial of service

The attacker re-sends the crafted request each time the device recovers. With a 2–5 minute reload cycle, the firewall enters a crash-reload loop. In HA deployments, the attacker targets both units sequentially. The sustained outage blocks all remote access VPN, site-to-site tunnels, and traffic inspection until the attack stops or the device is patched.
Conditions required:
  • Attacker maintains network connectivity to target
  • Attacker can detect when device has recovered (e.g., port 443 becomes reachable again)
Where this breaks in practice:
  • HA failover complicates targeting — attacker must identify and reach both cluster members
  • Upstream ISP or transit provider could null-route attacker source IPs
  • Geo-blocking or control-plane ACLs could restrict access during incident response
Detection/coverage: Multiple crash/reload events in rapid succession are highly anomalous. SIEM correlation on crashinfo events + VPN session drops should trigger P1 alerting.
03 · Compensating Control

1
HIGH 7.8→IGNORE 0.0
SEVERITY REDUCED
Apply the vendor patch immediately — Upgrade to a fixed release: ASA 9.16.4.104 / 9.18.4.96 / 9.20.4.50 / 9.22.3.200 / 9.23.1.48 / 9.24.1.27 or FTD 7.0.11 / 7.2.13 / 7.4.9 / 7.6.7 / 7.7.14 / 10.0.3 / 10.1.1. This eliminates the vulnerability entirely. Given confirmed active exploitation, deploy within hours — not days — per the active-exploitation SLA override. Schedule an emergency maintenance window. Test the upgrade in a lab or non-critical HA peer first if possible, but do not delay beyond 24 hours.
2
HIGH 7.8→IGNORE 0.0
SEVERITY REDUCED
Remove secondary authentication from affected tunnel groups — Run no secondary-authentication-server-group under each affected tunnel-group <name> general-attributes block. This eliminates the vulnerable code path entirely — the NULL pointer dereference cannot be reached without secondary auth configured. Deploy immediately as an interim mitigation if patching requires a longer maintenance window. Tradeoff: this removes your MFA layer for VPN access, degrading your authentication posture. Pair with compensating controls like certificate-based auth or Duo-at-the-IdP if you go this route.
3
HIGH 7.8→HIGH 7.0
Disable tunnel-group-list to hide connection profiles — Configure no tunnel-group-list enable under webvpn mode. This prevents attackers from enumerating tunnel groups via the login dropdown and limits connections to DefaultWEBVPNGroup. Only effective if DefaultWEBVPNGroup itself does not use secondary authentication. If it does, this control provides no benefit. Users must know their connection profile name, which adds minor operational friction.
4
HIGH 7.8→MEDIUM 5.5
SEVERITY REDUCED
Restrict SSL VPN access via control-plane ACL to known IP ranges — Apply an ACL on the outside interface to restrict access to the SSL VPN listener (typically TCP/443) to known corporate IP ranges, partner networks, or geo-fenced regions. This dramatically shrinks the attacker pool that can reach the vulnerable endpoint. Works best for organizations with static remote-access populations. For mobile workforces, consider restricting to cloud proxy egress IPs (Zscaler, Netskope) as a middle ground. Deploy within hours given active exploitation.
5
HIGH 7.8→MEDIUM 5.0
SEVERITY REDUCED
Ensure HA failover is configured and tested — If not already deployed, configure active/standby failover so that a device reload triggers automatic failover to the standby unit. This limits the impact of a single crash to seconds rather than minutes. Note that a persistent attacker can target both units sequentially, so HA is not a fix — it buys time. Verify failover with a manual test (failover active / no failover active) before relying on it during an attack.
What doesn't work
  • Generic IPS/IDS signatures — Cisco has not published Snort rules or IOCs specific to CVE-2026-76418. The crafted request arrives on the same HTTPS port as legitimate VPN traffic, making signature-based detection impractical without vendor-supplied patterns.
  • Rate-limiting SSL VPN connections — The exploit may require only a single crafted request to trigger the device reload. Connection-rate limits do not help when the first packet crashes the device.
  • Disabling the SSL VPN service entirely — Technically eliminates the vulnerability, but destroys the remote access capability the device exists to provide. Not a viable compensating control for organizations that depend on the VPN.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationConfirmed. Cisco PSIRT states in the October 28, 2026 advisory (v1.0) that they "became aware of active exploitation of this vulnerability" in October 2026. No specific threat actor attribution or campaign details have been published.
Proof-of-concept availabilityNone public. No PoC found on GitHub, ExploitDB, pocindex.io, or Nuclei template repositories as of October 29, 2026. No Metasploit module exists. The exploit is held privately by threat actors conducting active exploitation.
EPSS scoreNot yet scored. The FIRST EPSS API returns no data for this CVE (published October 28, 2026 — too recent for EPSS model ingestion). Expect a score within 1–2 weeks.
CISA KEV statusNot listed as of October 29, 2026. Given confirmed active exploitation by the vendor, KEV addition is likely imminent. Monitor KEV catalog for updates.
CVSS vector breakdownCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H — Network-reachable, low complexity, no privileges, no user interaction. Scope: Changed reflects that crashing the firewall disrupts all services behind it (VPN users, inspected traffic). Availability impact is High; no confidentiality or integrity impact.
Affected version rangesASA: 9.16.1 through 9.24.10 (142 affected builds across 9.16, 9.18, 9.19, 9.20, 9.22, 9.23, 9.24 branches). FTD: 7.0.0 through 10.1.0 (67 affected builds across 7.0, 7.2, 7.3, 7.4, 7.6, 7.7, 10.0, 10.1 branches). Requires secondary-authentication-server-group on at least one tunnel group with SSL VPN enabled.
Fixed versionsASA: 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. FTD: 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3, 10.1.1.
Scanning & exposure dataShadowserver Foundation identified ~48,800 internet-exposed Cisco ASA/FTD devices in 2025. Eclypsium reported a scanning surge targeting ASA appliances in 2026. Not all exposed devices use secondary auth, but the subset that does is disproportionately composed of larger enterprises.
Disclosure & attributionDisclosed October 28, 2026 by Cisco (CNA). Cisco Bug ID CSCwx26625. Discovered by Eric Fernald during a Cisco TAC support case. Advisory: cisco-sa-asaftd-tunnel-dos-s6mgkb75.
Related CVEsDo not confuse with CVE-2026-20349 (cisco-sa-asaftd-vpn-dos-dzv4mQFF), a *different* ASA/FTD SSL VPN DoS disclosed August 2026 with active exploitation and KEV listing. That bug is in HTTP request error-checking (CWE-244); this one is in secondary authentication logic (CWE-690). Both affect overlapping version ranges. Ensure your patching covers both.

Sources.

  1. Cisco Security Advisory (cisco-sa-asaftd-tunnel-dos-s6mgkb75)
  2. Strix AI — CVE-2026-76418 detail page
  3. Offseq Radar — CVE-2026-76418 threat intelligence
  4. BleepingComputer — Cisco ASA/FTD VPN flaw context
  5. Eclypsium — Cisco ASA scanning surge and exposure analysis
  6. SC World — Shadowserver exposure data on ASA/FTD devices
  7. TheHackerWire — CVE-2026-76418 analysis
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.8/10)

Why this verdict

  • Active exploitation confirmed by the vendor: Cisco PSIRT acknowledged active exploitation in October 2026, the same month as disclosure. Threat actors have working private exploits despite zero public PoC. This eliminates any theoretical-risk discount and triggers immediate-action SLA overrides.
  • Unauthenticated remote, low complexity: The attack requires no credentials, no user interaction, and no race conditions. Any internet-reachable attacker can attempt it. The CVSS access vector profile is maximally hostile.
  • Secondary authentication prerequisite narrows the vulnerable population: Only ASA/FTD devices with secondary-authentication-server-group configured on at least one tunnel group are affected. This is a real deployment-specific narrowing that the vendor's 8.6 does not reflect. Estimated 30–50% of SSL VPN-enabled ASA/FTD deployments use secondary auth, concentrated in security-mature enterprises. This prevents CRITICAL but does not drop below HIGH. Adjustment: −0.8 from vendor baseline.
  • DoS-only impact caps the ceiling: No code execution, no data exfiltration, no credential exposure. The blast radius is availability — device reload drops VPN sessions and firewall state. Severe operationally, but not a compromise vector.
  • Role multiplier: Cisco ASA/FTD is a canonical network edge appliance — effectively 100% of installs serve the perimeter firewall/VPN concentrator role. This is a high-value-role component by definition. A sustained DoS on the perimeter firewall impacts site-wide connectivity, remote access for the entire workforce, security inspection of all traffic, and site-to-site tunnels. The blast radius is site-wide availability. However, the outcome is service disruption, not domain takeover or data breach, so the floor is HIGH (not CRITICAL). The chain succeeds in the high-value role with blast radius = site, which floors the verdict at HIGH.

Why not higher?

The impact is availability-only — no code execution, no data exfiltration, no lateral movement, no credential exposure. A DoS on a perimeter device is operationally painful but does not give the attacker a foothold, domain access, or data. Additionally, the secondary authentication prerequisite means a material fraction of the ASA/FTD installed base is simply not vulnerable — only those deployments that explicitly configured MFA on tunnel groups are exposed. These two factors together — DoS ceiling plus configuration narrowing — cap the severity below CRITICAL, even with active exploitation.

Why not lower?

Cisco PSIRT confirmed active exploitation in October 2026, meaning this is not theoretical — threat actors are weaponizing this right now. The affected component is a perimeter firewall and VPN concentrator, the canonical network edge appliance, where DoS has outsized operational impact (site-wide outage, remote workforce lockout). The attack is unauthenticated, remote, low-complexity, and repeatable for sustained disruption. No workaround exists — only mitigations that themselves degrade the security posture. Dropping below HIGH would undercount the real-world risk to any organization running secondary auth on their ASA VPN.

06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation with SSH access to the target Cisco ASA or FTD device. Invoke as bash check_cve_2026_76418.sh <device_ip> [ssh_user] (e.g., bash check_cve_2026_76418.sh 10.1.1.1 admin). Requires SSH credentials with privilege level sufficient to execute show running-config and show version.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-76418 Vulnerability Check — Cisco ASA/FTD
# Checks: (1) SSL VPN enabled, (2) secondary-authentication-server-group configured
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED  1=VULNERABLE  2=UNKNOWN
set -uo pipefail

HOST="${1:?Usage: $0 <device_ip_or_hostname> [ssh_user]}"
USER="${2:-admin}"

rcmd() {
  ssh -o ConnectTimeout=10 -o StrictHostKeyChecking=no -o BatchMode=yes \
      "${USER}@${HOST}" "$1" 2>/dev/null
}

echo "=== CVE-2026-76418 check: ${HOST} ==="

# Step 1: Check if SSL VPN (webvpn) is enabled on any interface
WV=$(rcmd "show running-config webvpn") || {
  echo "UNKNOWN - SSH connection failed or command rejected on ${HOST}"
  exit 2
}
if ! printf '%s' "$WV" | grep -qiE '^[[:space:]]*enable[[:space:]]'; then
  echo "PATCHED - SSL VPN (webvpn) is not enabled on any interface"
  exit 0
fi
echo "[+] SSL VPN is enabled"

# Step 2: Check for secondary authentication on any tunnel group
TG=$(rcmd "show running-config tunnel-group") || {
  echo "UNKNOWN - Cannot retrieve tunnel-group configuration from ${HOST}"
  exit 2
}
if ! printf '%s' "$TG" | grep -qi 'secondary-authentication-server-group'; then
  echo "PATCHED - No tunnel group uses secondary authentication; CVE-2026-76418 prerequisite not met"
  exit 0
fi
echo "[!] Secondary authentication configured on tunnel group(s):"
printf '%s\n' "$TG" | grep -i 'secondary-authentication-server-group' | sed 's/^/    /'

# Step 3: Print version for manual comparison against fixed releases
VER=$(rcmd "show version" | grep -iE 'software version|cisco adaptive|firepower threat' | head -3)
echo ""
echo "[i] Device version info:"
echo "    ${VER:-Could not determine version}"
echo ""
echo "Fixed ASA: 9.16.4(104) | 9.18.4(96) | 9.20.4(50) | 9.22.3(200) | 9.23.1(48) | 9.24.1(27)"
echo "Fixed FTD: 7.0.11 | 7.2.13 | 7.4.9 | 7.6.7 | 7.7.14 | 10.0.3 | 10.1.1"
echo ""
echo "VULNERABLE - ${HOST} has SSL VPN enabled with secondary authentication on at"
echo "  least one tunnel group. Verify version against fixed releases above."
echo "  Ref: cisco-sa-asaftd-tunnel-dos-s6mgkb75"
exit 1