Cisco FMC CVE-2026-20316: the CVSS 5.3 that CISA put in KEV

On 29 July 2026 Cisco published advisory cisco-sa-fmc-static-cred-BET3Cjh. It describes CVE-2026-20316, a static credential built into Cisco Secure Firewall Management Center, with a CVSS v3.1 base score of 5.3. On the same day CISA added it to the Known Exploited Vulnerabilities catalog. Cisco's PSIRT statement is one sentence long: "In July 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability." There is no workaround. The score says routine; the exploitation status says now. This article is about why those two signals disagree, and what to do about the disagreement in your own patch queue.

What CVE-2026-20316 actually is

The vulnerability is static credentials for a low-privilege account compiled into Secure FMC Software. An unauthenticated remote attacker uses them to log in and read the data that account can see. No memory corruption, no exploit payload, no crash — a valid username and a valid password that ship with the product.

Affected trains are 7.0, 7.2, 7.4, 7.6, 7.7 and 10.0. Cisco's advisory is explicit that "there are no workarounds that address this vulnerability" — the only remediation is a hotfix. The flaw was reported by Jimi Sebree of Horizon3.ai, and BleepingComputer reports that Cisco has not disclosed the threat actor, the timeline, or the victims.

FMC is not a firewall. It is the on-premises console that owns the firewall estate: access policy, NAT, VPN configuration, device registration, and the event stream for every Secure Firewall / FTD sensor registered to it.

Why the Cisco FMC static credential scores only 5.3

Read the vector Cisco published:

Metric	Value	What it asserts
AV:N	Network	Reachable over the network
AC:L	Low	No special conditions
PR:N	None	No privileges needed
UI:N	None	No user interaction
S:U	Unchanged	Impact stays in the vulnerable component
C:L	Low	Some confidentiality loss
I:N / A:N	None	No integrity or availability impact

Everything on the access side is maximally bad — network, no auth, no interaction — and the score is still 5.3, because the impact side is a single C:L. CVSS base scoring measures one vulnerability in isolation and deliberately excludes what an attacker can reach by combining it with a second one. That is a documented design decision, not a bug in the standard. The problem is what happens downstream: the base score is the number that gets exported into the ticketing system, and most enterprise patch SLAs are keyed to it.

• Critical / 9.0+ — emergency change, days.
• High / 7.0–8.9 — next patch window, weeks.
• Medium / 4.0–6.9 — quarterly cycle, up to 90 days.
• Low — best effort, often never on an appliance.

CVE-2026-20316 lands in row three. Cisco's own Security Impact Rating is High, precisely because — in Cisco's words — the access can be combined with other FMC vulnerabilities to escalate privileges. That correction is in the advisory prose, not in the number, and prose does not survive the CSV export into a vulnerability management platform.

Change board: It's a 5.3, read-only, and the box isn't even public-facing for most of the estate. Why is this an out-of-cycle change? Security: Because the vendor's own indicator of compromise for it is a file that gets executed as root.

The chain was public four months before the CVE

In March 2026 Cisco patched two critical FMC flaws, CVE-2026-20079 (CVSS 10.0, authentication bypass to root) and CVE-2026-20131. VulnCheck published a full technical analysis of the first on 26 March. The chain it documents has four steps:

Step	Mechanism
1	FMC creates a csm_processes session at boot with a static session ID instead of a UUID; it persists in the database
2	The session is upgraded by authenticating with hardcoded machine credentials (report:snortrules), yielding a valid CSRF token
3	The validateLicense endpoint is used to write a Makeself shell script to /var/tmp/license.tmp
4	upgradeReadinessCall processes that file and executes it as root

Now read the detection guidance Cisco published in July for the "5.3, read-only" bug. From the advisory: run cat /var/log/messages | grep license in expert mode; exploitation is indicated if the output contains /var/tmp/license.tmp.

