Cisco FMC: patching closes the door, but nobody gives you back your network blueprint

On 9 September, Cisco Talos published that it is seeing real-world exploitation of two flaws in Secure Firewall Management Center, the box from which many companies administer all their firewalls at once. So far, an ordinary Wednesday. What is not ordinary is the count: three separate attacker clusters, unrelated to each other, inside the same box. One left a web shell. Another, an advanced persistent threat actor, dropped two scripts to harvest the configurations of the managed firewalls. The third ended up deploying ransomware. And there sits the part almost nobody is discussing: of everything they took, there is a portion the patch does not fix, because it cannot be rotated.

What there is, without decoration

These are two distinct flaws and it is worth keeping them apart. CVE-2026-20079 is an authentication bypass in the FMC web interface, rated CVSS 10.0: a remote, unauthenticated attacker runs commands and ends up as root on the underlying operating system. The origin Cisco describes is a system process improperly created at boot time. CVE-2026-20316 is something else: static credentials — hard-coded into the product — for a low-privileged account, rated CVSS 5.3. It does not give root; it gives you in.

Cisco already has hotfixes for both. The full hardening release, which also carries other fixes, is announced for the week of 16 September, and Talos explicitly asks you not to wait for it: apply the hotfixes now. CISA added the 10.0 to its known exploited vulnerabilities catalogue on 9 September, with a 12 September remediation date for US federal agencies. The 5.3 was already there: added on 29 July, due 1 August, and flagged as used in ransomware campaigns. Six weeks before Talos published anything. Those dates do not bind you; the clock they mark does. And there is no workaround for the bypass: the only thing that lowers the risk while you patch is making sure the management interface cannot be reached from the internet. Which, incidentally, is where it should have been for years.

Three clusters, three different hauls

Talos separates the activity into three clusters, and they are worth looking at one by one because each teaches something different:

• UAT-12197 exploited the 10.0, dropped a JSP web shell into a Tomcat directory and planted a malicious JAR file to query the compromised system's internal databases and pull authentication data and credentials out of them.
• UAT-11823, which Talos describes as an advanced persistent threat actor, used both flaws. It left a Netcat reverse shell, deployed two bash scripts to harvest managed-device configurations and ended up installing Cyclops Blink, an ELF implant with DNS over HTTPS, file administration and credential harvesting.
• UAT-11988 came in through the static credentials — the 5.3 — and ran extensive reconnaissance, domain enumeration and credential theft before deploying Qilin ransomware. To move inward it stood up a Python SOCKS5 proxy and a reverse SSH tunnel out of the FMC itself, forwarding LDAP, LDAPS, Kerberos, SMB, NetBIOS and WinRM; on the endpoints it used impacket, Invoke-TheHash and custom-built utilities for killing antivirus. The management box turned into a springboard into Active Directory.

The persistence is the part we liked most, precisely because it is so unspectacular. The appliance's license.tmp file was modified to act as a Makeself package — a self-extracting archive — which the package_info.pl utility executes as root during the installation process. There are also scripts planted in /etc/init.d/. Nothing exotic: a file with a boring name, in a place nobody looks, executed with full privileges by the product itself because that is what it is for.

Of the three things they took, two rotate and one does not

Line them up. Credentials: they rotate. A bad afternoon, a full day if the estate is large, but it gets done and it is over. An encrypted domain: it gets restored. It hurts, it costs money and nights, but it has a procedure and it has an end. The configurations of the managed devices: they do not rotate. There is no button. There is no command. There is no vendor to call.

And they do not rotate because they are not a secret: they are a description. Your firewall configuration is your network blueprint. It says which segments exist and what you call them internally. It says what talks to what and over which port. It says where your VPN endpoints are and which companies sit at the other end. It says what each NAT rule publishes. And above all it lists your exceptions: that "allow any to this host" rule somebody added "temporarily" in 2019 because an old application could not cope with anything finer, and which is still there because removing it is frightening.

Somebody holding that file no longer needs to scan your network. And that matters more than it looks, because scanning is the noisy phase: it is what fires alerts, what leaves traces in the flows, what buys you time to react. Whoever arrives with the blueprint under their arm skips exactly the part of the attack where you had some chance of noticing. They turn up straight where the good stuff is, and it looks like legitimate traffic because it travels exactly along the path you yourself wrote down as allowed.

