Vulnerabilities

Cisco ISE zero-day: root without a login, patch it first

CVE-2026-76460 lets an unauthenticated attacker bypass Cisco ISE's management login and run commands as root. Fixed versions, checks and cleanup.

By Yaali. September 25, 2026, 6 min read, Vulnerabilities, Patching, Identity.

Cisco Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC) have a critical flaw, CVE-2026-76460, rated CVSS 10.0. An API endpoint does not check authentication properly, so an attacker with no account can send one crafted request, get past the web management login and, according to Cisco, end up running commands as root. Every ISE and ISE-PIC deployment on releases 3.0 to 3.5 is affected, whatever its configuration, and Cisco says there is no workaround.

It is already being used. Cisco published the advisory on September 16 and confirmed active exploitation, and CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog the same day with a three-day deadline for US federal agencies: September 19. If you run ISE for 802.1X, guest access or device posture and have not patched yet, do it today.

Attack path for CVE-2026-76460: a crafted request to the ISE API gateway skips the management login, gives root on the ISE node, and exposes access policy, RADIUS secrets, identity store connections and audit logs

Why ISE deserves firewall-level urgency

ISE decides who and what gets on the network. Switches, wireless controllers and VPN gateways send it RADIUS requests for every 802.1X login, guest portal session and posture check, and ISE answers with accept, reject, a VLAN or a downloadable access list. Because it sits on the internal network, it often waits for a routine maintenance window while firewalls and VPN gateways get emergency patches.

With root on ISE, an attacker can change authorization policy so their own laptop lands on a privileged VLAN, or quietly let a device through that posture rules would block. ISE also holds the RADIUS shared secret for every network device it serves and the account it uses to join Active Directory, which gives an attacker material for moving on to the rest of the network. Cisco adds that root access lets an attacker alter the system and hide evidence, which makes investigation harder.

How it works

Since release 3.1, ISE sends its REST APIs (the External RESTful Services, Open API and Monitoring interfaces) through a built-in Kong API gateway, a proxy that sits in front of the API services and is meant to enforce authentication before passing requests on. One endpoint behind that gateway does not enforce it. It processes a crafted request without checking who sent it, which gets the attacker past the login the web management interface would normally demand, and from there Cisco says exploitation can reach command execution as root.

Cisco has not published the endpoint name or the request format. It has pointed defenders to the gateway's access log, where exploitation shows up as requests under unexpected usernames. That is the basis for the log check below.

Cisco found the flaw while working on a customer's Technical Assistance Center (TAC) support case. As Hardware Busters points out, that means at least one ISE deployment had been broken into before anyone knew the flaw existed.

What attackers are doing

Public detail is thin. Cisco's Product Security Incident Response Team (PSIRT) says it is aware of active exploitation, and CISA's KEV listing on September 16 confirms exploitation in the wild. Neither has named an attacker, given a start date or said how many organisations were hit.

What to do

Fixed releases for Cisco ISE and ISE-PIC, 3.1 Patch 12 to 3.5 Patch 4 with no fix for 3.0, followed by four steps: patch every node, restrict API access if you cannot patch yet, check for exploitation, rebuild and rotate if compromised

1. Patch to a fixed release

The fixed releases are 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4. Release 3.0 is past end of software maintenance and gets no fix, so it has to be migrated to a supported release. The same versions apply to ISE-PIC. Patch every node in a distributed deployment: the Primary Administration Node, Monitoring nodes and every Policy Service Node. Releases 3.1 and 3.2 only receive critical fixes now, so plan the move to 3.3, 3.4 or 3.5 once the emergency patch is in.

2. If you cannot patch today

Put an infrastructure access control list (iACL) in front of every ISE node, on the upstream switch, router or firewall, that allows HTTPS management (TCP 443) and the ERS API (TCP 9060) only from your admin jump hosts and the systems that genuinely call the ISE APIs. RADIUS (UDP 1812 and 1813) from network devices, and the guest and sponsor portal ports your users need, stay open. Check too that no ISE interface can be reached from the internet.

Cisco lists no workaround and says only a fixed release closes the hole. An iACL cuts the number of machines that can reach the endpoint, but anyone already on an allowed admin network can still exploit it.

3. Check whether you were hit

On each node, from the admin CLI, run show logging application ise-kong/access.log | include dummyuser. Cisco gives this as the example, and asks you to look more widely for any username in that log you do not recognise. In a support bundle the same log sits under ise/logs/apigateway/.
In the admin console, open the Audit reports under Operations > Reports and review Change Configuration Audit and Administrator Logins since early September. Look for policy set and authorization profile changes, new network devices and new endpoint identity groups nobody asked for.
Under Administration > System > Admin Access > Administrators, list admin users and remove any you cannot account for.
Outside ISE, check firewall and proxy logs for connections from ISE nodes to the internet, especially uploads to unfamiliar addresses and downloads of tools. Because an attacker with root can edit local logs, these outside records are the more reliable ones.

4. If you find signs of compromise

Cisco's advice is to re-image the affected node and restore configuration from a backup, rather than patch in place. Rebuild on a fixed release, pick a backup taken before the suspicious activity, and compare the restored policy sets with what you expect.

Then rotate what the node held: the RADIUS shared secrets configured for each network device (on ISE and on the device), the Active Directory join account and ISE's machine account, credentials for LDAP and other external identity stores, and the passwords of every ISE admin account. Review any access granted by policies an attacker could have changed while they were in.

The wider lesson

Patch priority is often set by internet exposure, which puts ISE behind the VPN and the firewall. Ranking by what a system controls gives a different order. An appliance that issues network access, holds shared secrets for every switch and joins the domain belongs in the same emergency patch group as the firewall, with its management ports locked to admin networks from the day it is installed.

Our network penetration tests check which management interfaces, ISE included, can be reached from user and guest networks, and our attack surface management work keeps that list current as the network changes. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

Sources: Cisco security advisory, CISA KEV catalog, Help Net Security, SecurityWeek, The Register, Hardware Busters, Beazley Security Labs, Qualys ThreatPROTECT, CSA Singapore.