What happened
On September 9, 2026, Cisco revised its CVE-2026-20079 advisory to state that active exploitation had been observed. Cisco first published the vulnerability on March 4, 2026, and said its PSIRT became aware of exploitation during August 2026. The confirmation materially changes the operating posture from expedited maintenance to a combined remediation and compromise-assessment decision. Attribution posture: Cisco confirmed active exploitation but did not name an actor or describe post-exploitation activity.
CVE-2026-20079 allows an unauthenticated remote attacker to send crafted HTTP requests to the web interface, bypass authentication and execute scripts or commands as root. The flaw affects Cisco Secure FMC Software and Cisco Security Cloud Control (SCC) Firewall Management regardless of device configuration; Cisco said its SaaS-delivered SCC Firewall Management environments have already received the fix. Cisco states that public internet exposure increases attack surface, but it does not make internet exposure a precondition for vulnerability.
Cisco’s published check is zgrep “package_info.license” /var/log/messages; a result containing /var/tmp/license.tmp may indicate exploitation. The advisory’s example log entry is: Jul 23 16:16:33 firepower sudo: www : PWD=/ ; USER=root ; COMMAND=/usr/local/sf/bin/package_info.pl /var/tmp/license.tmp –lsm. Cisco warned that its hot fixes prevent future exploitation but may not remediate an existing compromise, and instructed customers with indicators to contact Cisco TAC.
Release-specific hot fixes are Cisco_Firepower_Mgmt_Center_Hotfix_GB-7.0.9.1-3.sh.REL.tar, Cisco_Secure_FW_Mgmt_Center_Hotfix_HL-7.2.11.1-4.sh.REL.tar, Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar, Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar, Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar and Cisco_Secure_FW_Mgmt_Center_Hotfix_P-10.0.1.1-2.sh.REL.tar. The cited Cisco advisory did not publish attacker IP addresses, domains or file hashes for CVE-2026-20079 exploitation.
Why this matters now
Secure FMC occupies a privileged control-plane position: root access to the manager can expose configuration, administrative workflows and the integrity of security operations. The vulnerability does not merely affect an ordinary application host. It affects technology used to administer enforcement infrastructure, so unexplained activity must be treated as a potential security-control compromise rather than a routine server event.
Cisco explicitly separates prevention from recovery. Its hot fixes and fixed releases protect against future exploitation, but the company warns that they may not address an existing compromise. That distinction changes the closure standard: a successful change record proves exposure reduction, while preserved log searches, incident disposition and, where required, Cisco TAC-guided recovery prove compromise has been addressed.
Cisco says removing public internet access reduces the attack surface, but the flaw affects Secure FMC regardless of device configuration. Internal attacker access, compromised administrative pathways and exposed management services therefore remain relevant. Enterprises need a decision-grade inventory of every instance and access route, not an assumption that perimeter filtering alone removed the risk.
The decision for security leaders
Run two workstreams under one accountable incident owner: exposure remediation and compromise assessment. Do not let the patching team close the risk while security operations still lacks preserved search output, a documented hunt horizon and an approved disposition for every matching event.
Require infrastructure owners to identify every on-premises FMC, its management accessibility, software branch, business dependency and recovery owner. Instances that cannot be rapidly inventoried or whose logging is unavailable should enter exception governance and receive compensating isolation rather than remaining an undocumented residual risk.
Where Cisco’s indicator appears, preserve evidence and engage Cisco TAC before routine restoration. Recovery authority should be explicit because the affected system administers security controls; restoring from an untrusted manager or reconnecting it prematurely can undermine the integrity of the broader firewall estate.
Evidence of closure
- Asset register identifies every FMC instance, owner, release and exposure path.
- Preserved search output shows no matching license.tmp execution or records an approved incident disposition.
- Network validation confirms FMC management is unreachable from unauthorised pathsOfCompromise logs retained are those specifically requested by Cisco and outcomes documented in incident records, with no disruption to the network monitoring capability due to the remediation work.
- Other post-remediation validation artef.
The Security.io assessment
Confidence is high that active exploitation is occurring because Cisco directly revised its advisory to say so. Confidence is lower on campaign scale, targeting, victim impact and attacker objectives because Cisco published no victim count, actor, infrastructure or post-exploitation account. Enterprises should calibrate urgency to the confirmed exploitation and privileged placement, not to an unavailable estimate of prevalence.
The July 23 example timestamp means defenders should not use the September confirmation date as the beginning of their search window. It does not independently establish the start of a campaign, but it makes a narrow same-day hunt indefensible. Retention limitations should be recorded as an assurance constraint rather than converted into a clean result.
An FMC without public internet access has a smaller attack surface, not a proven absence of exposure. The decision should account for internal routes, remote administration, compromised jump hosts and other paths capable of reaching the web interface. Closure requires evidence about both software state and historical activity on each instance.
Questions for the morning meeting
- Can we prove every Cisco Secure FMC instance, release and management path is inventoried?
- Are teams separating hot-fix completion from evidence that exploitation did not occur?
- Who has authority to isolate an FMC and engage Cisco TAC immediately?
- Can recovery proceed without relying on a potentially compromised management plane?