Cisco ISE's perfect 10.0 is already under attack

What has Cisco fixed?

Cisco has released patches for a maximum-severity authentication bypass in Identity Services Engine, the appliance that decides which people, laptops and phones are allowed onto a corporate network. The flaw is tracked as CVE-2026-76460 and carries a CVSS base score of 10.0, the highest number the scale allows.

Cisco's advisory describes the mechanism plainly: “This vulnerability is due to insufficient authentication control on an API endpoint. An attacker could exploit this vulnerability by sending a crafted request to an affected API endpoint.” No login, no prompt and no user interaction are involved. A successful exploit lets an attacker into the device by walking straight past its web-based management interface.

Which versions are affected, and what fixes them?

Every Cisco ISE and ISE Passive Identity Connector deployment is affected, regardless of how it is configured. Cisco found the flaw while working a Technical Assistance Center support case, which means it was not surfaced by an external researcher or a bug bounty submission.

The fixes are already out. Cisco lists first fixed releases of 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4. Teams still running ISE 3.0 have a harder problem: that release has reached end of software maintenance, and Cisco's advice is to migrate to a supported version rather than expect a patch. There are no workarounds. The nearest thing to a temporary hold is an infrastructure access control list that permits only the management and control plane traffic your deployment actually needs to reach the appliance.

Is anyone exploiting it?

Cisco says so directly: “The Cisco PSIRT is aware of active exploitation of this vulnerability.” That is the whole of the disclosure. The advisory gives no victim names, no description of the attacks, no attribution and no technique detail beyond the vulnerability itself.

What Cisco does supply is a warning about what exploitation leaves behind. An attacker who gets in may end up with root privileges on the appliance, and at that level of access “evidence of exploitation and indicators of compromise may be removed or hidden”. Cisco's suggested starting point is the access log, looking for suspicious usernames, and it says the check should be run on every node in a distributed deployment. Administrators are also told to cross-check network and firewall logs held elsewhere, because “the device itself may not be a reliable witness”. Where malicious activity is suspected, Cisco recommends re-imaging the affected nodes and restoring from configuration backup.

Why is CISA involved?

CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities catalogue on 16 September 2026. US federal civilian agencies have until 19 September to remediate it, and the entry carries a forensic triage requirement, which is CISA's way of saying that simply patching may not be enough if an attacker has already been inside.

The catalogue entry sits under Binding Operational Directive 26-04, the risk-based patching directive CISA published in June 2026. It is the same shift that saw the agency retire its weekly vulnerability bulletin at the end of this month: instead of treating every disclosed bug as equally urgent, CISA now scores urgency on exposure, known exploitation, how automatable the attack is and how much control an attacker gains. A 10.0 that is being exploited in the wild, on the appliance that gates network access, tops that calculation by every measure.

What should administrators do?

Four things, in order. Work out how many ISE and ISE-PIC nodes you run and how many of them are reachable from anywhere but a management network, because that is the number that decides your exposure. Apply the fixed patch for your release, or start the migration off 3.0. Tighten the infrastructure ACLs in the meantime, since that is the only mitigation Cisco offers. Then read the access logs on every node, and remember that a clean log on an appliance with root-level compromise is not proof of anything.

Our opinion

A 10.0 is easy to be cynical about. Vendor scoring has drifted upward for years, and a perfect score does not automatically mean a perfect catastrophe. This one earns it, though, for a specific reason: nothing needs to go right for the attacker. No credentials, no user who clicks the wrong thing, no race condition, just a crafted request to an API on the box that decides who gets on the network.

The detail that should worry administrators most is not the score — it is the log guidance. When a vendor writes that evidence may be hidden because intruders can reach root, and then suggests checking your firewall logs instead of your own appliance, it is telling you that the usual post-incident routine is not sufficient here. The forensic triage flag on CISA's entry says the same thing in policy language.

There is also a quieter lesson in how this arrived. Cisco found the bug while resolving a support case, which is a reminder that a good number of the serious flaws in the security products we rely on are discovered by the people running them, after something has already gone wrong. Patch the patches too: an appliance that gates access to everything else deserves the same attention you give your firewalls.