CVE-2026-20316 in Cisco Secure Firewall Management Center

# CVE-2026-20316 in Cisco Secure Firewall Management Center: the static-credentials zero-day CISA pushed to KEV inside 48 hours

Cisco's Product Security Incident Response Team (PSIRT) confirmed on July 29, 2026 that a vulnerability in Cisco Secure Firewall Management Center (FMC) had been actively exploited since earlier that month, with no patch in place at the time. Tracked as **CVE-2026-20316**, the flaw allows an unauthenticated remote attacker to log into the management console of an affected firewall using static credentials baked into the software itself. The case is unusual in two reinforcing ways: the technical severity score (CVSS 5.3) does not anticipate the operational urgency that has been assigned to it, and exploitation was confirmed precisely when Cisco shipped the hotfix — the textbook definition of a zero-day, not a coordinated disclosure in the conventional sense.

A week that started with a partner-channel warning and ended with a federal remediation order

The discovery is credited to **Jimi Sebree, a researcher with Horizon3.ai**, as recorded in the acknowledgements section of Cisco's official advisory, identifier `cisco-sa-fmc-static-cred-BET3Cjh` (internal bug `CSCwt95997`). Cisco published the advisory on July 29, alongside an update to a second critical bulletin — **CVE-2026-20079**, an authentication-bypass flaw rated CVSS 10.0 — which shares several indicators of compromise with the first and can be chained with it to escalate to root. Within hours, on the same day, **CISA** added CVE-2026-20316 to its **Known Exploited Vulnerabilities (KEV)** catalog and set **August 1, 2026** as the remediation deadline for U.S. Federal Civilian Executive Branch (FCEB) agencies, under Binding Operational Directive 26-04. From advisory publication to the federal-sector deadline: 72 hours. That cadence is uncommon and reveals how CISA reads the real-world risk, even when the base score, on paper, looks moderate.

What CVE-2026-20316 actually is

The flaw is classified as **CWE-259: Use of Hard-coded Password**. Operationally, this means Cisco Secure FMC Software ships, inside the image, a low-privilege user whose credentials are known and reusable: any vulnerable instance is, in practice, accessible to that user without the attacker supplying any password of their own. The attack vector is **remote, via the web management interface, with no prior authentication required**, and the direct impact is access to the sensitive information that the low-privilege account can read — which in FMC includes security policies, the inventory of managed devices, detection configurations, event logs, and, depending on the deployment, some of the material operators treat as "internal" and rarely isolate from the management network.

The CVSS 3.1 base score is **5.3 (Medium)**, but Cisco raised the internal **Security Impact Rating (SIR) to High** for a specific reason: the static account opens an entry point that becomes significantly more dangerous when chained with other FMC vulnerabilities. The combination drawing the most attention from security teams, and which multiple independent analyses flag, is **CVE-2026-20316 + CVE-2026-20079**: chained together, they let an attacker move from an unauthenticated login with a low-privilege account to code execution as root on the FMC — the brain that controls firewall policy deployment across the organization. From a static credential to total compromise of the management plane in two steps.

Which products are affected — and which are not

The official advisory is explicit, and the specialist press echoed it with identical readings. **Only Cisco Secure Firewall Management Center (FMC) Software in its on-premises deployment is affected**, across release branches **7.0, 7.2, 7.4, 7.6, 7.7, and 10.0**. For each branch Cisco has published **hotfixes** (not full release upgrades), and the company stresses that there are no workarounds that close the vector entirely: limiting the interface, for example, does not remove the account, only shrinks the exposed surface. Remediation options boil down to installing the branch-appropriate hotfix without delay.

**Explicitly out of scope**: **Cisco Cloud-Delivered FMC** (the SaaS variant), **Firewall Device Manager (FDM)**, **Secure Firewall ASA Software**, **Secure Firewall Threat Defense Software**, and **Security Cloud Control**. That distinction matters in mixed deployments — common among operators that still maintain ASA in some segments — because the urgency to patch FMC should not lead to wrong conclusions about the rest of the portfolio's exposure.

The indicators of compromise Cisco published with the advisory

The advisory accompanies the hotfixes with a **set of indicators of compromise (IoCs)** any administrator can check in minutes from the FMC's expert-mode CLI. Cisco recommends two complementary searches, both against `/var/log/messages`:

1. `cat /var/log/messages | grep license` — to surface suspicious entries associated with the licensing subsystem. 2. `zgrep "package_info.*license" /var/log/messages*` — to cover compressed, rotated logs where the oldest trace sometimes appears.

