Petri reported the vulnerability and patching guidance on September 21. Cisco’s advisory establishes the important operational distinction: administrators must address both the vulnerable software and the possibility that a device has already been compromised. Installing a fix closes the documented vulnerability; it does not establish that an appliance is free of an existing intrusion.
What the authentication bypass allows
The flaw lies in insufficient authentication controls on an ISE API endpoint. According to Cisco, a remote attacker can send a crafted request to that endpoint and gain unauthorized access to the affected device by bypassing the web-based management interface. Cisco assigns the vulnerability a CVSS 3.1 base score of 10.0, reflecting a network-accessible attack with low complexity, no required privileges, and no required user interaction.
This is particularly significant for a platform used to manage network authentication and access policies. The vulnerable boundary is access to the ISE appliance itself, rather than a requirement to obtain a legitimate administrator’s password.
Cisco also warns that successful exploitation may give an attacker command execution with root privileges. That affects how defenders should interpret evidence: an attacker with that access may remove or hide traces of exploitation. Clean local logs cannot rule out compromise, which is why Cisco recommends checking network and firewall logs outside the affected device.
The affected products are ISE and ISE-PIC, regardless of device configuration. Administrators should not assume that an otherwise typical or hardened configuration exempts an unpatched installation. Network reachability still matters to exposure, but restricting reachability does not repair the vulnerable endpoint.
Which releases contain the fix?
Cisco lists the following first fixed releases for both ISE and ISE-PIC. The patch number matters: identifying an installation simply as “ISE 3.4,” for example, is insufficient to establish whether it contains the fix.
| Installed release family | First fixed release |
|---|---|
| 3.1 | 3.1 Patch 12 |
| 3.2 | 3.2 Patch 11 |
| 3.3 | 3.3 Patch 12 |
| 3.4 | 3.4 Patch 7 |
| 3.5 | 3.5 Patch 4 |
Cisco ISE 3.0 has reached end of software maintenance. Cisco advises customers on that release to migrate to a supported release containing the fix rather than expect a corresponding 3.0 patch.
For deployment planning, the practical sequence is:
- Inventory ISE and ISE-PIC installations, recording the exact release and patch level across the deployment.
- Select the appropriate fixed release for each installation. Before upgrading, confirm that the target release supports the existing hardware and software configuration and that the device has sufficient memory, as Cisco advises.
- Apply the fixed software through the upgrade process appropriate to that release and deployment.
- Verify the installed release and patch level against the fixed-release table.
Cisco’s advisory does not provide a universal installation command or distributed-node upgrade sequence. Those details depend on the deployment, so this table establishes the remediation target rather than a complete upgrade runbook.
Reduce exposure while arranging the upgrade
Cisco states that there is no workaround that addresses the vulnerability. It does, however, identify a temporary mitigation: use infrastructure access-control lists, or iACLs, to allow only required management and control-plane traffic destined for the affected device.
The distinction is practical. An access-control list limits which systems can reach the appliance; a software update corrects the authentication flaw. Organizations should restrict unnecessary access while arranging the update, preserving traffic needed for legitimate management and operation.
Do not interpret an internal-only management interface as proof that an unpatched appliance is safe. The relevant exposure question is which systems can reach the affected service, not simply whether it is directly reachable from the public internet.
Review every node for signs of exploitation
Cisco directs administrators to examine access logs for suspicious usernames and to repeat the review on every node in a distributed deployment. Its advisory provides this non-exhaustive example:
show logging application ise-kong/access.log | include dummyuser
The command filters the application access log for the example username dummyuser. Cisco says entries returned by this example may indicate malicious activity. It is not a comprehensive detection rule: an empty result means only that the filter found no matching entries in that log, not that exploitation did not occur.
A supported investigation should include these steps:
- Review
ise-kong/access.logfor suspicious usernames on each node, rather than treating one node’s results as representative of the deployment. - When additional access logs are needed, collect a support bundle with include debug logs selected and use shared-key encryption. After decrypting the bundle, locate the access logs under
./ise/logs/apigateway/. - Cross-check external network and firewall records. Cisco specifically highlights unexpected uploads initiated by the appliance to external IP addresses and downloads from malicious IP addresses.
- If malicious activity is suspected, follow Cisco’s recommendation to re-image affected nodes and restore from a configuration backup if needed.
Re-imaging is a consequential recovery action, separate from ordinary patch installation. Before restoring a configuration, establish that the chosen backup is suitable for recovery rather than assuming the newest backup predates the intrusion.
The response therefore has two parallel tracks: move every affected installation to fixed software, and investigate possible exploitation using evidence that extends beyond the appliance. Where compromise is suspected, Cisco’s recommended recovery is re-imaging—not relying on patching alone to remove an attacker’s foothold.