Cisco ISE Has an Actively Exploited Authentication Bypass. Check More Than the Version.

Cisco found an authentication bypass in Identity Services Engine while resolving a Technical Assistance Center support case. The company now says the vulnerability is being actively exploited.

CVE-2026-76460 does not require an account. A crafted request to an ISE API endpoint can bypass the web management interface, and Cisco warns that a successful attacker may reach command execution as root. The vulnerability carries a 10.0 CVSS score, affects ISE and ISE-PIC regardless of configuration, and has no workaround.

If I owned one of these deployments, I would install the fixed patch immediately. I would not close the incident when the version number changed.

A patch prevents the same request from working again. It cannot prove that nobody used it before the patch arrived.

ISE is part of the network’s decision-making machinery

ISE is more than an appliance with a vulnerable admin page. It can authenticate users and devices through RADIUS and TACACS+, make authorization decisions, assign network segments, hold endpoint and identity information, and exchange context with other security systems through pxGrid.

The exact blast radius depends on how a particular deployment uses it. An ISE instance limited to a narrow role is not equivalent to one tied into device administration, profiling, segmentation, directory services, and automated containment. But that is precisely why the surrounding systems belong in the response.

An attacker with root on an ISE node is standing beside policy, identity data, certificates, integration credentials, and records that may be trusted elsewhere. Cisco’s advisory does not say every one of those was taken or changed. It does mean that checking only whether authentication still works is a poor integrity test.

This is the difference between patch management and incident response. The first fixes a known defect. The second asks what authority the affected system had, what it could reach, and whether anything used that authority while the door was open.

Cisco’s log check is useful, but it is not an all-clear

Cisco tells administrators to inspect ise-kong/access.log for suspicious usernames on every node in a distributed deployment. Its non-exhaustive example searches for dummyuser:

show logging application ise-kong/access.log | include dummyuser

Older access logs can be collected through an encrypted support bundle. That is worth doing before an upgrade, re-image, or retention policy removes the evidence you need.

The harder part is in Cisco’s next warning: root access lets an attacker remove or hide evidence on the appliance. A clean local search is therefore useful, but it is not proof that exploitation did not occur.

Cisco specifically recommends cross-checking network and firewall logs outside ISE for unexpected uploads to external addresses or downloads from suspicious addresses. I would also preserve whatever independent records the environment already has—administrative access, DNS, proxy, NetFlow, authentication, configuration management, and backups—rather than inventing a new evidence pipeline after the fact.

Evidence stored on the affected node shares the node’s trust problem. Evidence collected elsewhere may still describe what the node did.

Patch every node, not just the administration node

Cisco lists these as the first fixed releases:

ISE or ISE-PIC release	First fixed release
3.1	3.1 Patch 12
3.2	3.2 Patch 11
3.3	3.3 Patch 12
3.4	3.4 Patch 7
3.5	3.5 Patch 4

Release 3.0 has reached the end of software maintenance, so Cisco directs those customers to a supported fixed release. There is no configuration that makes an otherwise vulnerable ISE version unaffected.

Cisco says there is no workaround, although infrastructure access-control lists can reduce exposure by allowing only required management and control-plane traffic to reach ISE. That is a sensible mitigation and should probably have existed already. It is not a substitute for the update, especially now that exploitation is public.

A distributed deployment also turns “patch ISE” into several changes, not one. Inventory every persona and node, confirm the installed patch rather than the intended patch, and verify replication and service health afterward. The node that presents the management interface is not necessarily the only place worth examining; Cisco explicitly says to review each node’s logs.

What I would do after the upgrade

1. Preserve logs and a support bundle before destroying useful evidence.
2. Restrict management-plane access at the network boundary and install the fixed release on every affected node.
3. Search the local access logs, then compare the result with firewall and network records that the appliance could not rewrite.
4. Review unexpected administrative accounts, policy changes, endpoint or identity-data changes, certificates, and recent integration activity.
5. Scope credentials and trust relationships available to each affected node. Rotate them where the evidence or uncertainty justifies it; do not blindly rotate half the company without knowing what depends on them.
6. If there are signs of exploitation, follow Cisco’s advice to re-image affected nodes and restore configuration from a known-good backup. Do not promote a possibly compromised node back into a clean deployment because rebuilding it is inconvenient.
7. Validate the access decisions and integrations that depend on ISE after recovery. A healthy process list does not prove that policy is still correct.

That is more work than applying a patch. Root access to a policy system earns more work.

The origin of this disclosure is also worth remembering. Cisco says the vulnerability was found while resolving a support case, and it now confirms active exploitation. Combined with the possibility that local evidence can be removed, that is enough uncertainty to justify looking beyond the appliance itself.

Sources

• Cisco, Identity Services Engine Authentication Bypass Vulnerability.
• Canadian Centre for Cyber Security, AL26-021: Vulnerabilities impacting Cisco ISE and ISE-PIC.
• Cisco DevNet, Identity Services Engine APIs and platform overview.