Cisco confirms active exploitation of CVE-2026-20079, a CVSS 10.0 auth bypass in Secure FMC

September 9, 2026. Cisco officially confirmed that CVE-2026-20079, a CVSS 10.0 flaw in Secure Firewall Management Center (FMC), is being actively exploited in real attacks. On September 10, 2026, the CISA added it to its KEV catalog, ordering US federal agencies to remediate by September 12, 2026. The uncomfortable detail: a fix has existed since March 2026, and exploitation likely began as early as July. For a CISO, the lesson is not the bug itself — it is how long it took to learn the bug was already in use.

A flaw that hands root to the console that drives the whole perimeter

CVE-2026-20079 is an authentication bypass in Cisco Secure FMC. In practice, an unauthenticated, remote attacker sends crafted HTTP requests to the device’s web interface and gains the ability to run scripts and commands as root. The root cause is an improper system process created at boot time — a design defect, not a misconfiguration an administrator could have avoided.

The severity comes from where the compromise lands. FMC is the centralized management console for an organization’s Cisco firewalls: it is the component that pushes rules, network objects, and security policies down to the Secure Firewalls across the fleet. An attacker who controls FMC with root privileges effectively controls the perimeter — they can read policies, modify rules, open access paths, or simply map the defense architecture before striking elsewhere. It is the worst possible place for an authentication bypass.

The flaw affects Cisco Secure FMC Software and Cisco Security Cloud Control Firewall Management. The cloud-hosted Security Cloud Control service is already patched — the on-premises deployment carries the real exposure. Cisco states there are no workarounds: the only remediation is upgrading.

A management console is a prime target

Centralized management consoles hold a special place in the attack surface. They concentrate privilege — here, the ability to push rules to every firewall in the fleet — while receiving less scrutiny than the devices they drive. Teams harden the firewall and segment the network, yet often leave FMC on a poorly isolated management plane, because it is “just an administration tool”.

That is precisely the calculation an attacker makes. RCE on an edge firewall gives a foothold. RCE on the console that drives every firewall hands over the whole perimeter — plus visibility into the rules in place, so the attacker knows how to move without tripping an alert. The lesson goes beyond Cisco: any security management console must be treated as a higher-value asset than the devices it administers, with segmentation and monitoring to match that privilege.

A timeline that lost months

The story of this vulnerability is almost more instructive than its technical details. Cisco published CVE-2026-20079 in March 2026, saying at the time it had no evidence of exploitation. The flaw was known, the fix was available, and many organizations could reasonably treat it as a routine patch.

Then the evidence piled up. On July 29, 2026, Cisco disclosed a second FMC flaw, CVE-2026-20316 — static credentials for a low-privileged account — stating it had been actively exploited, rated High because it chains with other flaws to escalate privileges. That same day, Cisco updated the CVE-2026-20079 advisory to add the same indicators of compromise as CVE-2026-20316, without confirming exploitation of the former.

Yet the indicators published at that point pointed to an earlier start. Cisco asked administrators to search /var/log/messages for activity tied to /var/tmp/license.tmp, sharing this sample log entry:

Jul 23 16:16:33 firepower sudo: www : PWD=/ ; USER=root ; COMMAND=/usr/local/sf/bin/package_info.pl /var/tmp/license.tmp --lsm

An entry dated July 23, 2026 — weeks before PSIRT said it learned of the exploitation in August. The reasonable conclusion is that CVE-2026-20079 and CVE-2026-20316 were likely exploited together in the same campaigns, with the same hot fixes covering both.

This gap between disclosure and confirmation of exploitation is the core problem. An organization that patched in March could have closed the ticket, even if its FMC had already been compromised in July — a patch prevents future exploitation, but it does not clean a device that was already hit.

Detecting a past compromise

Cisco is explicit on this point: installing the fixes prevents future exploitation but does not remediate devices already compromised. So the first action is not merely to patch — it is to hunt the indicators.

The search focuses on the filesystem and system logs:

• Look for /var/tmp/license.tmp and any command invoking package_info.pl with that path, across /var/log/messages and the sudo logs;
• Find the telltale log line — the entry containing USER=root and package_info.pl /var/tmp/license.tmp — which signals probable exploitation;
• Correlate with CVE-2026-20316 — the same indicators cover both flaws, and their joint presence suggests a single campaign.

Because Cisco shares the indicators across the two flaws, a device carrying them was likely hit by the same campaign — treat a hit on one as evidence worth checking against the other.

If these indicators are found, Cisco asks customers to contact the TAC (Technical Assistance Center). The operational guidance is unambiguous: a device carrying these traces must be treated as compromised, not as “pending a patch”.

What network teams should do

The order of operations matters, and it inverts the usual patch logic: here, detection precedes the update itself.

• Inventory your on-premises FMC deployments — every self-hosted Secure Firewall Management Center, including secondary and lab instances, is inside the risk perimeter;
• Hunt the indicators before concluding — run the search for /var/tmp/license.tmp and the package_info.pl entry before treating a device as clean;
• Apply the recommended upgrade — there is no workaround, only the latest release closes the hole;
• Treat any device with indicators as compromised — rebuild it from clean media, do not settle for patching it;
• Consider Security Cloud Control — the cloud service is already patched and moves this risk off your infrastructure.

The CISA calendar sets the pace: federal agencies must remediate by September 12, 2026. For the private sector it is a useful reference point — three days is the window beyond which an exposed FMC with this flaw becomes a statistical anomaly in incident reports.

Verdict

CVE-2026-20079 is not one more firewall firmware bug: it is a CVSS 10.0 authentication bypass on the console that drives the entire perimeter, left exploitable and exploited for months before public confirmation followed. The lasting lesson is the lag between disclosure and exploitation detection — a March patch does not guarantee a device was healthy in July.

If you run on-premises FMC deployments, patch immediately and hunt for compromise indicators before declaring a device healthy. The presence of the package_info.pl /var/tmp/license.tmp entry should trigger a rebuild, not a simple post-update restart.

If you cannot patch right away, isolate the FMC from any interface reachable from the internet or a partner network — but know that the flaw is already exploited in the wild, and that isolation reduces exposure without fixing anything. The only real closure is an upgrade paired with a compromise check.

References

• BleepingComputer — Cisco confirms CVE-2026-20079 Secure FMC flaw exploited in attacks, September 9, 2026
• Cisco Security Advisory — cisco-sa-onprem-fmc-authbypass (CVE-2026-20079)
• Cisco Security Advisory — Cisco Secure FMC Static Credentials (CVE-2026-20316)
• CISA — Known Exploited Vulnerabilities Catalog