Cisco ISE CVE-2026-76460: When the Policy Engine Becomes the Weakest Link
On September 16, 2026, Cisco published a batch of security advisories covering 77 CVEs. One of them, CVE-2026-76460, carries a CVSS 3.1 base score of 10.0 and affects Cisco Identity Services Engine (ISE) and the ISE Passive Identity Connector (ISE-PIC). Cisco's Product Security Incident Response Team confirmed exploitation in the wild, and CISA added the vulnerability to its Known Exploited Vulnerabilities catalog the same day, giving federal civilian agencies a remediation deadline of September 19, 2026 — a three-day window.
The flaw is classified as CWE-648, incorrect use of privileged APIs. An API endpoint behind the ISE management interface does not enforce authentication properly. An unauthenticated remote attacker can send a crafted request that bypasses the web-based management login and reaches the endpoint directly. Successful exploitation yields root-level command execution on the appliance.
Why an authentication bypass on a NAC platform matters more than the score
ISE is a network access control platform. It decides which users and which devices may join the access domain, and what they may reach once admitted. It also holds management credentials for the devices it governs, shared secrets, and machine accounts integrated with Active Directory.
That combination changes the shape of the incident. An attacker who obtains root on an ISE node does not simply control one appliance. The node is the component that issues access decisions, so the attacker can authorise arbitrary devices across the estate. The compromise also sits upstream of the audit trail: identity-based authorisation and logging continue to function normally while the inputs they consume are already forged.
Cisco's advisory states that the vulnerability is independent of configuration. There is no optional feature to disable and no software workaround. The only interim measure the vendor describes is an infrastructure access control list (iACL) that restricts which sources may send management and control-plane traffic to the ISE nodes.
Affected versions and fixed builds
All supported configurations of ISE and ISE-PIC are affected. Cisco released fixes per maintenance branch:
| Branch | Fixed build |
|---|---|
| ISE 3.1 | Patch 12 |
| ISE 3.2 | Patch 11 |
| ISE 3.3 | Patch 12 |
| ISE 3.4 | Patch 7 |
| ISE 3.5 | Patch 4 |
ISE 3.0 is also vulnerable but has reached end of software maintenance. Organisations still running that branch must migrate to a supported release before patching is even possible. This is a practical trap for asset inventories that record only the major version: the fix granularity here is the patch number, not the release train.
Detection is harder than usual because the attacker holds root
Cisco's guidance is to review access.log on every node in a distributed deployment, because an attacker may target any reachable node. The vendor provides an example command:
show logging application ise-kong/access.log | include dummyuser
Any output from that filter is potentially indicative of malicious activity.
The complication is explicit in Cisco's own advisory: an attacker with root can delete or hide evidence, including local logs. Detection therefore cannot rely on the compromised host. Security teams should correlate upstream network and firewall logs for anomalous uploads, downloads, or outbound connections originating from ISE nodes, and should treat local log absence as inconclusive rather than exculpatory.
If malicious activity is confirmed, or if there is sufficient reason to believe a node was compromised, Cisco recommends reimaging the affected node and restoring configuration from a known-good backup. Attempting to clean a rooted appliance in place is not a supported recovery path.
What defenders should sequence first
Three actions follow directly from the facts above.
Identify exposure before patching. Because the vulnerability is configuration-independent, the question is not whether a feature is enabled but whether the management interface is reachable. Enumerate every ISE and ISE-PIC node and determine which ones accept management traffic from anything other than a tightly scoped administrative network.
Apply iACLs while the change window is being arranged. Restricting management and control-plane traffic to known administrative sources does not remove the vulnerability, but it removes the unauthenticated reachability that exploitation requires.
Plan for credential rotation, not just patching. ISE holds credentials for downstream devices and identity data for the organisation. If a node was exposed to the internet or to a broad internal segment during the exposure window, the assumption that nothing was read cannot be verified from the node itself. Rotating the credentials ISE holds, and reviewing administrator accounts and TOTP enrolments, is the conservative response.
The broader lesson is about how access control is modelled. Treating a NAC platform as a single point on the network perimeter understates its role. It is a decision chain: policy, identity, credential custody, and enforcement all pass through it. A 10.0 authentication bypass on that chain is not a patch-management inconvenience; it is a change in who gets to decide who is trusted.
References
- Cisco Security Advisory, CVE-2026-76460, September 16, 2026.
- CISA Known Exploited Vulnerabilities Catalog, entry added September 16, 2026.
- Cisco PSIRT advisory batch, September 2026 (77 CVEs across ISE, Secure Firewall ASA, FTD and FMC).
- Reporting on the three-day federal remediation deadline and the absence of a software workaround, September 18–21, 2026.
Top comments (0)