The marker Cisco considers unambiguous is the presence of the file **`/var/tmp/license.tmp`** on the system, together with log entries in which the `www` process (FMC's internal web server) invokes `package_info.pl` as root. That chain — an unprivileged web process, a package-info utility running as root, and a reference to a `.tmp` file the legitimate system does not create — is the signature PSIRT observed in confirmed intrusions. Hispasec was the first Spanish-language outlet to publish the extended advisory and framed these IoCs as "the first place to look" in any deployment that had been exposed to the Internet or to a remote management network.

Why the official severity does not match the operational urgency

There is an old debate that this case reactivates about the gap between **CVSS** and **SIR** when a vendor decides to escalate the category for reasons the standard does not capture. Cisco explains it in the advisory: with a pure CVSS 5.3, the vulnerability would be Medium severity and rarely make headlines. But the chaining potential with CVE-2026-20079 — and, more broadly, with any other FMC flaw that supports lateral movement or escalation — lifts the effective risk to "High" from the product's perspective. **SecurityWeek** framed it as "low CVSS, real-world high": a reminder that CVSS measures the isolated flaw, not the systemic risk of the deployment. **Bleeping Computer** and **Help Net Security** arrived at the same reading, and all three outlets stressed that CISA's decision to add the CVE to KEV less than 24 hours after advisory publication is the clearest practical proof that, in operational terms, the flaw behaves as critical.

In other words: CVSS tells you how much the entry point hurts; SIR, KEV, and BOD 26-04 tell you how much the whole system is going to hurt. Operating on the first reading and forgetting the other three is, in this case, the difference between a remediation plan for the next maintenance window and a federal incident.

What to do, in priority order

Synthesizing the advisory, the IoCs, and the recommendations across the specialist press, the reasonable response for any operator running FMC on-prem in production has four sequential steps:

1. **Inventory the FMC estate and the release branch of every instance.** This must happen before anything else: a hotfix applied to the wrong branch leaves the vulnerability open with the false impression of remediation. Cisco publishes the exact hotfix file per branch in the advisory; `show version` in expert mode on the FMC confirms the branch in use.

2. **Apply the branch-appropriate hotfix.** There are no full workarounds: rotating the affected account's password partially mitigates, but does not remove the static account baked into the firmware. The hotfix matrix covers 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0; any instance on a release outside those branches is running unsupported and must be migrated before patching.

3. **Hunt for IoCs in logs and the file system.** The two searches against `/var/log/messages` plus the presence of `/var/tmp/license.tmp` are the first triage line. Any hit must trigger full rotation of credentials, keys, and certificates on the FMC, and open an incident to investigate lateral movement from the static account into the rest of the management plane.

4. **Restrict access to the management interface.** Even with the hotfix closing the specific vulnerability, **Bleeping Computer** and **The Hacker News** repeat the same guidance as Cisco itself: the FMC management interface should never be exposed to the public Internet under any reasonable circumstance, not even behind a poorly segmented VPN. Strict ACLs, a dedicated admin VPN, an isolated management network, and, where the topology allows, a jump host with MFA, are the standard the incident makes even harder to argue against.

The CVE-2026-20079 factor: why this zero-day does not come alone

It is important to understand that the CISA alert and the federal urgency do not fully make sense without the twin vulnerability. **CVE-2026-20079**, also patched by Cisco on July 29, is an authentication-bypass flaw rated CVSS 10.0 that enables script execution. The two advisories share the same IoC — the presence of `/var/tmp/license.tmp` — but Cisco has not officially confirmed that the two vulnerabilities are part of the same exploitation path, although researchers who reviewed the advisories believe the overlap is not coincidental. What is confirmed is that the concatenation **CVE-2026-20316 → CVE-2026-20079** hands an attacker a complete path from the Internet to root on the FMC — exactly the kind of chain CISA wants to keep from materializing in federal agencies before August 1.

For operators, the practical reading is direct: **patching only CVE-2026-20316 leaves the other door open**, and vice versa. Both advisories must be remediated in the same maintenance window, ideally the same night, with post-patch IoC verification and the credential, key, and certificate rotation already performed on the clean FMC.

What the offensive side tells us — and what it does not

As of writing, Cisco PSIRT has not disclosed the exact date active exploitation began, nor attribution to a specific actor or group, nor the type of organizations affected. What is known, as **SecurityWeek** and **The Hacker News** reported, is that Cisco became aware of active exploitation **before a patch existed** — the technical definition of a zero-day — and that the disclosure chain (private reporter → PSIRT → advisory → KEV → BOD 26-04) ran in an order and at a pace consistent with a responsible disclosure in flight, not a leak. The absence of attribution at this point is not news: it is Cisco's standard practice when the company does not have firm evidence to share, and it is preferable to a premature attribution.

What any defense team can extract as a practical signal is the usage pattern: **web-based access to the FMC, login with the static account, escalation via CVE-2026-20079 (or an equivalent yet-unpublished flaw), persistence via `package_info.pl` executed by the `www` process and dropped as root, and a `license.tmp` file in `/var/tmp/` as the marker**. Any incident that shows that pattern must, retroactively, be treated as a potential FMC compromise until proven otherwise — and "proven otherwise" requires a forensic baseline of the system, not just the hotfix applied.

The structural lesson: static credentials in management-plane firmware

CVE-2026-20316 is not an exotic flaw. It is exactly the kind of error the industry has been trying to stamp out for years: an account with a known credential embedded in the binary, reachable through the management interface, intended for the software's own internal use. That it shows up in 2026 in a product on the firewall management layer — the piece that coordinates perimeter security across an entire organization — is an uncomfortable reminder. **Cisco** publishes an exhaustive hotfix matrix, PSIRT acted diligently, CISA responded with the speed the case warranted, and the specialist press (SecurityWeek, Bleeping Computer, The Hacker News, Help Net Security, The Cyber Express) covered the story with the rigor expected of them. But the flaw existed, attackers found it before it was patched, and now the cleanup cost — inventory, hotfix, IoC hunt, credential rotation, hardening of management-plane access — falls on operators who for years reasonably assumed that the firewall console was the most watched piece of their infrastructure. That assumption, after this incident, needs to be revisited with the same seriousness with which trust in domain controllers was revisited after Kerberos roasting, or trust in VPNs after the Pulse Secure and Fortinet zero-day waves.

Closing: what cannot wait until Monday

If your organization runs FMC on-prem on any of the 7.0, 7.2, 7.4, 7.6, 7.7, or 10.0 branches, the inventory and the hotfix planning cannot wait for the next change window. The exposure window has been open since July, and the IoCs are simple enough that a first triage takes hours, not days. For FCEB agencies the date is August 1; for everyone else, the date is the next change advisory board — but the CAB's content is the same: patch, hunt IoCs, rotate credentials, and close the management interface off from the Internet. The rest — attribution, public exploit, specific malware — is information that time will clarify, but the potential damage of the flaw is already known and on the table.