CVE-2026-76460: ISE API authentication bypass, exploited as a zero-day

What it is

An API endpoint in Cisco Identity Services Engine (ISE) doesn’t check authentication properly (CWE-648). An unauthenticated attacker on the network can send a crafted request to it and bypass authentication on the web-based management interface. Cisco rates it CVSS 10.0.

Cisco says successful exploitation can lead to command execution as root. It hasn’t said how the bypass leads to root, and it hasn’t said who is exploiting it. Cisco found the bug while resolving a TAC support case. It says it is aware of active exploitation, and CISA added the CVE to the KEV catalog the day the advisory came out.

ISE usually sits at the centre of network access control: it holds policy, endpoint identities and often credentials for directory and device integrations. A compromised node is a strong foothold.

Am I affected?

Probably yes, if you run ISE or ISE-PIC at all. Cisco says the issue affects both products regardless of device configuration, and gives no config check. Any node on a release older than the fixed release for its train is vulnerable.

Train	First fixed release
3.5	3.5 Patch 4
3.4	3.4 Patch 7
3.3	3.3 Patch 12
3.2	3.2 Patch 11
3.1	3.1 Patch 12

Cisco’s footnote says ISE 3.0 has reached End of Software Maintenance and recommends moving to a supported release. Treat 3.0 as unpatched.

The CVE record lists specific patch levels as affected (for example 3.3 Patches 1 to 11 and 3.5 Patches 1 to 3). The advisory is the reference: anything below the first fixed release in your train needs the upgrade.

What to do

1. Upgrade every ISE and ISE-PIC node to the first fixed release for your train, or later. Follow the upgrade guides on Cisco’s ISE support page.
2. Restrict access until you’ve patched. There is no workaround. Cisco’s only mitigation is to use infrastructure access control lists (iACLs) so only required management and control plane traffic reaches the device. This is temporary, not a fix. CISA’s KEV entry tells federal agencies to apply Cisco’s mitigations under BOD 26-04.
3. Review the logs before and after patching (see Detection). Patching doesn’t remove an attacker who is already in.
4. If you suspect compromise, re-image the affected nodes and restore from a configuration backup if needed. Cisco recommends this because root access lets an attacker hide evidence. Assume secrets stored on or reachable from ISE are exposed and plan to rotate them.

Detection

Cisco has published no attacker IP addresses, accounts or file hashes, and none of the reports we reviewed list any. No researcher analysis or public proof of concept has been published. What Cisco does give:

• Review access.log on every node for suspicious usernames. Cisco’s example command, which is non-exhaustive:

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

dummyuser is Cisco’s placeholder, not an observed attacker account. Any output from a search like this may indicate malicious activity. Look for usernames and source addresses you don’t recognise.

• To get more access.log files: collect a support bundle with include debug logs selected and shared key encryption. After decrypting it, the logs are under ./ise/logs/apigateway/ (access.log and rotated .gz copies).
• Check network and firewall logs outside the device for unexpected uploads from ISE to external IP addresses, and downloads from malicious IP addresses.
• Logs on the node itself may be incomplete if the attacker gained root and cleaned up, so rely on external logs too.