Cisco Identity Services Engine Vulnerabilities

Cisco published a same-day cluster of critical advisories on 2026-09-24 covering Identity Services Engine (ISE) and the ISE Passive Identity Connector (ISE-PIC). One of them, tracked as CVE-2026-76423, requires no authentication. The others in the ISE family require valid administrative credentials. This post examines the lead flaw in detail: what the vendor says the defect is, the precondition an attacker needs, how to determine whether an instance is exposed, and what to do now, before an exploited-in-the-wild designation compresses the window.

Why ISE sits in the blast radius of every enterprise network

Identity Services Engine is Cisco's policy decision point for 802.1X, TrustSec, guest access, BYOD onboarding, and posture. It brokers RADIUS and TACACS+ for network access, publishes downloadable ACLs and SGTs to switches, and integrates with Active Directory or LDAP through PxGrid. ISE-PIC is the trimmed-down sibling that consumes identity mappings from AD, syslog, or WMI and republishes them to firewalls and downstream policy engines. ISE decides who can connect and, in TrustSec environments, what those users may reach. A pre-auth code path into ISE is a pre-auth code path into the fabric that arbitrates lateral movement.

The lead flaw: CVE-2026-76423

Cisco's advisory groups multiple defects under a single ID and describes them this way: "Multiple vulnerabilities in Cisco Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (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."

Four primitives sit under one advisory:

  1. Authentication bypass on the REST API. The attacker reaches an authenticated route without producing valid credentials.
  2. Remote code execution. Once inside a privileged code path, an attacker executes commands on the underlying operating system.
  3. SQL injection. Structured input reaching a database driver is not parameterised, allowing an attacker to reshape the query.
  4. XML External Entity injection. A parser accepts a document whose DTD references external entities, letting the attacker read files or reach internal HTTP endpoints from the ISE host.

The real risk is composability. Auth bypass is the entry ticket. XXE gives an attacker a read primitive on the ISE filesystem and on any URL the ISE process can reach, which typically includes localhost management endpoints and PxGrid brokers. SQL injection turns that read primitive into arbitrary state changes against the ISE datastore, which itself brokers policy. RCE closes the loop by giving the attacker shell on the appliance, at which point RADIUS shared secrets, TACACS+ keys, certificate material, and AD service credentials are all accessible.

Cisco states that software updates address these vulnerabilities and that there are no workarounds. Plan around that last phrase.

The precondition an attacker needs

Read the vendor's advisory carefully. It mentions no required role, session, or token for the REST API path and no "must be logged in" precondition. The only precondition is network reach to the ISE administrative interface hosting the REST API: a single TCP flow from an attacker-controlled host to the ISE admin plane. In practice, exposure comes from three common misconfigurations:

How to determine exposure

Do not rely on inventory spreadsheets. Two questions matter, and both are answerable from the wire.

First, which of your ISE and ISE-PIC nodes are running a fixed version? The vendor advisory is the authoritative source for fixed trains. Retrieve it and compare fixed trains against the release output on each appliance:

# From an ISE admin CLI session
show version | include "Cisco Identity Services Engine"
show application status ise | include "Application Server"
show application version ise

Second, from any untrusted segment, is TCP 443 to the ISE admin interface open? Use a source that simulates the worst-case attacker vantage point. The snippet below is a benign reachability probe, not an exploit. Replace the hosts with your own inventory:

# Reachability probe from an untrusted segment
for host in ise01.example.com ise02.example.com isepic01.example.com; do
  timeout 3 bash -c "</dev/tcp/${host}/443" \
    && echo "REACHABLE ${host}:443" \
    || echo "blocked   ${host}:443"
done

# Confirm the responding service identifies as ISE
curl -sk -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  https://ise01.example.com/admin/

If a host outside your management enclave sees REACHABLE and gets a 200 or 302 into /admin/, you have the exact preconditions the advisory describes.

What to do before this reaches the exploited-in-the-wild lists

Cisco has not reported CVE-2026-76423 as exploited in the wild as of 2026-09-24, and CISA has not added it to the Known Exploited Vulnerabilities catalog. Federal agencies remediate KEV entries under BOD 26-04 (Prioritizing Security Updates Based on Risk), which carries the KEV criteria forward from the earlier directive. When a critical unauthenticated flaw in an identity broker arrives with vendor-supplied fixes and no workaround, patching windows will compress once weaponised exploit code surfaces.

Concrete steps to take now:

The authenticated companions

Cisco's same-day cluster also lists CVE-2026-20176 and CVE-2026-20282, both of which require valid administrative credentials before reaching ISE command execution. These matter less on day one than the unauthenticated flaw, but they matter on day two, once an attacker already inside your environment can pivot with a captured admin cookie or a service account. Treat them as part of the same patch, not a separate effort.

Verifiable security.