And that file does not expire when you patch. The patch closes the door they came through. The copy that already left stays valid tomorrow, in March, and on the day you change maintenance provider. We wrote the first half of this idea when FortiOS left behind a symlink that survived the upgrade: patching is not cleaning. This is the second half, and it is worse, because cleaning can at least be done. Un-knowing cannot.

The short list

Write it once and you have it for good. In nearly every company we have seen, it fits on half a page:

• Firewall, router and load balancer configurations. And their backups, which usually live on a shared folder with looser permissions than they deserve.
• The inventory: NetBox, or the spreadsheet that stands in for NetBox. It is the readable version of the same blueprint.
• Network diagrams and architecture documents, with hostnames and addresses inside. Usually on somebody's drive.
• Internal DNS zones. The cheapest map there is to read: it gives you names, functions and, through the names, priorities.
• The infrastructure-as-code repository. It holds not only what exists, but why it is like that and what was tried before.
• The people directory: names, job titles, who reports to whom, extensions. It is what makes a call to the help desk sound plausible.

Of all that, whatever passwords appear inside get rotated, full stop. The rest does not. That is where decisions have to be made, and deciding costs more than patching, which is exactly why almost nobody does it.

The box that protects your network is the one you cannot look inside

Go back to the Talos indicators and look at what they are: a JSP in a Tomcat directory, a license.tmp that is really an installer, scripts in /etc/init.d/. All of that is findable if you have access to the underlying operating system. On an appliance, usually, you do not: you have a menu-driven console, and that is by design, because the vendor rests its support model precisely on nobody poking around in there.

That is the structural discomfort of security appliances: they are the machines where you cannot install your agent, so your endpoint detection never reaches them. We have already covered how an all-green console can mean nothing at all. Here the problem is different and in a way cleaner: it is not that the agent lies, it is that there is no agent. Nobody is at fault; it is a consequence of the model.

What you do have left are two signals, and the interesting thing is that neither lives inside the box. The first is the network: who your management console talks to, and the correct answer is "very few parties, always the same ones". Cyclops Blink uses DNS over HTTPS precisely so its traffic resembles ordinary browsing, so the useful question is not "which protocol?" but "since when does this machine initiate outbound connections to new destinations?". Flow analysis sees that; the appliance does not. The second is the configuration, compared against a copy that does not live on the appliance itself: if your only reference for how the FMC should look is the FMC, you do not have a reference, you have a mirror. It is the same thing we said when it was another vendor's management console, and we repeat it without changing a comma.

For the immediate term there is something more concrete: Cisco published Snort signatures: 66075 to 66080 for the 10.0, 66883 for the static-credentials one and 66960-66961 for the malware. If you have an IPS in the path of that management interface, checking those signatures are loaded and set to block is today's ten-minute job.

About the 5.3

The ransomware did not come in through the 10.0. It came in through the 5.3. We are not going to rerun here the post we already wrote about a score being insufficient to order the patching queue, but there is a nuance we did not make then: on a single-purpose appliance, "low-privileged account" is a label borrowed from the world of general-purpose servers, where there genuinely are many things such an account cannot do. On an FMC there are not many things. Privilege is not measured by what the account can execute: it is measured by how many firewalls it can see. A read-only account on the system holding your entire perimeter's configuration is, precisely, the haul this article is about.

What we would do, in order and by cost

1. Today: patch and take the management plane off the internet. The hotfixes for both CVEs, without waiting for the release due the week of the 16th. And in parallel, check whether that administration interface is reachable from outside. If it is, that is the real finding, because it is not from this month: it has been there since the day it was built.
2. This week, cheap: rotate everything rotatable that appears in that configuration. IPsec pre-shared keys, SNMP communities, service accounts, RADIUS and TACACS credentials, integration API keys, portal certificates. This does not depend on whether you think you were hit: it costs an afternoon and closes the cheap half of the problem.
3. This month, medium cost: audit the exceptions. Every rule that has existed "temporarily" for years is now written down somewhere you do not control. The question is not whether the rule is dangerous in the abstract, which it nearly always is: it is whether it is still needed. And that is not guessed, it is measured: put the rule into logging mode for a month and see whether anybody uses it. The ones that log nothing fall on their own, and that conversation is far easier than the "just in case" one. Removing the surplus is the only action on this list that genuinely changes the blueprint, and you can justify it without mentioning any incident at all.
4. Expensive and slow: change the topology. Renumber a segment, move a VPN endpoint, redo the segmentation. Almost nobody does it. We rarely recommend it either, and saying so out loud is part of the job. But let the answer be "no" in writing and with a reason, not by omission. "We evaluated renumbering the server segment and decided against it, because the cost is X and the benefit does not justify it" is worth a great deal eighteen months from now, when something happens and somebody asks what was done.
5. And one that costs nothing: get the configuration backup off the appliance itself. An external repository with history, that the appliance writes to but cannot delete from. It is not only for this: it is what turns "I think somebody changed a rule" into "this rule changed on Tuesday at 03:14 and here is the diff".

