CVE-2026-20079 scores a perfect 10.0. CISA added it to the Known Exploited Vulnerabilities catalogue on 9 September 2026 — a full six months after Cisco disclosed it, on 4 March.
That gap is the first thing worth understanding about this vulnerability, before the mechanism.
What it does
Per NVD, the flaw sits in the web interface of Cisco Secure Firewall Management Center (FMC) — the console administrators use to configure and monitor Cisco's firewall fleet — and allows an unauthenticated, remote attacker to bypass authentication and execute script files on the affected device. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) says the same thing in structured form: network-reachable, low complexity, no privileges needed, no user interaction, and a scope change — meaning what the bug compromises extends beyond the vulnerable component itself.
FMC is not a firewall. It is the thing that manages firewalls — the console with authority to push configuration to every Cisco Secure Firewall device it administers. Authentication bypass on the management plane of a firewall fleet is not "one device compromised." It is standing access to redefine the security posture of everything the console controls.
Why six months between disclosure and confirmed exploitation matters
A CVSS 10.0 sitting unexploited — or at least unconfirmed as exploited — for six months is not unusual; plenty of critical vulnerabilities never get weaponised, either because exploitation is harder in practice than the score suggests or because attackers have easier options elsewhere. What changed on 9 September is that CISA's catalogue entry states the opposite is now true for this one: someone built a working exploit and used it.
That gap has one operational implication that matters more than the historical curiosity: any organisation that treated this as "patched eventually, no rush" because six months passed without incident now has a different fact to work from. The absence of confirmed exploitation was never evidence that exploitation was impossible — only that it hadn't been observed yet.
What a management-plane bypass actually reaches
FMC is not deployed to protect itself — it exists to hold the policy, object definitions, and access-control rules for every Secure Firewall device registered to it, and to push changes to those devices on an administrator's behalf. An attacker who bypasses authentication on FMC's web interface inherits that same authority: the ability to read the current firewall ruleset for reconnaissance, the ability to modify it, and in many deployments, the ability to push a change that opens a path the organisation believed was closed, all without the individual firewalls themselves ever being directly attacked or even necessarily patched against anything.
Scope change in the CVSS vector (S:C) is the formal way NVD encodes exactly this: the vulnerable component and the components actually affected by exploitation are different. Here, the vulnerable component is FMC's web interface; the affected components are every firewall FMC administers, whatever their own patch level.
What to check this week
Confirm patch status against the March disclosure, not against today's KEV date. If your FMC deployment was never patched for this specific CVE, six months of exposure just became six months your organisation needs to account for, not six months of safety.
Audit FMC's own configuration history for the affected window. A management-plane authentication bypass with a scope change means the meaningful question isn't just "was FMC itself compromised" — it's "what did the compromised console push to the firewalls it manages."
Restrict what can reach the FMC web interface directly. A device with this much downstream authority over an organisation's firewall posture should not be reachable from a general network segment regardless of patch status.
The general lesson about management-plane software specifically
Security teams frequently apply more scrutiny to the devices doing the enforcing — the firewalls, the endpoint agents — than to the consoles administering them, on the reasoning that the management layer is internal-only and therefore lower-risk by default. FMC's own deployment guidance typically recommends restricting its web interface to a trusted management network for exactly this reason, but that recommendation is only as good as its actual enforcement, and management interfaces have a long history of ending up reachable from broader network segments than intended — through a VPN misconfiguration, a firewall rule added for a legitimate but forgotten reason, or a network segmentation boundary that shifted during an unrelated infrastructure change.
How Safeguard helps
Safeguard's continuous inventory tracks not just whether a vulnerable version of a product like FMC is present, but how long it has been present and unpatched — which is exactly the context that turns "critical CVE, no known exploitation" into an accurately prioritised finding rather than a deprioritised one. When a KEV entry lands months after disclosure, as this one did, that history is what should move remediation ahead of newer, lower-context findings in the same queue.
