```html ``` There Is a Static Password in the Box That Manages Your Cisco Firewalls. You Have Until Saturday.
top of page

There Is a Static Password in the Box That Manages Your Cisco Firewalls. You Have Until Saturday.

  • Writer: Patrick Duggan
    Patrick Duggan
  • 14 minutes ago
  • 7 min read

Cisco published CVE-2026-20316 at 16:22 UTC today. CISA added it to the Known Exploited Vulnerabilities catalog the same afternoon. The federal remediation deadline is August 1 — three days.


It is a static user credential in the web interface of Cisco Secure Firewall Management Center. Not a buffer overflow, not a deserialization gadget, not a parser bug. A password that ships in the product. An unauthenticated remote attacker logs in with a low-privileged account and reads sensitive data off the box that manages your firewall estate.


There is no exploit to write. You log in.


Cisco overrode their own score, and said why



The CVSS base score is 5.3. Medium. Here is what Cisco put in the advisory anyway, and it is the most important sentence published about this bug today:


Cisco has assigned this security advisory a Security Impact Rating of High rather than Medium as the score indicates. The reason is that this vulnerability can be used with other Cisco Secure FMC Software vulnerabilities to elevate privileges.


Read that again. The vendor is telling you the number is wrong, in the same document that contains the number. Not because the scoring was computed incorrectly — because CVSS scores a vulnerability in isolation and this one's value to an attacker is entirely in what it chains to.


We have now watched that exact failure three days running.


Tuesday it was JFrog Artifactory: three medium-severity bugs, none critical, none unauthenticated, every one of them defensibly deferrable on a busy triage queue — which chained into a containment breach at a frontier AI lab and an intrusion into Hugging Face's production database.


This morning it was a matched pair on KEV: Arista VeloCloud Orchestrator at a perfect 10.0, and Fortinet FortiOS at 5.3. The 10.0 gets an attacker in. The 5.3 was a bypass of the patch meant to evict one who was already there.


Tonight it is a 5.3 that Cisco is publicly relabelling as High because it is a ladder rung.


Severity scores rank vulnerabilities. They do not rank your exposure, because they cannot see what else is on the box. Three vendors, three days, same lesson — and this time the vendor said it out loud instead of leaving defenders to work it out.


The management plane is having a week



Count the last eight days on KEV:


July 22 — Check Point SmartConsole, CVE-2026-16232. Authentication bypass, exploited as a zero-day. Rapid7's analysis this week explained the mechanism: SmartConsole accepted an attacker-supplied Secure Internal Communication distinguished name instead of binding identity to the authenticated peer certificate. Full administrator, and the vulnerable Trusted Clients configuration was the default.


July 27 — Arista VeloCloud Orchestrator, CVE-2026-16812. Unauthenticated OS command injection, 10.0, exploited as a zero-day, no special configuration required.


July 29 — Cisco Secure Firewall Management Center, CVE-2026-20316. Static password, no exploitation required at all.


Three different vendors. Three different failure modes — bypass, injection, hardcoded credential. One target class: the console that programs the security devices. Not the firewall. The thing that configures the firewall.


That is not a coincidence and it is not new. It is where the leverage is. Compromise one appliance and you own one appliance. Compromise the management plane and you can rewrite policy across the estate, export the inventory, and read the certificates and credentials it holds for every device it manages.


We counted the exposed ones. There are twenty-six.



Our exposure censuses usually produce an alarming number. This one does the opposite, and the small number is the finding.


Searching Shodan tonight for internet-facing Cisco Firepower/FMC returns 26 hosts worldwide. Narrowing to boxes serving it as an HTTP title gives 12. For comparison, the same instrument returned 31,325 exposed baseboard management controllers yesterday and 11,422 internet-facing Splunk hosts last week.


Twenty-six. That is the entire globally-visible population of the management console for one of the most widely deployed enterprise firewall platforms on earth.


The distribution is more interesting than the total. Thirteen are in the US, five in Hong Kong, three in mainland China, three in Ireland, two in Poland. Fifteen answer on 443 and seven on plain port 80 — an unencrypted firewall management interface is its own separate conversation. Three are answering on 161, which is SNMP, which is a different bug report entirely.


And the concentration is stark: a single US technical-college system accounts for seven of the twenty-six — better than a quarter of the world's exposed FMC population sits inside one education network. Eight more are hosted on Alibaba Cloud across its US and Hong Kong regions. Three belong to a local-government network whose own organisation name in the registry is, without irony, "Public facing services."


We are not publishing the addresses. These are victims, not threats — exposure data never goes into our blocklist, and a census is not a target list.


What the small number actually means



It would be easy to read 26 and relax. That is the wrong read, in both directions.


