Cisco Secure Firewall Management Center Software Authentication Bypass

On 2026-09-10 the vendor published an advisory for a critical authentication bypass in the web interface of Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management. The flaw is tracked as CVE-2026-20079. An unauthenticated remote attacker can send crafted HTTP requests to an affected device, bypass authentication, and execute script files to obtain root access on the underlying operating system.

CISA added the CVE to its Known Exploited Vulnerabilities catalog with a KEV entry dated 2026-09-09, one day before the advisory published. This flaw is confirmed exploited before most operators have finished patching. What follows covers what the flaw is, the precondition an attacker needs, how to identify exposed FMC instances, and the steps to take before this reaches your incident channel.

What the flaw actually is

The vendor identifies the root cause as an improper system process created at boot time. The FMC boot sequence starts a process that handles HTTP requests along an alternate path (the KEV catalog classifies this under CWE-288, authentication bypass using an alternate path or channel). Requests reaching that path skip the normal authentication gate; the attacker does not defeat a credential check but routes around it.

That path terminates in a handler that can execute script files, so the outcome is not a data read or a stolen session token: it is direct command execution as root on the underlying operating system. No user interaction, no valid session, and no authentication precondition are required. If the web interface is reachable, the attacker can reach the vulnerable path.

The advisory summarizes the impact:

Product:   Cisco Secure Firewall Management Center (FMC) Software
           Cisco Security Cloud Control (SCC) Firewall Management
Component: web interface (management plane)
Auth:      none required
Vector:    crafted HTTP request(s)
Outcome:   authentication bypass, script execution, root on host OS
CWE:       CWE-288 (Authentication Bypass Using an Alternate Path or Channel)
CVE:       CVE-2026-20079
KEV:       2026-09-09 (confirmed exploited)

The precondition an attacker needs

The only precondition is HTTP(S) reachability to the FMC management web interface. No client-side component, phishing lure, valid low-privileged account, or chained pre-auth SSRF is required. If TCP/443 (or whatever port the FMC web UI listens on) is reachable from the attacker's position, they can attempt the request.

Two practical consequences follow. First, any FMC whose management interface is exposed to the public internet must be treated as compromised until proven otherwise, not simply patched. Second, exposure via a jump host, a poorly segmented management VLAN, or a VPN concentrator that terminates on the management network is functionally equivalent to public exposure once an attacker has any foothold on the path.

How to determine your exposure

Answer these three questions in order.

  1. Where are our FMC and SCC Firewall Management instances, and what versions do they run? Query your asset inventory for the FMC product family. Cross-check with the vendor advisory's fixed-release table to identify which instances run a vulnerable version. Do not rely on a device's self-reported patch date; rely on the running image version.
  1. From which networks is each management web interface reachable? Enumerate actual network paths, not intended ones. A firewall rule that "only allows the SOC subnet" still exposes the interface to anything that can reach the SOC subnet. For each FMC, produce a list of source networks that can complete a TCP handshake to the management port.
  1. Which of those exposure paths cross a trust boundary you do not control? The public internet is the obvious case. Partner VPNs, contractor VDI ranges, and any network hosting endpoints with third-party browser stacks are the less obvious ones. CVE-2026-87491 and CVE-2026-85046 (both Chromium V8 remote code execution flaws added to KEV in the same window) mean that "an internal workstation" is not a strong trust boundary in September 2026.

Probe the FMC endpoints from every candidate admin subnet to confirm reachability is limited to expected sources:

# From each candidate source network, confirm intended reachability only.
curl -sk --max-time 5 -o /dev/null -w '%{http_code} %{url_effective}\n' \
  https://fmc.example.com/ui/login \
  https://fmc.example.com/api/fmc_platform/v1/info/serverversion

Any 200 or 302 response from a network that should not have management-plane access is an exposure finding, independent of patch state.

What to do before this reaches your incident channel

The vendor advisory lists no workaround. Patching is the fix. Take these steps in order:

  1. Patch to the fixed release identified in the advisory for each FMC and SCC Firewall Management instance. Do this before applying compensating controls; the flaw requires no authentication and no user interaction.
  2. Restrict management-plane reachability. FMC web UIs must not be reachable from user subnets, guest networks, contractor VPNs, or the public internet. This is best practice year-round; this week it is required.
  3. Hunt for evidence of prior exploitation. Because a successful attack yields root on the FMC host, look for unexpected script executions, new cron entries, modified web application files, unexpected outbound connections from the FMC, and configuration changes not tied to a change ticket. Preserve /var/log before rebooting.
  4. Rotate credentials and tokens the FMC has held or brokered, including device-management credentials the FMC uses to reach downstream firewalls. Root-level compromise of the FMC is compromise of everything it manages.
  5. Review the companion advisory CVE-2026-20316, a static credential flaw in the FMC web interface that lets an unauthenticated attacker log in with a low-privileged built-in account. It is a separate defect on the same product family and belongs in the same patch cycle, not a later one.

Why this pattern keeps happening

Authentication bypass via an alternate path or channel is one of the most productive vulnerability classes in appliance management planes. The reason is architectural: management web apps accumulate boot-time helpers, health-check endpoints, and inter-process handlers that are trusted implicitly because they were never intended to be reachable from outside the device. When one of those handlers binds to the same web server that fronts the login page, the login page is no longer a gate. CVE-2026-19490 (Citrix NetScaler authentication bypass, added to KEV 2026-09-09) is the same shape of bug on a different appliance in the same week. Address the pattern, not just the CVE.

If your controls confirm an appliance is patched but do not show which networks can still reach its management plane, they are answering the wrong question. Test reachability. Test the bypass path against a lab image. Prove, do not assume.

Verifiable security.