The indicator of compromise for a vulnerability scored as low-impact confidentiality loss is the artefact of a root code execution step that a public write-up described four months earlier. Cisco acknowledged CVE-2026-20079 exists but declined to explain the relationship between the two, so the honest statement is the narrow one: the credential half of a known FMC root chain got its own CVE in July, got a medium score, and was already being used in the wild by the time it was published.

The internet-facing population is small — VulnCheck put it at roughly 300 FMC instances on Censys and 600–700 on FOFA in March 2026. That is not a mass-exploitation number. It is a target list. Each of those hosts speaks for a fleet.

The management plane is the target, not the firewall

An attacker who owns FMC does not need a firewall exploit. They get the supported, logged, expected configuration-push channel to every registered sensor. From the console you can read the full policy set (which is a map of the network and its trust relationships), add a rule, change a NAT translation, pull VPN configuration, or register a device. None of that is anomalous traffic — it is the management plane doing its job.

This is the same shape as the incidents we have covered on other estate controllers: the VeloCloud SD-WAN Orchestrator zero-day and Cisco Unified CM CVE-2026-20230. The pattern is stable enough to plan against: the controller is a lower-scored, less-monitored, less-frequently-patched appliance than the things it controls, and it has a legitimate authenticated path to all of them.

What KEV and BOD 26-04 changed about the patch queue

