CVE-2026-20079: the 10.0 auth-bypass that shares a footprint with the FMC bug already under attack

Picture the one box in your network whose whole job is to be trusted. Not a firewall — the thing that programs the firewalls: the management center that pushes policy, signatures and access rules down to every Secure Firewall you run. Now picture an unauthenticated stranger, somewhere on the internet, mailing it a handful of crafted HTTP requests and walking away with root on the operating system underneath. That is CVE-2026-20079, and it scores a flat 10.0. Let me rewind to how we got here.

A few days ago I wrote about CVE-2026-20316 — a 5.3 that the CVSS number badly undersold, a static low-privilege credential baked into the same FMC software, already exploited in the wild and already in CISA's catalog. That piece ended on an unfinished thought: Cisco itself rated the 5.3 High, not Medium, because it "can be used with other Cisco Secure FMC vulnerabilities to elevate privileges." Which other vulnerabilities? On July 29 Cisco answered the question without quite saying so — it quietly revised a second, older advisory, and the two suddenly share a fingerprint.

Two advisories, one footprint

Here is the part that made me sit up. CVE-2026-20079 is not new — its advisory was first published back in March. What changed on July 29 was small and telling: Cisco bolted a second internal bug ID onto it (CSCwt95974), and shipped it the same indicators of compromise and the same per-train hot fixes that ship with the exploited static-credential flaw. Same footprint. Same patch. Can that be a coincidence? Maybe. But when two advisories start pointing at the exact same file dropped in /var/tmp, the honest reading is that whatever is happening in the wild touches both.

The boot-time process

What actually breaks? Cisco's own words: the flaw is "due to an improper system process that is created at boot time." That is all we are given, and I am not going to invent the rest — I have not reversed the binary, and I would rather leave a blank than fill it with fiction. What the advisory does tell us is the shape. A process comes up at boot. It is reachable from the web interface. It will execute script files. Feed it crafted HTTP and it runs "a variety of scripts and commands" as root. No login. No user interaction. And the scope metric is Changed — CVSS's way of saying the damage leaves the vulnerable component and lands on the whole operating system beneath it.

So is it actually being exploited?

Here is where I have to be careful, because the signals disagree with each other. Cisco's PSIRT says plainly it is "not aware of any public announcements or malicious use" of 20079. Our own index flags has_exploit — there is a public repository carrying the CVE's name — yet there is no Metasploit module, no Nuclei template, no confirmed campaign attached to this CVE. Meanwhile its 5.3 cousin, 20316, is the one with the confirmed in-the-wild zero-day and the KEV listing. Read those as three different questions and the fog clears.

• CVSS asks how bad it would be if exploited — for 20079, a flat 10.0.
• EPSS asks how likely exploitation is — 98th percentile, high.
• KEV asks whether it is confirmed happening — for the cousin 20316: yes; for 20079: not yet, per Cisco.

Hunt for the shared footprint

Cisco publishes an expert-mode check for the trail both advisories point at. Run it on every FMC you manage, verbatim from the advisory:

zgrep "package_info.*license" /var/log/messages*# A hit that looks like this is the tell — 'www' running package_info.pl as root:# sudo:  www : PWD=/ ; USER=root ; COMMAND=/usr/local/sf/bin/package_info.pl /var/tmp/license.tmp# And the dropped artifact itself:ls -l /var/tmp/license.tmp

Patch: one hot fix closes both

The good news, such as it is: there is no separate patch to juggle. The per-train hot fix that closes the exploited 20316 closes the 10.0 at the same time. Match your FMC train to the fixed build and apply it.

1. Apply the hot fix for your train from the table above — it closes both CVEs in one shot.
2. Run the zgrep IoC hunt on every FMC before and after patching; if it hits, contact Cisco TAC and treat the box as root-compromised.
3. Take the FMC management interface off the public internet — Cisco explicitly notes that removing internet access shrinks the attack surface.
4. Rotate anything the FMC holds or can reach: management credentials, API tokens, and the trust it has to push policy to your Secure Firewall fleet.
5. If you are on 7.1 or 7.3 with no hot fix, plan the migration to a fixed train now — an unpatched perfect-10 on a management plane is not a backlog item.

What the pairing teaches

Two lessons, and then I want to give credit where it is due. First: do not triage by CVSS alone. The flaw that was actually being exploited here was the 5.3, not the 10.0 — the low number was the live threat and the perfect score was the sleeping one. Second: do not wave away a "not known exploited" 10.0 that shares a fingerprint with an active campaign. A perfect ten on the box that governs your entire firewall fleet is worse than a perfect ten on any single firewall, because from there an attacker rewrites the rules for everything downstream. And the gratitude: to Brandon Sakai at Cisco, who found the 10.0 internally before anyone weaponized it, and to Jimi Sebree at Horizon3.ai, whose work on the 5.3 cousin surfaced the very footprint that ties the two together. The finding is the antagonist here, not the vendor — and the defenders who did the quiet work of finding it are why you get to patch before the story ends badly.

Advisory revisions and scores current as of 2026-08-04