A crafted HTTP request runs as root on the console that pushes every Cisco firewall's policy

Cisco's advisory puts the root cause of the 10.0-rated CVE-2026-20079 in an improper system process created during boot ^[2][3]. In use, an attacker sends a crafted HTTP request to an unpatched device, the web interface processes it without a valid session, and scripts execute as root on the underlying operating system ^[3]. There is no workaround ^[4].

The escalation in UAT-11823's chain went through Cisco's own code path. Talos says the cluster rewrote license.tmp so that an installation tool would execute it as root, opened a Netcat reverse shell, harvested configuration from the managed firewalls, and installed a Cyclops Blink variant ^[9]. That implant is a Linux ELF loader supporting credential theft, command execution, file transfer and packet sniffing ^[10]. UAT-12197 went after the credential store instead. It dropped a JSP web shell into the CSM Tomcat web root and a JAR command executor, then used the built-in OmniQuery.pl script to pull authentication data out of FMC's internal database ^[8].

One of the three clusters worked the static-credential flaw alone. Talos assesses UAT-11988 with high confidence as a Qilin ransomware affiliate. It logged in with the hardcoded credentials from CVE-2026-20316, mapped the environment with legitimate tools, deployed an antivirus killer and delivered Qilin ransomware to selected endpoints ^[11]. That flaw scores 5.3 on its own ^[6].

FMC pushes policy, firmware and configuration to every managed Cisco firewall in an estate, and it stores the management credentials for the firewalls it governs ^[14][23]. Rotation therefore covers every credential reachable from the console ^[23].

External scan data counts a different population. A dev.to analysis ran ZoomEye queries and found 2 assets under app="Cisco Firepower" and 114 under app="Cisco ASA", indexed under fingerprints the FMC console does not present ^[18]. A console placed behind a VPN, a jump host or an internal segment does not appear in an external asset index at all ^[20]. VulnCheck's count of roughly 300 to 700 internet-exposed instances is a March 2026 figure, unrevised since ^[15]. For that range to say anything about your own estate, your console would have to be in the internal majority it implies. The evidence for that comes from configuration management, network monitoring and the firewall rules that permit access to the console ^[27].

The timeline is the other constraint. Cisco fixed the flaw in March 2026 and disclosed it with no evidence of exploitation, then learned in August that it was being used and confirmed that on 9 September ^[5]. About five months separated the fix from that knowledge ^[26]. Hotfixes went out on 31 July 2026, and the consolidated hardening release was planned for the week of 14 September, 45 days later ^[16][24]. Talos advised against waiting for it ^[16].

For devices already patched, one retrospective check is cheap. In expert mode, run zgrep "package_info.license" /var/log/messages. If the output points to /var/tmp/license.tmp, treat the device as compromised. Also check the CSM Tomcat web root for unexpected JAR files ^[22].