The Route That Forgot Its Guard: How CVE-2026-76460 Turns Cisco ISE Into a Root Shell for Anyone Who Asks

Every enterprise network we look at treats Cisco Identity Services Engine as the tallest wall on the property. It is the box that decides which laptop can sit on which VLAN, which contractor gets a TACACS+ shell on which switch, and which service account is allowed to touch a RADIUS realm. When a bug lets an unauthenticated stranger on TCP 443 skip all of that and land as root on the appliance itself, the compromise is not just a bad Tuesday for the network team. It is the compromise of the thing you were relying on to describe what compromise looks like.

That is what CVE-2026-76460 does. Cisco disclosed it on September 16, 2026 with a CVSS v3.1 base score of 10.0, and Cisco's PSIRT confirmed that exploitation was already underway when the advisory posted. CISA added it to the Known Exploited Vulnerabilities catalog the same day with a binding remediation deadline of September 19 for federal civilian agencies. The bug lives in the ISE management API gateway process, ise-kong, and there is no configuration switch that removes it. The fix is the patch.

Meet ise-kong, the process that decides who is admin

Cisco ISE's REST management surface does not answer requests directly. In front of the Java admin service sits a purpose built API gateway that Cisco packages as ise-kong, a Cisco flavored deployment of the open source Kong gateway, an NGINX and OpenResty reverse proxy that terminates TLS, routes each request to the correct upstream ISE service, and applies plugins for authentication, authorization, rate limiting, and access logging. In a healthy ISE, every request to /admin, /ers, or any REST route the console exposes hits ise-kong first, gets tagged with an admin identity from a session cookie or an API key, and only then reaches the code that would actually change policy.

The design is fine. Kong is a competent gateway, and running your admin plane behind one is a defensible choice, right up until any single route on the gateway is not bound to the authentication plugin. That is the whole of CVE-2026-76460. One route on ise-kong that the authentication plugin was never applied to, sitting there in production, accepting requests. Cisco tracks the bug as CWE-648, Incorrect Use of Privileged APIs, and that is the accurate label. The endpoint exposes privileged functionality to callers who never proved they should be there.

The bypass, told by the request

Craft a request against the unguarded route, and Kong forwards it to the upstream ISE service verbatim. The upstream trusts Kong to have made the authentication decision, because that is Kong's job in the pipeline, so when a request arrives without an admin identity attached the upstream service treats the missing identity as a gateway configuration matter rather than as a hostile signal. From that point the attacker is talking directly to management code that was only ever designed to talk to an authenticated administrator. The functions reachable on that route are the same functions the console uses to update system settings, and several of them include command shaped fields that eventually reach the underlying shell of the appliance. One crafted call, one shell command, one process running as the ISE application user, and because the escalation to root sits inside the same call chain that Cisco explicitly warns about, you finish the transaction as uid 0.

Nothing about this requires a foothold, credentials, phishing, or a second bug. Reachability of TCP 443 on the ISE management interface is the whole prerequisite, and the CVSS vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H is the full house because the impact really is that clean. Cisco is clear that the flaw affects ISE and ISE Passive Identity Connector regardless of feature configuration, so there is no optional module to disable and no fallback path that walks the caller through a real auth check. Every reachable appliance in the 3.1 through 3.5 trains was rootable from the network the moment the advisory went up.

What the ISE console will never tell you about this compromise

This is where our team stopped scrolling. ISE is the box a lot of blue teams look at when they hunt for identity abuse elsewhere in the network, so a compromise of ISE itself is a compromise of the alerts you were going to use to find it. A root shell on the appliance can read every RADIUS and TACACS+ shared secret in memory, mint policy exceptions that quietly place an attacker owned device onto sensitive VLANs, rewrite the same audit records you would have paged on, and delete the log lines that would have named the operator responsible. Nothing on your ISE dashboard will flag a policy modification made by whoever is inside the box, because the box wrote the dashboard.

The trace that does exist lives one layer down, inside the gateway process itself. Cisco's own detection guidance is to run show logging application ise-kong/access.log and grep for suspicious usernames, and the important thing to understand is that this log almost never contains user facing entries for legitimate admin traffic in the first place. Anything that shows up there for an admin route with no matching admin session, or under a username that is not on your operator roster, is worth pulling and investigating as a live incident. Because a successful exploit runs as root and can rewrite this same log after the fact, you also need the story from a vantage point the appliance cannot touch. Pull the firewall, load balancer, and management network flow logs in front of ISE for the same window, and hunt for unexpected source addresses hitting TCP 443, especially ones that touch a single narrow path on the appliance and never anything else.

On the ATT&CK map this reads cleanly. Initial access is T1190 Exploit Public-Facing Application the moment the ISE management interface is reachable from outside a trusted management network, execution rides T1059 Command and Scripting Interpreter via the injected shell command, and any persistence you find will usually sit under T1543 Create or Modify System Process as an added daemon or systemd unit. Assume T1070 Indicator Removal happened as well, because a root shell that ignored the log tamper option is not the actor you were up against.

The rollout: patch trains, iACLs, and the hunt that comes next

Cisco published the first fixed releases in the same advisory. Upgrade to 3.5 Patch 4, 3.4 Patch 7, 3.3 Patch 12, 3.2 Patch 11, or 3.1 Patch 12, whichever train your fleet is on. There is no configuration workaround, so the upgrade is not optional. Federal civilian agencies had until September 19, 2026 under the CISA KEV listing, and the rest of us should plan to be inside that same window whether or not the deadline binds you, because the exploitation activity is not slowing down and any exposed appliance is an active target.

While the fleet rolls, put an infrastructure ACL in front of every ISE and ISE-PIC node that narrows TCP 443 down to a small set of jump hosts on your management network. That single ACL removes remote exploitation and buys you the hours you need, and Cisco names iACLs as the network mitigation that actually prevents the request from ever reaching the vulnerable route. Once the patch is on, treat any pre patch hit in the ise-kong access log as a confirmed compromise and re image the affected node from a known good image, then restore configuration from a backup that predates the earliest suspicious entry. Rotate every RADIUS shared secret, TACACS+ key, ERS API credential, and pxGrid certificate that the compromised node ever handled, and expire any endpoint that authenticated during the exposure window until it is onboarded again through a clean node. On the network side, correlate the compromised node's outbound flows for the same window against your normal ISE peering to catch exfiltration traffic that a root shell would have otherwise quietly erased.

This is the loop BlueTeamAutomation runs continuously, where BASzy replays the primitive shape of an unauthenticated gateway bypass against your identity plane so the detection you write for CVE-2026-76460 today keeps firing on the next privileged API bug that arrives, and the evidence rolls into your SIEM, SOAR, and compliance record without a manual scramble every time.