CVE-2026-76418 Hits Cisco ASA and FTD: Patch Now

CVE-2026-76418 is a NULL pointer dereference in Cisco Secure Firewall ASA Software and Cisco Secure FTD Software, and it is already being exploited. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-10-29 and gave defenders a due date of 2026-11-01. An unauthenticated, remote attacker can use it to force a device reload — a denial of service against your internet edge. If an ASA or FTD box terminates traffic from outside your network, it is in scope. The fix is the vendor's mitigation applied to the software version actually running on the device, and proof from the device itself that the version changed.

What CVE-2026-76418 actually does

It is an unchecked return value that ends in a NULL pointer dereference, and the only outcome CISA describes is a device reload. In plain terms: code inside the firewall calls a function, does not check whether the call succeeded, then writes through a pointer that came back empty. CISA's short description says an unauthenticated, remote attacker could trigger this and cause the device to reload unexpectedly, resulting in a denial of service. Nothing in the entry describes code execution, credential theft or traffic decryption — the stated impact is availability. That is still serious on a perimeter device: a reload drops every session through it, and a reload that repeats becomes a sustained outage for VPN users and anything routed over that link.

CVE-2026-76418: are you running Cisco Secure Firewall ASA Software or Cisco Secure FTD Software?

You are affected if either product is deployed and an interface that processes untrusted traffic is reachable from the internet. Both ASA and FTD are named in the same entry, so do not assume your platform is the safe one. CISA places the judgement on the asset owner: stakeholders are responsible for evaluating each asset's internet exposure. Inventory is the hard part. Cloud VPC firewalls tend to be visible in a console; appliances in a colo cage, a branch office or a DR site often are not. If you have self-managed infrastructure sitting outside a provider's dashboard, that is where to look first.

What to do in the next 24 hours

Treat this as an availability task with a deadline that has already passed, not as a compliance item to log. CISA's required action is to apply mitigations in accordance with vendor instructions, and where mitigations are unavailable, its guidance is to discontinue use of the product. Concretely:

• Pull the running software version from each device's own console or management plane, not from your CMDB, and note it with a timestamp.
• Apply the vendor mitigation or upgrade on every instance, including HA standby units, DR replicas and any lab box sharing a management network.
• After any failover, re-check which unit is actually passing traffic and confirm its version too.
• Export logs and configs before and after the change, so you can tell a planned reload from a crash.
• Afterwards, watch for uptime counters resetting, reload-reason syslog messages, SNMP cold-start traps and gaps in flow or session logs. Keep watching for a few days — a crash loop is the failure mode that hurts.

The deadline was 2026-11-01, in catalog version 2026.10.30

CISA's remediation deadline for CVE-2026-76418 has already passed. The entry was added on 2026-10-29, in catalog version 2026.10.30, with a due date of 2026-11-01. That short window tells you how CISA is treating this one, and it is the same reason you should not park it behind next sprint. The required action also points at CISA's BOD 26-04 risk-based patching guidance and its Forensics Triage Requirements. If you sell into the US public sector, or sit in a supply chain that does, expect those references in a vendor questionnaire. Ransomware campaign use is recorded as Unknown — a gap in the record, not a clean bill of health. For most Indian teams the practical trigger is a client security review or an insurance renewal rather than a regulator; getting ahead of it costs a day.

Where AI changes the workflow for a bug like this

AI will not tell you whether your edge is exposed; your asset register will. What it compresses is the gap between an advisory landing and a defensible answer about scope. Feed it your device inventory and version exports, and ask it to map devices to the two named products, flag which are internet-facing, and draft the change tickets and the note to your ops team — work that used to eat a morning. On the code side, unchecked return values and missing NULL checks are exactly the pattern a tired reviewer skims past and a linter or AI-assisted review catches consistently, in your own C and C++ as much as in vendor code. The caveat is real: a model will misread a version or model string with total confidence, so let it produce the checklist while the device stays the source of truth. Our AI practice uses it that way — as a reviewer, never as the record.

Where to start

Start with the device that terminates your internet traffic and work inward. Pull running versions today, apply the mitigation per Cisco's instructions, and write down the before-and-after state so the next audit question takes minutes instead of a week. If you would rather do the inventory pass with someone, Maysan Labs does this kind of work — finding what is actually running, then fixing it.