Respond to the Cisco Secure FMC Static-Credential Vulnerability

Cisco disclosed CVE-2026-20316 on 29 July 2026: a static credential in the Cisco Secure Firewall Management Center (FMC) web interface can let an unauthenticated remote attacker sign in as a low-privileged user and access sensitive data. Cisco says it became aware of active exploitation in July, and CISA added the issue to its Known Exploited Vulnerabilities catalog on 29 July with a required-action date of 1 August for federal civilian agencies.

The useful response is not to test a firewall manager from the internet. It is to establish which FMC appliances are affected, reduce unnecessary management exposure, preserve evidence, install Cisco’s applicable hot fix or fixed release during an approved change window, and verify that the management plane and managed devices return to their expected state. Cisco reports no workaround that fixes this issue. Restricting access reduces exposure, but it does not replace remediation.

This guide is for administrators of on-premises Cisco Secure FMC. It does not apply to Cloud-Delivered FMC, Firewall Device Manager, Secure Firewall Threat Defense, ASA software, or Security Cloud Control, which Cisco lists as not affected by this advisory. Commands are documentation-verified examples. Run them only on FMC systems your organization owns or administers, and keep management addresses, credentials, device inventories, backups, and log exports out of tickets and public repositories.

Start with an owned-asset inventory

Begin by answering a narrow question: which systems are actually Cisco Secure FMC, and which software train does each one run? Do not infer this from the managed firewall model. FMC is the management application; an FTD device managed by an FMC is not itself the affected product.

Use the approved administrative interface or console for each management center to record its hostname, serial number, software version, management address, responsible team, backup status, and maintenance window. Keep that record in the incident or change system. The advisory affects Cisco Secure FMC software regardless of device configuration, so an appliance that has a small number of managed devices is still in scope.

Also identify every path to the FMC management interface. Check published firewall rules, load balancers, VPN access groups, jump hosts, DNS records, cloud security groups, and any remote-support arrangement. Cisco notes that removing public internet access reduces the associated attack surface. A management interface should normally be reachable only from an administrative network or a controlled VPN, not from an arbitrary client network.

This is an exposure-reduction check, not a reason to make an emergency routing change without a rollback plan. Record the existing allowed sources before changing an access-control list. If operations teams depend on a jump host, monitoring collector, TAC workflow, or automation account, include that dependency in the change record. A hastily applied deny rule that locks out the people performing remediation does not improve the incident response.

Preserve evidence before changing the appliance

Cisco published one specific indicator for this advisory. From the FMC command-line interface, enter expert mode and use the documented query. The command reads local log files; it does not contact a target or exercise the vulnerability.

expert
sudo su
zgrep "package_info.*license" messages*

Cisco says that output containing /var/tmp/license.tmp in a package_info.pl command may indicate exploitation. Treat a match as an incident signal, not as conclusive attribution and not as a cleanup instruction. Preserve the relevant log files and their timestamps according to the organization’s evidence-handling process, limit access to copies, and contact Cisco TAC for recovery guidance. Do not delete the temporary file or rotate logs merely to remove a visible indicator.

An empty result is useful evidence, but it does not prove that the appliance was never accessed. It only says that this published indicator was not found in the log files searched. Record the command, the time it was run, the appliance identity, and whether rotated messages files were present. Review ordinary administrative and authentication logs around the period Cisco identifies, using the logging and retention procedures already approved for the environment.

If the management center is internet-reachable, or if there is evidence of unexpected access, escalate through the incident-response process before performing a routine maintenance change. Consider the managed firewall policy, stored network objects, certificates, integration credentials, and administrator accounts sensitive. The correct recovery scope depends on the organization’s investigation and Cisco TAC guidance; this article does not assume that a hot fix alone resolves a suspected compromise.

Select the fixed software from Cisco’s advisory

Cisco’s advisory lists hot fixes for the affected trains. As of the advisory revision dated 31 July 2026, the listed packages are:

Do not select a package by matching only the first digit of a version. Compare the exact installed release with the current Cisco advisory and download the matching package from Cisco Software Center through the organization’s authorized account. Cisco may revise fixed versions or installation instructions after publication. Recheck the advisory immediately before scheduling the change.

Before upload or installation, obtain a current FMC backup with the site-approved backup destination and verify that the backup completes. Record the installed version, the chosen package filename, advisory revision, change ticket, expected service impact, rollback decision, and named operator. Read Cisco’s installation guidance for the exact train. A management-center update can affect access to the web interface and the availability of policy-management functions even when traffic enforcement on managed devices continues.

Verify the package checksum or signature by the method Cisco supplies. Do not use an archive retrieved from a ticket attachment, personal file share, or an unverified mirror. Keep the appliance’s management interface on the restricted administrative path while the change is pending; an access restriction is a compensating control, not a substitute for the fixed software.

Install in a controlled change window

Use FMC’s documented update workflow for the matching release. The precise screens and restart behavior vary by release, which is why the advisory and train-specific Cisco documentation are the authority for the installation sequence. Confirm that the appliance has enough available space and that any high-availability or disaster-recovery procedure is understood before starting.

At the start of the window, notify firewall and network operations teams that policy deployment may be temporarily unavailable. Avoid combining the security update with unrelated policy edits, device registration changes, certificate replacements, or network redesign. A small change set makes it possible to distinguish an update problem from a pre-existing configuration issue.

After the installer reports completion, reconnect through the expected administrative route and confirm the installed version or hot-fix state using the FMC interface or Cisco’s documented CLI check. Save the resulting version record with the change. If the update fails, stop at the documented failure boundary, preserve the error details, and engage Cisco TAC rather than repeatedly retrying an installer against a management appliance.

Verify the management plane and managed devices

A successful installer is only the first verification. Check that the FMC web interface is available from an authorized administrator network and unavailable from networks that should not manage it. Test with a normal administrator account; do not attempt to authenticate with suspected credentials or reproduce the vulnerability.

Then review the health of the management relationship. Confirm that the expected managed devices are registered and communicating, policy deployment status is understood, scheduled tasks are present, and operational monitoring has resumed. If the environment permits a harmless policy deployment, use the normal change process to validate that FMC can produce and deliver a reviewed policy update. Do not use an emergency vulnerability response as a reason to make unrelated firewall-rule changes.

Repeat Cisco’s published log query as a post-change record, while preserving the original evidence separately. The desired technical outcome is an FMC on the advisory’s fixed software, reachable only through its intended management path, with a recorded investigation result and normal managed-device status. Continue to watch Cisco security advisories and the KEV catalog because active exploitation and fixed-release guidance can change after the initial response.

Verification checklist

• Every Cisco Secure FMC appliance has an owner, exact version, management path, and remediation status.
• Cisco’s published indicator was checked and any suspected compromise was escalated with evidence preserved.
• The selected Cisco hot fix or fixed release matches the appliance’s exact software train.
• A current backup and a documented rollback decision exist before installation.
• The updated FMC is reachable from approved administration networks and not publicly exposed.
• Managed devices, policy-management functions, and monitoring are in their expected state after the change.
• The Cisco advisory and CISA KEV entry were rechecked immediately before closure.

Sources

• Cisco Security Advisory: Cisco Secure FMC Static Credentials Vulnerability
• CISA Known Exploited Vulnerabilities Catalog entry for CVE-2026-20316
• NIST NVD: CVE-2026-20316