Cisco FMC CVE-2026-20079: the Firewall Manager Roots Itself, and Three Crews Walked In

The device you bought to enforce your network policy is the device three different threat actors are now running as root. CVE-2026-20079 is a CVSS 10.0 authentication bypass in Cisco Secure Firewall Management Center (FMC) — the management plane for Firepower and Secure Firewall estates — and on 2026-09-09 Cisco Talos confirmed that it is being exploited in the wild by three distinct clusters: a crimeware group, the Russian state actor Sandworm, and a Qilin ransomware affiliate. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-09 with a federal remediation deadline of 2026-09-12 — a three-day fuse, the short tier CISA's risk-based BOD 26-04 assigns to a CVSS 10 under active state-actor exploitation. That deadline has already passed.

This is not an edge appliance leaking a config file. FMC is the console from which every managed firewall gets its rules, its logging policy, and its software. Lose FMC and you have not lost one box; you have lost the authority that decides what every firewall in front of it does — and the audit trail that was supposed to record the loss.

What CVE-2026-20079 actually is

Cisco describes the flaw as an improper process created at boot time that lets an unauthenticated, remote attacker send crafted HTTP requests to the FMC web interface, bypass authentication entirely, and execute scripts as root on the underlying OS. There is no privilege escalation step to chain and no credential to phish. A packet to the management interface is the whole exploit. It was found by Cisco's own Brandon Sakai and disclosed in early March 2026; the in-the-wild activity — confirmed by Cisco on 2026-09-10 — is what turned a patch advisory into a KEV entry.

Riding alongside it is CVE-2026-20316 (CVSS 5.3), a static-credentials weakness reported by Jimi Sebree at Horizon3.ai: a hard-coded low-privilege account that lets a remote attacker log in without knowing anything you set. On its own it is a medium. Chained behind the CVSS 10, it is the quiet second door the ransomware crew preferred.

The affected range runs from 6.4.0.13 through 10.0.1. Cisco shipped hotfixes for the supported trains — 7.0.9, 7.2.11, 7.4.6, 7.6.5, 7.7.12, and 10.0.1 — with a hardened maintenance release following the week of 2026-09-14. Cloud-delivered SCC/SaaS instances were patched server-side.

Why a rooted FMC is the worst box to lose

A firewall management console is a monitoring surface and a control surface at the same time, and that duality is exactly what makes it catastrophic to lose. Root on FMC gives an attacker three capabilities no ordinary foothold does:

• Push policy to every managed firewall. The attacker can author an access-control rule that whitelists their own C2, disable the logging that would record their traffic, or open a path they need for lateral movement — and the firewalls will accept it, because it came from the legitimate manager.
• Harvest the network's blueprint. FMC holds the configuration, object groups, and topology of everything it manages. Sandworm's cluster archived exactly this: managed-device configurations bundled for exfiltration.
• Tamper with the record. The device whose job is to tell you what happened on your network is now controlled by the person you want it to tell you about. Any log written on the FMC or on the boxes it manages is now suspect by construction.

"Show me the firewall logs for that window." "The firewall manager was root-compromised for that window." "…so the logs are evidence of what the attacker chose to let us see."

That is the shape of every post-incident conversation where the control plane fell. It is also why the useful detection signal is not on the appliance — it is on the wire, where behavior cannot be edited by whoever owns the console.

Three crews, one box: what the clusters did

Talos separated the activity into three clusters, and reading them in order is a compressed tour of what a rooted control plane is worth to different attackers.

Cluster	Actor	Entry	What they did
UAT-12197	Crimeware	CVE-2026-20079	Dropped a home.jsp web shell (Base64 param) and a cmd.jar executor in the Tomcat webroot; queried internal DBs via OmniQuery.pl to extract stored authentication data
UAT-11823	Sandworm (Russia)	20079 + 20316	Netcat reverse shell to 208.123.119.215:3090; abused package_info.pl and a malicious license.tmp (Makeself) executed as root; archived managed-device configs; deployed a Cyclops Blink ELF implant with DoH-based C2, credential harvesting, packet sniffing, and network scanning
UAT-11988	Qilin ransomware	CVE-2026-20316	Static-credential login, then package_info.pl living-off-the-land recon (hostnames, AD credentials, MySQL accounts); a socks5.py proxy and reverse-SSH tunnels forwarding LDAP (389), LDAPS (636), Kerberos (88), SMB (445), WinRM (5985); impacket, Invoke-TheHash, custom AV killers; Qilin ransomware on selected endpoints

Cyclops Blink is worth pausing on: it is the successor lineage to VPNFilter, purpose-built to live on network devices, and its presence here means Sandworm was not passing through FMC on the way to a workstation — the appliance was the objective. The Qilin cluster is the mirror image: FMC is the pivot, and the reverse-SSH tunnels forwarding Kerberos and SMB are the whole point — turn the firewall manager into a doorway into Active Directory, then encrypt.

The wire is the honest surface

Every one of those clusters had to do something the compromised console cannot hide: it had to move packets. The crimeware crew queried databases and staged credentials. Sandworm beaconed out over DNS-over-HTTPS and held a Netcat session to a never-before-seen IP. Qilin fanned reverse-SSH tunnels across LDAP, Kerberos, and SMB and then drove ransomware laterally. None of that lives cleanly in a log the attacker can edit — but all of it is visible as behavior on the network:

• A Netcat reverse shell from a management appliance to 208.123.119.215:3090 is an outbound session from a host that should almost never originate connections, to an ASN it has never talked to.
• Cyclops Blink's DoH C2 is encrypted, so signatures miss it — but its periodicity and the fact that it originates from an infrastructure device is a behavioral anomaly, not a payload match.
• Reverse-SSH tunnels forwarding Kerberos (88) and SMB (445) out of a firewall manager are lateral-movement fan-out with a shape a model can learn even when every byte is encrypted.
• Qilin's encryption phase has a traffic signature — rapid SMB write patterns to file shares, predictable lateral spread — that is detectable while it is happening, not in next morning's SIEM digest that the attacker may have already curated.

This is the case for treating the network as the primary witness in any environment where the control plane can be turned. Signatures and appliance logs assume the appliance is trustworthy. Once it is root-owned, only the traffic is still telling the truth.

Remediation

Treat any internet-reachable or lateral-reachable FMC as presumed-compromised until proven otherwise. Patching a control-plane box does not evict an attacker who already has root.

1. Am I affected? Check your FMC version in the web UI (Help → About) or via CLI show version. Anything from 6.4.0.13 through 10.0.1 without the hotfix is vulnerable. Enumerate exposure: the FMC web interface should never be reachable from the internet — confirm with an external scan of tcp/443 against your management IPs, and audit firewall rules for any path that reaches FMC from untrusted zones.

2. Patch — exact fixed versions. Apply the Cisco hotfix for your train: 7.0.9, 7.2.11, 7.4.6, 7.6.5, 7.7.12, or 10.0.1, with the hardened maintenance release (week of 2026-09-14) once available. SaaS/SCC instances are already patched. Patch the manager first, then verify managed devices did not receive attacker-authored policy while it was exposed.

3. Can't patch this hour? Compensating controls. Restrict the FMC management interface to a dedicated management VLAN and an explicit admin allow-list; drop all other reachability at the upstream device. Terminate any inbound access to tcp/443 on FMC from non-management networks. Cisco published Snort coverage — SIDs 66075–66080 for CVE-2026-20079, 66883 for CVE-2026-20316, and 66960/66961 for the associated malware — deploy them on the segment in front of the appliance, not on the appliance you no longer trust.

4. Hunt for compromise. Map to MITRE ATT&CK and look for:

• T1505.003 (Web Shell): unexpected .jsp/.jar files in the CSM Tomcat webroot — home.jsp (SHA-256 b037f45e02a289325a1a5eb0d4db6a9fce9954fd0fdfd07162cb4eb2acbef77d), cmd.jar (db491181ece3f319de6567ab6f6daa90c6879911cd890155e6b7d8cc7a1a8c8e).
• T1059 (Command/Script): a modified license.tmp (Makeself package) or unexpected invocations of package_info.pl and OmniQuery.pl.
• T1071.004 / T1572 (DoH C2, tunneling): outbound sessions from the FMC to 89.34.96.56, 208.123.119.215, 91.214.78.118, 104.218.165.253, or 43.204.2.142; Cyclops Blink implant (6f98add5d1a7729192b6ad8491d85c505c64836f7881742d6b93bd8e3d2fe461); any reverse-SSH or SOCKS5 tunnel originating from a management appliance.
• T1078 (Valid Accounts): logins to the static low-priv account from CVE-2026-20316.
• T1021 / T1003 / T1486: impacket, Invoke-TheHash, AV-killer execution, and SMB write bursts on managed segments — the Qilin lateral-and-encrypt chain.

5. Eradicate + verify. Rebuild a confirmed-compromised FMC from clean media rather than cleaning it in place — a root-level implant on a control appliance is not something you selectively remove. Rotate every credential the FMC could see: its own admin accounts, any AD/LDAP service accounts it holds, MySQL accounts, and — critically — the trust and keys between FMC and its managed firewalls, since the attacker had root on the authority that manages them. Re-baseline every managed firewall's policy against a known-good config and diff for attacker-authored rules. Confirm clean after patching by watching the wire for the C2 and tunnel behavior above — the absence of those sessions, not the absence of a log entry, is the proof.

Where Zero Hunt fits

Everything above turns on one fact: when the control plane falls, the network is the only surface still telling the truth. That is the exact problem Zero Hunt's AI Traffic Analysis pillar was built for. It is a proprietary deep-learning model trained on billions of PCAP sequences, running locally on the appliance GPU at a 2.7+ Gbit/s baseline, with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, and application fingerprinting. It reads the Netcat reverse shell from an appliance that should never dial out, the DoH periodicity of a Cyclops Blink beacon, the reverse-SSH fan-out forwarding Kerberos and SMB, and the SMB write signature of Qilin encryption as behavior, while it happens — none of which depends on a log written by the box the attacker now owns, because the model runs out-of-band on hardware the attacker never touched.

The follow-on is validation. Zero Hunt's change-triggered campaigns treat a newly-exposed management interface on the perimeter as a trigger: within the hour, the 10-agent swarm runs a per-target exploitation attempt against your actual FMC — a generative auth-bypass chain written by a local LLM, not a copied PoC, backtested in AI Gym before it touches your environment and ECDSA-signed per finding. That answers the question CVSS 10 only implies: not "is this bug severe" but "is my FMC reachable and exploitable right now" — with the audit-grade evidence that FMC sits inside your NIS2 and DORA scope, a control the auditor assumes is working until you can prove it was.

CISA's federal clock on this one ran out on 2026-09-12. The clock the three clusters are running never had a deadline.