What we are not claiming

We do not know how many FMCs are exposed to the internet and we are not estimating it: we have seen figures circulating over the past two days and could not corroborate them against a primary source, so we are not repeating them. Talos does not say UAT-11823 is Sandworm: it says, with high confidence, that it is an advanced persistent threat actor that overlaps in tooling with Sandworm, and that the implant it deploys — Cyclops Blink — was previously attributed to Sandworm by the United States and the United Kingdom. Tooling overlap is not identity, and a good deal of this week's coverage has slid from one to the other without saying so. We stay with what the report actually says. Nor do we know whether, in any specific case, complete or partial configurations were actually exfiltrated: what the report says is that scripts were deployed to harvest them, and the difference matters. And we are not resellers of any particular platform, Cisco included: we recommend according to the case, not according to the commission, so nothing above changes our invoice. If you have an FMC and your provider applied the hotfixes on Wednesday, you have done the urgent part and there is nothing to buy; what would be missing is the other half, the blueprint one, and that one is not urgent, it is important, which is worse.

Note on sources

Every fact in this post comes from public sources consulted on 11 September 2026. The main one is the Cisco Talos blog post "Active exploitation of Cisco Secure Firewall Management Center vulnerabilities", dated 9 September 2026, which is the source of the three activity clusters (UAT-12197, UAT-11823 and UAT-11988) and what each did, the description of both vulnerabilities and their CVSS scores of 10.0 and 5.3, the JSP web shell in the Tomcat directory, the JAR file querying internal databases, the Netcat reverse shell, the two bash scripts harvesting managed-device configurations, the Cyclops Blink implant with DNS over HTTPS, Qilin ransomware, the rest of the tooling (Python SOCKS5 proxy, reverse SSH tunnel, impacket, Invoke-TheHash, custom AV killers), the persistence through license.tmp turned into a Makeself package and executed as root by package_info.pl, the scripts in /etc/init.d/, the recommendation to apply the hotfixes without waiting for the hardening release due the week of 16 September, and Snort signatures 66075-66080, 66883 and 66960-66961. The description of CVE-2026-20079 as originating in a system process improperly created at boot, the absence of a workaround and the mitigation of keeping the management interface off the internet are in Cisco's own security advisory (cisco-sa-onprem-fmc-authbypass-5JPp45V2); the static-credentials nature of CVE-2026-20316, in Help Net Security's coverage (10 September 2026). The CISA KEV dates are verified against the catalogue's primary JSON file, version 2026.09.10: CVE-2026-20079 added 9 September with a 12 September deadline, and CVE-2026-20316 added 29 July, due 1 August, and flagged as known to be used in ransomware campaigns. The link between UAT-11823 and Sandworm comes from Talos itself, which states a tooling overlap — not identity — and notes that Cyclops Blink was previously attributed to Sandworm by the United States and the United Kingdom; the distinction between overlap and identity is ours. The following is OUR reading, not the sources': the distinction between what rotates and what does not; that perimeter configuration functions as a description rather than a secret, and therefore lets an attacker skip the noisy scanning phase; the list of six files still valid two years from now; the argument that on a single-purpose appliance privilege is measured by how many devices the account can see; the idea that on an appliance the only two available signals live outside the box; and the five points ordered by cost, including the recommendation to write down the decision NOT to change the topology. We give no figures for exposed appliances or victims, because we have not verified any. The cover photograph is "Switches and connectors unplugged", published on rawpixel under a Creative Commons CC0 1.0 licence.