The Cisco Firewall Console Shipped With a Password Baked In: CVE-2026-20316 Hands Attackers a Foothold Straight Into Your FMC

Every year the industry rediscovers the same uncomfortable fact. A security appliance is still just software written by humans, and the humans sometimes leave shortcuts in it. This week we got another example we cannot stop turning over. Cisco confirmed that its Secure Firewall Management Center, the box that runs your entire on-prem Cisco firewall estate, has been shipping with a hardcoded low-privilege account any attacker on the network can log in as, and someone has been quietly using it since at least early July. The account is baked into the web interface. There is no environment variable, no default-password prompt on first boot, and nothing in your existing FMC audit UI screaming that a stranger has walked in.

What made us pay attention is not that a hardcoded password made it to production, because that story is old. What made us pay attention is what the low-privilege account gives you when you combine it with a diagnostic utility Cisco built into the appliance for legitimate support reasons. A CVSS 5.3 login becomes an entire root shell on the box that manages your perimeter, and the observable evidence sits in a log file that most SOCs never look at.

The hardcoded account that lived inside the firewall console

CVE-2026-20316 is the CVE Cisco published on July 29 in the advisory it tagged cisco-sa-fmc-static-cred. The bug is exactly what it says on the tin, a set of static credentials for a low-privilege user account compiled into the FMC web interface. Anyone who can reach the FMC UI on TCP/443, which historically means anyone the network operator has trusted to look at the login page, can present those credentials and get an authenticated session against the appliance. Cisco lists the CVSS v3 base score at 5.3 because the account itself is low-privilege, then in the same breath escalates the severity to High because the account is chainable to worse.

The vulnerability class is CWE-259, hardcoded password, cataloged with all the usual root cause discussion. Leftover test creds, an internal debug account, a support hook that should have been feature-flagged off. Neither Cisco nor Jimi Sebree of Horizon3.ai, whose disclosure led to the fix, has published the account name or how it slipped in. Treat the exact string as a defender's problem to hunt for rather than a value to type into a login form.

The scope Cisco lists is only the on-prem Secure FMC Software. Cloud-Delivered FMC, Firewall Device Manager, Secure Firewall ASA Software, Secure Firewall Threat Defense Software, and Security Cloud Control are all explicitly out of scope, which is the one small mercy in this advisory. Cisco's SaaS management plane does not carry this account. If you have not moved to Cloud-Delivered FMC, you are the target set. runZero's asset guidance is a reasonable starting point if you are not sure how many FMC instances you actually run and where they sit.

From a known password to a rooted management appliance

By itself, the low-privilege session cannot do much. It can read the sensitive data the account is authorized to see, which given that this is the box that manages firewalls means device configuration, policy detail, and potentially credential material the account can view through the UI. That alone is bad, and worth patching for on its own. But the reason CISA moved CVE-2026-20316 into the Known Exploited Vulnerabilities catalog the same day the advisory dropped, with a federal patching deadline of August 1, is what happens next.

Once inside, the attacker has a working session running under the FMC web tier. That tier needs elevated access to a set of internal diagnostic utilities so support tooling can build packages, dump license state, and pull configuration blobs. One of those internal utilities is /usr/local/sf/bin/package_info.pl, a Perl script the web tier is able to invoke as root through a suid wrapper. When called with /var/tmp/license.tmp --lsm, it operates on an attacker-controllable file with root authority. The exploited-in-the-wild pattern documented by SOC Prime and cited in Cisco's own IoC guidance is exactly that invocation appearing in /var/log/messages, with a package_info.pl /var/tmp/license.tmp --lsm line executed by the FMC web process and no legitimate operator having pressed a button to justify it.

Cisco explicitly warns that CVE-2026-20316 becomes far more dangerous when chained with a second FMC bug. The public candidate for the second half of that chain is CVE-2026-20079, a CVSS 10.0 authentication bypass in the FMC web interface that VulnCheck and others have analyzed as leading to script execution with root, discovered by the same Horizon3 researcher. Whether the observed intrusions used exactly that combination or a different privilege-escalation primitive, the shape is the same. A hardcoded account gets you into the web tier, and the web tier can already talk to root.

