Running Cisco ISE? Here’s Your Action Plan for the CVSS 10.0 Flaw Under Attack

If your business runs Cisco Identity Services Engine, act now. The new Cisco ISE patch is not optional homework for next quarter. Cisco confirmed that attackers were exploiting the underlying flaw, CVE-2026-76460, before any fix existed. The bug scores a maximum 10.0 on the CVSS scale, the highest rating there is. Here is what it means for your network, and what to do about it, in order.

Why this one is different

Plenty of advisories land in an inbox and wait for the next patch window. This is not one of them. ISE decides which devices are allowed onto your network in the first place. A flaw that lets an attacker with no login seize control of it is not a routine bug. Cisco says the issue sits in an API endpoint that failed to enforce proper authentication. An attacker could send a single crafted request and walk straight past the web-based management login. From there, Cisco warns, an attacker can reach root-level command execution on the appliance.

ISE holds the keys to network access policy. That level of control does not stay contained to one box. Root access lets an attacker “modify that policy, extract stored credentials, delete logs, and move laterally into every network segment ISE controls,” said Landon Rice, a senior exploit developer at VulnCheck. Treat this as a network-wide incident risk, not an appliance-level one.

The U.S. government’s cyber agency, CISA, treated it that way too. It added CVE-2026-76460 to its Known Exploited Vulnerabilities list on 16 September. Federal agencies have until 19 September, just three days, to patch. UK organisations are not covered by that directive. But the timeline it implies is worth borrowing: this is a this-week job, not a next-change-window job.

Step one: work out what you are running

Check the ISE and ISE-PIC version on every deployed node. The affected range spans releases 3.1 through 3.5, plus the now end-of-life 3.0. Cisco says the flaw affects every deployment, whatever its setup. So do not assume a hardening step protects you; the version number is the only reliable filter. If anything is still on 3.0, there is no patch coming for it. Plan a migration to a supported release instead of waiting on a fix.

Step two: apply the Cisco ISE patch

Cisco has published a fixed version for every supported branch. The fixes are 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4. No workaround removes the underlying flaw. Blocking outside access to the management interface with an iACL cuts exposure while you schedule the upgrade. But it is a stopgap, not a fix. Patch as soon as your change process allows. Treat “as soon as possible” as days, not the usual monthly cycle.

Step three: assume it may already have happened

Attacks began before the patch was public. That means a clean upgrade does not automatically mean a clean box. The Cisco ISE patch alone will not tell you whether you were already hit. Cisco’s own guidance points admins to the access log with this command:

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

That surfaces the kind of suspicious usernames seen when attackers tried this. If you find anything that looks like it, do not just patch and move on. Cisco’s advice, and good practice generally, is to treat the appliance as compromised. Re-image it from a known-good backup. Do not trust that a patch alone removed an attacker who already had root.

Step four: look at the wider pattern

This is the third maximum-severity, actively exploited flaw in ISE in a little over a year. Two earlier ones, CVE-2025-20281 and CVE-2025-20337, hit last summer. Two days before this advisory, Cisco also disclosed a separate exploited zero-day in Secure Email Gateway. It is one of several recent Cisco, Citrix and Fortinet bugs under active attack this year. Cisco says the ISE and email gateway issues are unrelated beyond a similar CVE number.

That pattern is worth acting on beyond this one Cisco ISE patch. Check whether the ISE management interface is reachable from anywhere it does not strictly need to be. Tighten that now, not just this month’s fix. Organisations that already run regular penetration tests against their perimeter and internal segmentation should ask a specific question: was an identity system like ISE inside the last test’s scope? A missing answer is a reasonable trigger to add it.

Step five: tell the people who need to know

Patching quietly is tempting. But a flaw this severe deserves a short, plain note to whoever owns risk decisions at your business. That might be a board member, an outsourced IT provider or an external auditor. Say what the flaw is, what you have done about it, and what you are still checking. If a third party manages your network access systems, ask them directly this week. Did they apply the Cisco ISE patch, and did they check for prior compromise? Do not assume a managed service provider already did either just because they usually handle patching.

A short checklist

• Confirm every ISE and ISE-PIC node’s current version and patch level.
• Apply the Cisco ISE patch for your branch: 3.1 Patch 12 through 3.5 Patch 4.
• Plan a migration off ISE 3.0, which has no fix coming.
• Where an immediate patch is not possible, restrict management interface access with an iACL as a temporary measure.
• Check access.log for suspicious usernames before assuming a clean upgrade.
• Re-image any node showing signs of prior compromise rather than patching in place.
• Review whether your identity systems sit inside the scope of your next penetration test