CRITICAL: Cisco Firewall Management Center CVE-2026-20079 Under Active Attack

There is a particular flavor of bad news in this industry, the kind where the appliance you bought to protect everything else turns out to be the softest thing on the network. Cisco's Secure Firewall Management Center is living that story this week.

On September 9, CISA added CVE-2026-20079 to the Known Exploited Vulnerabilities catalog and gave federal civilian agencies until September 12 to remediate it. That is a three day clock. CISA does not hand out 72 hour deadlines because it enjoys the paperwork. It does that when something is being turned against real targets and the blast radius is genuinely ugly. The flaw carries a CVSS score of 10.0, the actual ceiling, and it lets an unauthenticated attacker on the far end of an HTTP request walk away with root on the box that manages your entire firewall estate.

Read that last part again, because it is the part that matters more than the number. FMC is not a firewall. FMC is the thing that tells your firewalls what to do. Access control policy, NAT rules, VPN configuration, intrusion policy, logging destinations, the works. An attacker with root on Firewall Management Center does not need to find a gap in your perimeter. They own the machine that decides where the gaps are, and they can quietly write themselves one that never shows up in a change ticket.

What actually broke

The root cause is almost embarrassingly mundane, which is usually how the 10.0s go. When an FMC appliance boots, a startup routine creates a partial session for an internal account called csm_processes and drops it into the sfsnort.sessions database. That session is not built with a randomly generated identifier the way a real user session would be. It uses a static, predictable session ID. If a human logs into the appliance after boot, normal session handling cleans the stale entry up and the problem evaporates. If nobody logs in, the half finished session just sits there, valid, waiting.

An attacker who knows the static value can present it as a cookie and slip past the initial authentication check. From there the chain gets worse in a hurry. VulnCheck's analysis of the bug walks through the rest of it, and it reads like a tour of everything you hope is not in your management plane. The attacker upgrades that partial session by authenticating with hardcoded machine credentials, the account report with the password snortrules, which promotes the session into something that can call the wider CGI interface and yields the sf_action_id CSRF token needed to keep going. With that token in hand, the validateLicense endpoint in sajaxintf.cgi becomes an arbitrary file write, and a shell script payload gets dropped at /var/tmp/license.tmp using JSON Unicode escaping to smuggle the contents through. Then a call to the upgradeReadinessCall function in pjb.cgi picks that file up and treats it as a MAKESELF installation script. The system dutifully executes it as root.

No memory corruption, no exploit mitigation to defeat, no timing window measured in microseconds. Just a predictable session ID, a hardcoded password sitting in the firmware, and two CGI endpoints that trust each other more than they should. The CVSS vector tells the same story in shorthand, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Network reachable, low complexity, no privileges, no user interaction, and a scope change because the web application ends up executing code as the underlying operating system's most privileged account. That scope change is exactly why this lands on 10.0 instead of 9.8.

There is one wrinkle that cuts both ways. The vulnerable csm_processes session only persists while nobody has authenticated to the appliance since it came up. Log into the dashboard, run a cloud managed session, or let the periodic authentication cleanup do its job, and the stale session disappears. In theory that narrows the exploitable window to the period shortly after a reboot. In practice it means the appliances most likely to be sitting exposed are the ones nobody touches, the FMC in the branch office that was stood up three years ago and has been humming along unattended ever since. Those are also, reliably, the ones running the oldest software. The bug is picky about its targets in a way that happens to select for neglect.

It also means patching deserves a little care. Applying the fix involves a reboot, and a reboot recreates the exact conditions the attack needs on an unpatched build. Patch fully, verify the version afterward, and do not leave a half upgraded appliance reachable from anywhere untrusted in the meantime.

Who is exposed

CVE-2026-20079 affects on premises Cisco Secure Firewall Management Center Software across versions 6.4.0.13 through 10.0.1, which is a range wide enough to cover essentially anyone who has not patched since the spring. CISA's catalog entry names both FMC Software and Cisco Security Cloud Control Firewall Management, so do not assume a cloud flavored deployment automatically walks free. Check your specific deployment against Cisco's advisory rather than against a blog summary, including this one. Cisco ASA and FTD devices themselves are not the target here. The management layer is.

It does not travel alone, either. Cisco disclosed a companion bug at the same time, CVE-2026-20131, an insecure deserialization of Java objects that also reaches arbitrary code execution as root and also scores 10.0. That one is not in KEV yet. Given that these two shipped in the same advisory cycle and affect nearly the same version range, treating them as a single patch event is the sane move.

The uncomfortable detail is the timeline. This is not a fresh zero day that landed on Cisco overnight. CVE-2026-20079 was published back on March 4, 2026, patches have been available since then, and proof of concept code has been sitting on GitHub in public view. Attackers had six months to read the same writeups defenders had, and the KEV listing on September 9 is simply the moment somebody confirmed they finally bothered. That gap between patch availability and patch application is where most real breaches actually live, and it is worth remembering the next time a critical advisory gets triaged into next quarter's maintenance window.

Cisco was not alone on the list either. The same KEV batch brought in CVE-2026-19490, an authentication bypass in Citrix NetScaler ADC and NetScaler Gateway rated 9.3 when the appliance is configured as a AAA virtual server or a Gateway, along with CVE-2025-25249, a heap based buffer overflow in Fortinet FortiOS, FortiSwitchManager, and FortiSASE at 7.3. All three share the September 12 deadline. All three are edge and management infrastructure. If you are keeping score at home, the pattern for 2026 remains what it has been for the past several years, which is that attackers have almost entirely stopped kicking the front door and now go straight for the security appliances bolted to the frame.

What to do about it

Patch, obviously, and do it before the weekend rather than after it. Confirm the running version rather than trusting the inventory record, because management appliances have a habit of drifting from whatever the CMDB believes. Cisco has published fixed releases and there are no workarounds for this one, so there is no clever configuration change that buys you time.

While the patch window is open, get the FMC web interface off any network segment it has no business being on. Management planes should be reachable from a management VLAN or a jump host and nothing else. A CVSS 10.0 preauth bug is dramatically less interesting to an attacker who cannot route to port 443 on the appliance in the first place.

For hunting, the exploit chain leaves reasonably distinctive tracks. Look for the presence or recent creation of /var/tmp/license.tmp and for unexpected files written into web accessible directories. In web server logs, requests to sajaxintf.cgi invoking validateLicense and requests to pjb.cgi invoking upgradeReadinessCall, particularly in sequence and particularly from an external source address, are worth an immediate look. Authentication events for the internal report account from anything other than a local process deserve the same scrutiny, as does any session activity tied to the csm_processes identifier arriving over the network. Beyond the appliance itself, audit your firewall policy history for changes nobody claims. Root on FMC means policy changes are trivially available to an attacker, and a quietly inserted allow rule is a far better prize than a noisy shell.

If you find any of that, treat the appliance as fully compromised rather than as something you can clean. Root on the management plane means credentials, certificates, and every policy secret on the box should be considered attacker owned, and rebuilding from known good media with rotated secrets is the only honest recovery path.

MSP Angle: Every client running an on premises FMC just got handed a concrete, CISA dated reason to fund the vulnerability management program they have been deferring, and a three day federal deadline makes a far better prospecting hook than a generic patching pitch ever will. Run a quick external exposure sweep across your book of business for internet reachable Cisco, Citrix, and Fortinet management interfaces, then lead the conversation with what you found rather than with a service brochure. The upsell that actually lands here is continuous edge and management plane monitoring, because the six month gap between Cisco's March patch and September's exploitation is the exact interval a managed patching retainer exists to close.