Why "nothing weird in the firewall logs" means nothing here

Here is the thing that keeps a blue team up at night about this specific bug. The FMC is not itself the firewall, it is the box that tells the firewall what to do. Everything a SOC has instrumented, whether that is inline TLS inspection on the perimeter, egress rules, Threat Defense signatures, ASA syslog, or VPN telemetry, is running on the firewalls FMC manages, not on FMC itself. If somebody logs in to FMC as a static account and quietly nudges policy, the appliances downstream will faithfully deploy whatever their manager tells them to. The logs those firewalls emit will read like normal admin activity, because from their perspective it is.

The web logs on FMC itself are the interesting corpus, and most SOCs are not ingesting them. Even where they are, an authenticated session over HTTPS from an internal jump box looks a lot like an authenticated session over HTTPS from an attacker who ran curl from a compromised endpoint on the same subnet. The tell is not the login, the tell is what the session does next.

That is why the specific IoC Cisco published points at /var/log/messages rather than the FMC audit UI or the web access log. The privileged utility runs at the operating system layer, gets logged there, and shows up nowhere else. If your SOC pipeline treats FMC as a network device you configure rather than as a Linux host you monitor, the hardcoded-account session and the ensuing root shell will both slide past.

The forensic breadcrumb Cisco is telling you to grep for

Cisco's own remediation guidance is unusually specific about what to look for on the appliance. Log in to the FMC in expert mode and run cat /var/log/messages | grep license. If any resulting line contains /var/tmp/license.tmp, the invocation of package_info.pl on that attacker-writable path is the indicator that CVE-2026-20316 has been exercised on your appliance. Treat any host that shows this pattern as compromised, not merely vulnerable, and start incident response accordingly.

Around the appliance, the hunts to run in your SIEM look like this. On the network layer, look for authenticated FMC web sessions from source addresses that are not in your operations-team allowlist. An FMC reachable from a general-user VLAN, from a DMZ segment, or from any interface that faces beyond your management network is exposed by default here. On the host layer, if you have any EDR or auditd telemetry from the FMC itself, look for package_info.pl executions where the parent process is the web tier and the arguments include /var/tmp/license.tmp or another /var/tmp/*.tmp path. In MITRE ATT&CK terms, you are hunting for T1078.001 (Valid Accounts: Default Accounts) as the initial access, T1190 (Exploit Public-Facing Application) on the FMC surface, and T1068 (Exploitation for Privilege Escalation) once the chained bug turns the session into root. The Cisco audit log will show a successful login from the static account with no matching human on the other side; if you can dump the account list from the FMC and diff it against your provisioning source of truth, the leftover account is the thing to look for.

The hotfix, the rotation, and the closing test

Cisco has shipped hotfixes for FMC 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. The named artifacts include Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar for 7.4, Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar for 7.6, and Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar for 7.7, per Cisco's advisory. Install the hotfix or move to a later fixed release; the vendor is explicit that no configuration-level workaround exists.

Then rotate. Cisco's own guidance, echoed by Security Affairs' CISA writeup, is that installing the hotfix does not invalidate anything the attacker may have already read while the door was open. Cycle every credential, API key, and certificate the appliance touches. That includes the accounts FMC uses to talk to your managed firewalls, the smart licensing tokens, any RADIUS or TACACS shared secrets, and any privileged accounts stored for automation. If the IoC in /var/log/messages fires on any host, expand the rotation to anything those firewalls could touch downstream and treat the appliance as if you were rebuilding from a known-good image.

The last step, and the one most upgrade tickets skip, is proving the fix actually held. After the hotfix, re-execute the log-grep IoC against the patched host and confirm no fresh matches accumulate. Confirm the previously exposed account no longer authenticates. Restrict FMC management interface access to a trusted administrator VLAN so that even if a future hardcoded-account bug ships, the login page is not reachable from the general estate.

This is the loop we spend our lives on at BlueTeamAutomation: patch, hunt, rotate, then re-emulate the exact primitive to prove it no longer works. BASzy runs that validation continuously against your management-plane appliances so a KEV-listed vulnerability turns into an evidenced closure rather than a rushed weekend and a hopeful email.