Attackers Are Bypassing Cisco ISE’s Login and a Clean Log May Not Mean You’re Safe
A platform that decides who is allowed onto a network has become an urgent question of trust itself. Cisco confirms that attackers are exploiting a login-bypass vulnerability in Identity Services Engine. The immediate job is to remove the exposure. The harder one is deciding whether an affected node has already been altered.
CVE-2026-76460 is rated 10.0. Cisco’s 16 September advisory describes insufficient authentication on an API endpoint in ISE and ISE Passive Identity Connector (ISE-PIC), irrespective of configuration. A remote attacker without credentials can send a crafted request and bypass the web management interface. Cisco reports active exploitation, not merely a laboratory possibility.
CISA’s official Known Exploited Vulnerabilities feed records an addition on 16 September and a 19 September remediation deadline for US federal civilian executive branch agencies. That federal deadline is not a universal legal obligation. It is nevertheless a useful urgency signal for other organisations with affected deployments.
Close the flaw without confusing it with recovery
There is no workaround that fixes the vulnerability. Cisco does describe infrastructure access-control lists as a temporary way to limit remote exposure to required management and control-plane traffic. That restriction is a mitigation, not a substitute for fixed software.
| ISE release | 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 |
The companion hardening advisory adds important lifecycle context. ISE 3.0 and earlier need migration to a fixed release. Branches 3.1 and 3.2 receive only critical security fixes in their maintenance phase; Cisco advises moving to a supported release with all hardening improvements. ISE-PIC’s last supported branch is 3.4. Do not read the ISE 3.5 row as an instruction to deploy an unsupported ISE-PIC release.
A clean appliance log is not a clean bill of health
Cisco says exploitation may lead to root command execution, allowing local evidence to be concealed or removed. It recommends checking access logs on every node and independently checking network and firewall records. Suspicion of malicious activity warrants re-imaging affected nodes and restoring configuration where needed.
For incident responders, the distinction is consequential: a patched node and a trusted node are different assertions. The first concerns the installed build. The second concerns what happened before that build was installed. A deployment ticket can establish the former without answering the latter.
BlackTree’s practical recommendation is to give those assertions separate owners and closure criteria. The infrastructure team should record the actual build on each node after the change. The response team should record the exposure window, available independent telemetry, suspicious activity and the confidence limits of its investigation. Neither team should be asked to certify what its evidence cannot show.
What the response ticket should contain
- A complete node inventory. Include the product, branch, build, role and accountable owner. A distributed deployment needs a per-node result, not a single platform-level green tick.
- An exposure assessment. Establish which networks and hosts could reach management and control-plane interfaces during the vulnerable period. Document any uncertainty rather than assuming that an internal address is unreachable.
- A supported upgrade plan. Check compatibility, backup availability and the vendor’s deployment guidance. Verify the resulting running build, not just the installer exit status.
- An evidence-preservation decision. Agree with the response team what to retain before replacement or re-imaging. Store relevant collected records outside the potentially affected appliance.
- A separate compromise assessment. Correlate local observations with independently held connection records. Escalate suspicious findings instead of closing the incident because patch installation succeeded.
- A recovery and validation record. Where compromise is suspected, follow Cisco’s recovery guidance with qualified responders. Validate service operation and monitoring after recovery, and retain the reasons for the decision.
These are BlackTree’s suggested operational checks, not a claim that every installation has been compromised. The public advisory does not establish a named actor, a victim count or a campaign’s geographical reach. Active exploitation justifies urgent attention to CVE-2026-76460; it does not supply evidence about a particular organisation.
The wider release is not a list of confirmed attacks
Cisco’s separate hardening release groups internally found issues by weakness class. It explicitly singles out the authentication-bypass issue as exploited and says it is not aware of malicious use of the others except as noted. Those grouped identifiers do not establish an equal number of separate bugs or exploited attack paths. The same release also addresses more than the headline flaw, making the vendor’s complete upgrade guidance the appropriate reference.
| Grouped identifier | Class | Maximum CVSS score |
|---|---|---|
| CVE-2026-20130 | Injection | 10.0 |
| CVE-2026-20192 | Access control | 10.0 |
| CVE-2026-20194 | Cross-boundary transfer, disclosure and upload | 9.1 |
| CVE-2026-20234 | Credential protection | 9.9 |
| CVE-2026-20237 | Input validation and path control | 9.9 |
| CVE-2026-20287 | Privilege management | 6.5 |
The grouped bulletin does not disclose every underlying issue’s individual prerequisite or affected range. Its shared remediation table is the one above, with the critical-only restriction on older branches already noted. No workaround is reported, and independently verified public exploit code was not established in BlackTree’s review. Neither uncertainty should be presented as proof that exploitation is impossible.
The managerial question is therefore not simply, “Have we installed the patch?” It is, “Which nodes were reachable, what independent evidence survives, and what lets us trust them again?” A control that mediates access deserves an answer grounded in evidence rather than the reassuring colour of a dashboard.
BlackTree’s earlier ISE investigation concerned different June vulnerabilities. It provides product context, not evidence that those cases and this exploited bypass belong to the same campaign.
Sources
- Cisco, Identity Services Engine Authentication Bypass Vulnerability, first published 16 September 2026, including exploitation, fixed releases, mitigation and recovery guidance.
- Cisco, Identity Services Engine Hardening Release: September 2026, including product lifecycle limitations and exploitation boundaries.
- CISA, official Known Exploited Vulnerabilities feed, entry added 16 September 2026.