It does mean this is not a mass internet-exploitation event. There is no botnet-scale population to spray. Anybody writing "millions of firewalls at risk" tonight is guessing.


It also means the risk lives almost entirely where Cisco put it in the advisory: chaining, from a position an attacker already holds. If your FMC is correctly on an internal management segment, a static credential in its web interface is not an internet problem — it is a lateral-movement problem, and it becomes valuable the moment somebody is already inside your network with reachability to that segment. Which is the operating assumption we ask everyone to hold anyway.


So the honest triage is: if you are one of the twenty-six, this is tonight's emergency and the reachability is a bigger finding than the CVE. If you are not, this is a chaining rung on a box that a great many people can reach from inside, and it still beats the deadline.


We have written about this exact product before



On April 1 we published a piece on FMC after CVE-2026-20131 — an unauthenticated deserialization bug that gave remote code execution as root on the same management console. The part worth remembering from that post is not the CVE. It is that when we went looking at the public proof-of-concept code appearing for it, we found a fake: a repository presenting itself as an FMC exploit with a webshell in it. People racing to test whether their management console was vulnerable were being handed a backdoor by the tooling.


We also spent June arguing that Cisco's management tier is the soft spot, when CVE-2026-20262 became the seventh Cisco SD-WAN Manager zero-day in thirteen months.


So: we did not call CVE-2026-20316 early. Nobody did — the CVE is nine hours old as we publish. What we have is four months of documented argument that this specific product category is where Cisco keeps getting hit, and a receipt showing that the last time FMC was on KEV, the exploit ecosystem around it was already poisoned.


Nothing public yet, and that is the whole window



We searched GitHub tonight for proof-of-concept code targeting CVE-2026-20316. Zero repositories. Our own exploit harvester — which watches for public exploit code appearing against known CVEs and has been running every six hours — holds nothing for it either. It does hold five records for the Check Point bug from July 28, including Rapid7's public PoC, and two for the March FMC deserialization flaw.


That gap is the point. Right now the barrier to exploiting this is knowing a password. When somebody publishes the account name, the barrier becomes reading a tweet. Our April post exists because that moment arrived for the last FMC bug and arrived dirty.


You have until Saturday, and probably less than that in practice.


A confession, because it would be cheap not to make it



We are not writing this from a position of superiority about hardcoded credentials.


Earlier this year our own production infrastructure ran for months on a Cloudflare token that was committed to a repository. The mechanism was almost funny: the environment variable name was wrong, so the code silently fell through to a hardcoded fallback, and because the fallback worked nothing ever failed loudly enough to investigate. We only found it by auditing what production was actually using rather than what we believed it was using. The rule we wrote afterwards was to throw rather than fall back, because a credential fallback does not fix a misconfiguration — it hides one.


Cisco's version of that mistake shipped inside a security appliance and reached a federal remediation deadline. Ours reached a git history. The difference is blast radius, not virtue. That is precisely why we will not pretend this is somebody else's category of failure.


What to do tonight



Check your FMC version. The affected range is broad — the 7.0 train from 7.0.0 through 7.0.5, the 7.2 train through 7.2.2, and 7.3.0, with more variants inside each. Get the exact fixed release from the Cisco advisory for your train rather than trusting a summary, including this one.


Then do the thing that actually reduces the surface, which Cisco names in the advisory: if the FMC management interface does not have public internet access, the attack surface associated with this vulnerability is reduced. A management console reachable from the internet is the underlying error here, and it was the underlying error for VeloCloud on Monday and SmartConsole last week. The credential is the news. The reachability is the problem.


While you are in the logs, look for successful low-privilege authentications to the FMC web interface that you cannot account for, from sources that have no business touching it. This bug leaves normal-looking successful logins, not exploitation artifacts. Nothing will look broken.


And treat a low-privileged read as a foothold, not a nuisance. Cisco raised the rating specifically because it chains. Assume the account was used to learn the box, not to sit on it.


The pattern, stated plainly



Nine hours from CVE publication to KEV listing to a three-day federal deadline, on a bug scored 5.3, with the vendor overriding their own severity in the advisory text.


If your patch process sorts by CVSS, this one lands below the noise floor and stays there past the deadline. That is not a process failure by any normal standard — it is what triaging by severity is designed to do. It is also, for the third consecutive day, the wrong answer.


Confidence capped at 95%, as always. The version data, severity rating and deadline are from the CVE record, the Cisco advisory and the KEV catalog; the absence of public exploit code is a point-in-time observation from tonight and will age badly on purpose.





Her name was Renee Nicole Good.


His name was Alex Jeffery Pretti.

 
 
 
bottom of page