CISA issued BOD 26-04, Prioritizing Security Updates Based on Risk, on 10 June 2026, replacing the flat 14-day KEV remediation clock of BOD 22-01 with a risk-based decision model. Deadlines now turn on whether the asset is publicly accessible and on the attacker value of the vulnerability, with the shortest tier measured in days. Federal agency policies must support the model by 7 August 2026, with evaluation and remediation to the new timelines starting 7 December 2026 (Tenable's FAQ is a good plain-language read on the four-variable model).

CVE-2026-20316 is the case the directive was written for. Publicly reachable on a subset of deployments, confirmed exploited, no workaround, and a base score that a CVSS-keyed SLA would file in the 90-day bucket. If you are outside US federal scope, the directive is still the cleanest available template for the argument you need to make internally: exploitation status outranks severity score, and KEV membership is the trigger, not the CVSS column.

Remediation

1. Am I affected?

Any on-premises Secure FMC / Firepower Management Center on 7.0, 7.2, 7.4, 7.6, 7.7 or 10.0 without the July hotfix. Cloud-delivered FMC, ASA and FTD sensors themselves were not affected by the March FMC pair; confirm your own deployment model against Cisco's advisory rather than assuming.

• In the FMC UI: Help → About for the exact version and any applied hotfix.
• From the CLI: show version, then confirm the hotfix identifier is present.
• On the network: enumerate HTTPS management interfaces on your appliance VLANs and fingerprint the FMC login page. Do not rely on your CMDB — appliances acquired with a business unit are the ones that are missing from it.

2. Patch — exact fixed versions

Cisco ships this as a hotfix per train (verbatim from the advisory):

Train	Hotfix
7.0	Cisco_Firepower_Mgmt_Center_Hotfix_GB-7.0.9.1-3.sh.REL.tar
7.2	Cisco_Secure_FW_Mgmt_Center_Hotfix_HL-7.2.11.1-4.sh.REL.tar
7.4	Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar
7.6	Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar
7.7	Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar
10.0	Cisco_Secure_FW_Mgmt_Center_Hotfix_P-10.0.1.1-2.sh.REL.tar

3. Can't patch now? Compensating controls

There is no vendor workaround, so everything here reduces reachability rather than removing the credential:

• Restrict the FMC HTTPS management interface to a management VLAN with an explicit allow-list; deny from user and server segments by default.
• Terminate administrative access on a hardened jump host with MFA. Nothing else should be able to reach port 443 on the FMC.
• Enforce client-certificate (mTLS) authentication in front of the web interface where your reverse proxy supports it.
• Remove any inbound NAT or public DNS record pointing at an FMC. Given the Censys/FOFA counts, this is the single highest-yield control on the list.
• Alert on every successful authentication to FMC from a source outside the jump-host range.

4. Hunt for compromise

Vendor indicator first, then the surrounding artefacts:

# Cisco's published IOC (expert mode). A hit on /var/tmp/license.tmp indicates exploitation.
cat /var/log/messages | grep license

# Files staged in the licensing path
ls -la /var/tmp/

# Processes running as root that shouldn't be
ps aux | grep -E 'root|csm_processes'

Then correlate on the network and in the appliance's own logs:

• HTTPS access-log entries hitting licensing and upgrade endpoints from a source that is not your management range.
• Authentication events for built-in service accounts — the whole point of a static credential is that the login succeeds, so absence of failures is not absence of compromise.
• Sensor-side change events: unexpected policy deployments, new device registrations, ACL or NAT edits with no matching change ticket.
• Outbound sessions from the FMC itself to destinations that are not Cisco update infrastructure or your syslog collector.

MITRE ATT&CK mapping for this activity:

Technique	ID
Exploit Public-Facing Application	T1190
Valid Accounts: Default Accounts	T1078.001
Unsecured Credentials	T1552
Data from Configuration Repository: Network Device Configuration Dump	T1602.002
Data from Local System	T1005

5. Eradicate and verify

If the IOC hits, treat the entire managed estate as credential-compromised, not just the console. Rotation scope:

• FMC local and remote admin accounts, and any SSO integration secrets.
• Device registration keys — re-register sensors if you cannot establish when the compromise began.
• VPN pre-shared keys and remote-access profiles held in FMC configuration.
• RADIUS / TACACS+ shared secrets configured on the appliance.
• Certificates and trust stores used by the FMC-to-sensor channel.

Verify after patching, in this order: confirm the hotfix is applied and the appliance rebooted; re-run the license grep and confirm no new hits; attempt the rotated credentials' predecessors and confirm they fail; diff the deployed policy on every sensor against your last known-good export. A management-plane compromise is only closed when the policy set has been re-validated, not when the console is patched.

Where Zero Hunt fits

A static credential is invisible to the tools most organisations point at this problem. A version-based scanner reports what banner it saw; it cannot tell you whether report:snortrules — or its successor on your train — actually authenticates on your appliance. A CVSS-keyed patch queue files the finding at 5.3 and moves on. The only way to know is to attempt the login and record what happened.

That is what Zero Hunt's Credential agent does, as one of ten coordinated agents in the AI generative pentest swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic and Report under an AI Controller. Recon fingerprints the management interfaces on the appliance VLAN that are missing from the CMDB; Credential tests built-in and default accounts against the live service, drawing on the SecLists corpus of 330+ default credential pairs and on 21 continuously synced threat-intelligence sources including CISA KEV, EPSS, MITRE ATT&CK and ExploitDB; Post-Exploit and Pivot establish what that low-privilege foothold actually reaches — which, on a management plane, is the answer that matters. Exploits are generated per target by a local LLM and backtested in the AI Gym against Vulhub and Vulhub-Bench before any skill runs against production, and every execution happens in an ephemeral container so the appliance under test is exercised, not the platform. Because campaigns are scheduled and change-triggered, a new appliance appearing on the perimeter starts a full campaign within the hour — which is the practical difference between finding this in a validation run and finding it in Cisco's IOC grep.

The scoring argument has a compliance half as well. Zero Hunt maps every finding across 32 frameworks — NIS2, DORA including the TLPT RTS, ISO 27001, SOC 2, NIST CSF and the rest — with severity-weighted scoring driven by exploitation evidence rather than by the base CVSS column, and signs each finding with ECDSA at write time. When an auditor asks why a 5.3 was treated as an emergency change, the Trust Center bundle contains the KEV evidence, the validation attempt, the timestamp and the signature, in one export. That is a materially easier conversation than reconstructing it from ticket comments six months later. If you want to see what that looks like against your own estate, get in touch.