Cisco ISE's Perfect-10 Zero-Day: What CVE-2026-76460 Actually Breaks
A CVSS 10.0 is rare enough that it is worth stopping to understand rather than just patching on autopilot. Here is what actually breaks in Cisco ISE's CVE-2026-76460, why an identity engine is a uniquely bad place for an auth bypass, and the exact log line to check for it.
show ip route | toc (6 sections)
A perfect CVSS score is rare enough that it is worth stopping on rather than scrolling past. On September 18, 2026, Cisco disclosed CVE-2026-76460, an authentication bypass in Identity Services Engine and ISE Passive Identity Connector that scores a full 10.0 out of 10.0. CISA had already added it to the Known Exploited Vulnerabilities catalog two days earlier, on September 16, the same day the flaw became public, which only happens when there is confirmed exploitation rather than a theoretical worry. I do not run ISE in my own home lab, but the underlying idea is exactly the one my own SOC lab keeps circling back to: the system that decides who gets trusted is the single worst place in the whole network for an authentication bypass to live.
What ISE actually is, and why this specific flaw is worse than a normal 10.0
Identity Services Engine is the box a lot of enterprise networks ask before letting a device onto the wire. Plug into a switch port or associate to a wireless SSID, and ISE is frequently the thing deciding, based on 802.1X, RADIUS, or TACACS+, whether you are an employee laptop that gets full access, a contractor that gets a restricted VLAN, or a device that gets bounced to a guest network. That makes it trusted infrastructure in the most literal sense: the rest of the network's access decisions flow from whatever ISE tells them.
An authentication bypass on a system whose entire job is authentication is a special kind of bad, the security equivalent of the lock on the door to the locksmith's own workshop failing. Cisco's advisory describes the root cause as insufficient authentication control on an API endpoint: a request crafted the right way reaches ISE's underlying management API directly, skipping the login screen entirely, and lands with root-level command execution on the appliance. No valid credentials, no session token, no user anywhere in the loop.
Why this earned a full 10.0
A CVSS 10.0 requires every factor that makes a vulnerability worse to line up at the same time, and most real-world flaws are missing at least one of them. This one is not. The attack is reachable over the network rather than requiring local access. It needs no prior authentication, which is the entire point of the bug. It needs no user interaction, no admin clicking a link or opening a file. And the outcome is not a partial win, a bit of data leakage or a service crash, it is complete compromise of confidentiality, integrity, and availability all at once, because root on the box means the attacker can read anything on it, change anything on it, or take it down entirely. Ten out of ten is not a marketing number here. It is what happens when a checklist of "how bad could this get" comes back yes on every single line.
Who is affected, and what actually fixes it
Cisco ISE and ISE-PIC versions 3.1 through 3.5 are affected regardless of configuration, which matters because it means there is no combination of settings that quietly avoids this one. Version 3.0 and earlier are past end of support, so the guidance there is migration rather than a patch. The fixed releases are specific enough to check against your own version string directly.
| Running version | First fixed release |
|---|---|
| 3.0 or earlier | No fix; migrate to a supported release |
| 3.1 | Patch 12 |
| 3.2 | Patch 11 |
| 3.3 | Patch 12 |
| 3.4 | Patch 7 |
| 3.5 | Patch 4 |
This patch train did not ship alone. The same week, Cisco published a broader ISE hardening release addressing several other high-severity issues in the platform, landing in the same patch numbers listed above. The practical lesson is not just "patch CVE-2026-76460," it is "get the whole patch," since stopping at the one CVE that made headlines while quietly carrying the rest forward defeats the point of an emergency change window in the first place.
If you cannot patch tonight
Cisco's guidance for anyone who cannot get a change window immediately is to restrict access to ISE's management interfaces to a trusted management network using infrastructure ACLs, since the flaw depends on network reachability to the vulnerable API endpoint. That buys time. It is not a fix, and it should be treated as a bridge to the actual patch rather than a place to stop.
There is also a specific thing worth checking regardless of whether you have patched yet,
because a patch closes the door without telling you whether someone already walked through it
beforehand. The API gateway underneath ISE's management interface keeps its own access log, and
the check public write-ups on this flaw describe is running
show logging application ise-kong/access.log | include dummyuser
on the appliance and looking for requests carrying usernames that could not belong to a real
login attempt. A legitimate authentication never produces that pattern, so its presence is a
reasonable signal that someone was probing the endpoint this flaw lives on.
The takeaway that outlasts this one CVE
I think about a lot of network security through the lens of my own SOC home lab, and the parallel here is direct even though the scale is completely different. In the design post for that lab, I wrote about a real limitation: the sensors watching for attacks share a machine with the thing being attacked, so a genuine compromise of that host could let an attacker tamper with the very system meant to catch them. ISE is the enterprise-scale version of that same problem. It is infrastructure that makes trust decisions for everything downstream of it, which means a flaw there does not stay contained to one box the way a flaw in an ordinary application server might. Identity and access infrastructure deserves the same patching urgency as anything internet-facing, even though it usually sits quietly on an internal management VLAN and rarely feels like the thing that is about to be someone's headline.
Frequently asked questions
What is Cisco ISE?
Cisco Identity Services Engine is a network access control platform. It is the system a lot of enterprise networks ask before letting a device on the wire: who are you, what group are you in, and what VLAN or ACL should apply to you. It sits in the decision path for 802.1X, RADIUS, and TACACS+ authentication, which means it is trusted infrastructure by design, not just another server.
What is CVE-2026-76460?
It is an authentication bypass on an API endpoint in Cisco ISE and ISE-PIC, versions 3.1 through 3.5. Cisco describes it as insufficient authentication control that lets an unauthenticated remote attacker reach the underlying management API directly, skipping the login step entirely, and end up with root-level command execution on the appliance.
Is CVE-2026-76460 being actively exploited?
Yes. CISA added it to the Known Exploited Vulnerabilities catalog on September 16, 2026, the same day it became public, which CISA only does when there is confirmed exploitation in the wild rather than a theoretical risk. For any organization running the affected versions, that turns this from a patch-on-the-next-cycle item into a patch-now item.
How do I check if my Cisco ISE deployment has been targeted?
Cisco's guidance points at the API gateway's own access log. On the appliance, running
show logging application ise-kong/access.log and searching it for requests with
unexpected or clearly fake usernames is the specific check public write-ups on this flaw
describe, since a real login would never produce that pattern. It is worth checking even if you
have already patched, because patching closes the door but does not tell you whether someone
already walked through it.
What should I do if I cannot patch Cisco ISE right away?
Restrict access to ISE's management interfaces to a trusted management network using infrastructure ACLs, since the flaw requires network reachability to the API endpoint in the first place. That is a mitigation, not a fix: get to the patched release (3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, or 3.5 Patch 4) as soon as your change process allows it.
What does a CVSS score of 10.0 actually mean?
It means every factor that makes a vulnerability worse lines up at once: an attacker does not need to be on your network already, does not need a valid account, does not need a person to click anything, and the result is complete compromise, not just reading some data or crashing a service. A 10.0 is rare precisely because most real vulnerabilities are missing at least one of those conditions. This one was not.