CVE-2026-76460: CVSS 10.0 Cisco ISE Auth Bypass to Root, Actively Exploited, in CISA KEV
CVE-2026-76460 is about as severe as a CVE score gets, CVSS 10.0, and it is already being actively exploited against Cisco Identity Services Engine (ISE) and ISE-PIC deployments. Cisco published its advisory on September 16, 2026, confirmed PSIRT awareness of active exploitation at disclosure, and CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation due date of September 19, just three days later, one of the shortest windows CISA has issued this year. If you run ISE anywhere in your environment, this is not a patch to schedule for the next maintenance cycle.
What the flaw actually is
Cisco classifies this as CWE-648, incorrect use of privileged APIs. In practice, an API endpoint on ISE has insufficient authentication controls, allowing an unauthenticated remote attacker to send a specially crafted HTTP request directly to that endpoint and bypass authentication entirely. Once past that check, the attacker can gain privileged access and ultimately execute commands with root privileges on the appliance. This affects both ISE and ISE-PIC, and it affects them regardless of device configuration, there is no hardening setting, feature toggle, or deployment mode that sidesteps the exposure. Cisco has confirmed there is no workaround. Patching is the only remediation.
Why ISE specifically makes this so severe
Identity Services Engine is not a peripheral appliance, it is the policy engine that many enterprise networks use to control network access, enforce 802.1X authentication, and make trust decisions about which devices and users get onto which segments of the network. Root-level compromise of ISE gives an attacker access to identity and configuration data underpinning your network access control decisions, and a foothold that could be used to manipulate those decisions going forward, not just a single compromised box. An unauthenticated, root-level compromise of the system that decides who gets network access is close to the worst-case scenario for a network access control deployment.
Patch versions
Cisco’s first fixed releases for each affected branch:
- 3.1 Patch 12
- 3.2 Patch 11
- 3.3 Patch 12
- 3.4 Patch 7
- 3.5 Patch 4
Identify your current ISE version and apply the corresponding patch for your branch immediately. Given confirmed active exploitation and the absence of any workaround, this should be treated as an emergency change, not something routed through a normal multi-week change control cycle.
Check for pre-patch compromise before you consider this closed
Because active exploitation was already occurring before the patch existed, applying the patch alone does not tell you whether your specific deployment was already compromised. Forensic triage is genuinely warranted here, not just patching:
- Review the
ise-kong/access.logon your ISE nodes for suspicious usernames or request patterns that do not match your normal administrative activity. - Cross-check external firewall logs, NetFlow data, and proxy telemetry for unexpected outbound connections originating from your ISE appliances, including unusual uploads or downloads, which can indicate data exfiltration or tooling staged on a compromised node.
- If you find anything suspicious in either check, treat it as a confirmed compromise investigation, not a false-positive to dismiss, given the severity and confirmed exploitation of this specific flaw.
Frequently asked questions
Is there any interim mitigation if I cannot patch immediately?
Cisco has stated there is no workaround for this vulnerability. Restricting network access to the ISE management and API interfaces to only trusted, necessary sources reduces exposure in general, but it is not a substitute for patching and should not be treated as sufficient on its own given confirmed active exploitation.
Does this affect ISE regardless of how it is deployed or configured?
Yes. Cisco’s advisory confirms the vulnerability affects ISE and ISE-PIC regardless of device configuration, there is no specific feature or setting whose absence or presence changes your exposure.
Why is the CISA remediation deadline so much shorter than usual?
CISA sets Known Exploited Vulnerabilities Catalog remediation deadlines based on confirmed real-world exploitation and severity. A CVSS 10.0 score combined with confirmed active exploitation against a widely deployed identity and network access control product justifies treating this with more urgency than a typical KEV entry, hence the compressed timeline.
