Cisco ISE REST API Authentication Bypass: Read the Advisory Before It Becomes a KEV Entry

When a vendor ships a critical advisory covering authentication bypass on a management plane appliance, defenders have a narrow window. The advisory predates any entry on CISA's Known Exploited Vulnerabilities list; no in-the-wild exploitation has been correlated yet. That gap is where readiness work belongs: understand the flaw, confirm exposure, and stage the change before an exploit note lands and turns advisory review into incident response.

This post covers the vendor advisory for Cisco Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC), tracked as CVE-2026-76423. It also cross-references the same-cycle Cisco Secure Firewall Management Center (FMC) authentication bypass, CVE-2026-20079, because the two share the same defender pattern: an unauthenticated remote attacker reaches a management plane over HTTP and, from there, the underlying operating system.

What the ISE flaw is

Per the vendor advisory, multiple vulnerabilities in Cisco ISE and ISE-PIC could allow a remote attacker to bypass authentication to the REST API, achieve remote code execution, perform SQL injection, and conduct XML External Entity injection attacks on an affected device. Cisco has released software updates that address these vulnerabilities. There are no workarounds.

Two details matter for triage. First, the REST API authentication bypass is the anchor primitive: once an attacker clears authentication, the other listed weaknesses become vehicles for post-bypass action against configuration, backing stores, or the OS. Second, "no workarounds" means no configuration change can prevent exploitation without patching. Access control at the network edge is the only mitigation you can stage in parallel with the upgrade window.

For the companion FMC bypass (CVE-2026-20079), the vendor states the root cause plainly: "an improper system process that is created at boot time." An attacker sends crafted HTTP requests to the web interface, executes script files, and reaches root on the underlying operating system. Same shape, same operator objective: unauthenticated remote to root, through the web layer.

The precondition an attacker needs

For CVE-2026-76423, the preconditions come directly from the advisory:

For CVE-2026-20079, the precondition is simpler: reach the FMC web interface over HTTP(S) and send crafted requests.

The implication is direct. If either management plane is reachable from a network the attacker controls (the internet, a partner segment, a lab VLAN silently promoted into production, or a jump host with degraded egress controls), the attacker satisfies the precondition.

How to determine exposure

Exposure discovery is a two-part exercise: inventory the assets, then determine which expose the management plane to unauthenticated callers.

Start with the asset side. If you keep an authoritative inventory of network appliances, filter for the affected product families. If you do not, work from configuration management artifacts. A minimal shell pass across bastion-collected show output looks like this:

# Inventory Cisco ISE nodes and software versions from a directory of
# 'show version' captures. Adjust regexes to your capture format.
for f in captures/*.txt; do
  host=$(basename "$f" .txt)
  ver=$(grep -Ei 'Cisco Identity Services Engine|ISE.+version' "$f" \
        | head -n1 | sed -E 's/.*[Vv]ersion[: ]+([0-9][^ ,]*).*/\1/')
  [ -n "$ver" ] && printf '%s\tISE\t%s\n' "$host" "$ver"
done | tee ise-inventory.tsv

# Cross-reference against the fixed versions listed in the vendor advisory
# for CVE-2026-76423 before you assume a host is patched.

Then determine reachability. From within each network zone that should not reach the management plane, probe the exposed ports without touching the vulnerability itself. A benign TLS handshake confirms exposure and yields the certificate metadata you need to correlate:

# Confirm whether an untrusted zone can even reach the management port.
# Replace target with your inventory entry; do not run against third parties.
timeout 5 openssl s_client -connect ise-admin.example.com:443 \
  -servername ise-admin.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

If that returns a certificate from an untrusted zone, exposure is proven; you do not need to test the exploit primitive to justify the change. The same technique applies to FMC and, more generally, to any management plane you inherited without a threat model.

Where the vendor has published request signatures, ingest them into your WAF or reverse proxy. For unauthenticated bypass classes, look for anomalous access to REST endpoints without a preceding successful login event in the appliance audit log. Absence of the login event is often the strongest signal available before mature signatures exist.

What to do before this reaches KEV

CISA's current directive for KEV-tracked flaws is BOD 26-04, Prioritizing Security Updates Based on Risk, which carries the KEV criteria forward from the directive it supersedes. Federal civilian agencies must remediate KEV entries by the due date CISA assigns. Everyone else should treat KEV as the most credible community index of what is being actively used against defenders. When a management plane authentication bypass appears in a fresh vendor advisory, KEV is the direction of travel; the only variable is how long the trip takes.

Stage the following before you have to:

  1. Constrain reachability. Restrict the ISE and FMC management interfaces to a dedicated management VRF or jump-host CIDR. If the interface answers requests from a general user VLAN, that is a change you can ship in a maintenance window this week.
  2. Patch to the vendor's stated fixed versions, not to a version derived from a third-party summary. Trackers sometimes coalesce fix levels incorrectly.
  3. Preserve evidence. Snapshot the appliance configuration and audit logs before upgrade. If exploitation turns out to have preceded your patch, you will want the pre-change state.
  4. Rotate credentials that lived on the appliance. Authentication bypass is often paired with access to credential material stored on the appliance file system; assume harvest until proven otherwise. This applies to TACACS+ shared secrets, RADIUS keys, LDAP bind accounts, and any REST API tokens issued from the box.
  5. Add detections for post-bypass behaviors: unexpected admin user creation, unexpected API token issuance, outbound connections from the appliance to non-vendor destinations, and configuration exports that do not correspond to a change-management ticket.

The advisory is public. The precondition set is narrow. The mitigation is a patch plus a network ACL, both of which you already know how to ship. Moving now, before a KEV entry, lets you pick the change window. After a KEV entry, the change window picks you.

Verifiable security.