Root on the Gatekeeper: Cisco ISE CVE-2026-76460 and the Logs That Delete Themselves

Cisco did not find CVE-2026-76460 in a fuzzing harness. It found the bug while working a TAC support case.

Sit with that for a second. Somebody phoned Cisco support about their Identity Services Engine behaving oddly, an engineer pulled the thread, and at the other end of it was an unauthenticated remote code execution path scoring a clean 10.0 on CVSS. By the time the advisory went out on 16 September 2026, Cisco PSIRT was already saying it was "aware of active exploitation." CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies three days to patch under BOD 26-04. KEV deadlines are usually measured in weeks.

I have spent most of my career building detections for other people's networks, and the advisory line that made me put my coffee down was not the CVSS score. It was this: an attacker with this bug gets command execution as root, which Cisco notes lets them "hide or delete indicators of compromise."

Your access control system is also your witness. This bug compromises both at once.

The mechanics are almost insultingly simple

Cisco's advisory (cisco-sa-ISE-ABP-VNSW7Tn5) puts the root cause in one clause: insufficient authentication control on an API endpoint. There is no chain here, no heap grooming, no race window. A remote attacker who has never authenticated sends a crafted request straight to an exposed API endpoint, walks around the web-based management interface entirely, and lands as root on the underlying OS.

Releases 3.1 through 3.5 are affected. So is the ISE Passive Identity Connector, and so is every deployment regardless of configuration. That last phrase kills the usual triage shortcut. You cannot read your own config and rule yourself out.

Fixed builds are 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4. There is no workaround. Cisco's only interim suggestion is infrastructure ACLs restricting management traffic to trusted subnets, which works, and which most shops believe they already have in place right up until someone runs an actual scan of the management VLAN.

CVE-2026-76460 did not arrive alone. Cisco shipped a batch of ISE advisories the same day covering more critical bugs: CVE-2026-76423, another CVSS 10.0 REST API authentication bypass granting admin access; CVE-2026-20307 at 9.9 for insecure Java deserialization through the web interface; CVE-2026-20305 and CVE-2026-20284 at 9.1 for command injection and SXP REST API SQL injection. Cisco credits its own internal security testing for those, and its advisory language says the testing used "existing testing processes as well as frontier AI models." Read that as a signal about cadence. If AI-assisted internal review is now finding 10.0s in a mature product on a maintenance schedule, the flow of ISE advisories is not going back to the old rate.

What ISE actually holds

Here is where the CVSS number undersells the incident.

A vulnerable web app usually gives an attacker the app's data. An identity appliance gives them everybody else's. Think about what is sitting in an ISE deployment on any given Tuesday:

• An Active Directory join account, because ISE has to bind to your domain to do machine authentication.
• RADIUS and TACACS+ shared secrets for every network device you own. Switches, WLCs, firewalls, out-of-band consoles.
• Device admin credentials and enable passwords for TACACS+ authorisation.
• SNMP community strings for profiling.
• pxGrid and MDM integration credentials, which is to say API keys into your EDR, your firewall manager and your mobility platform.
• An internal certificate authority issuing EAP-TLS certs to endpoints.
• ERS API service accounts, usually created once during a deployment project and never rotated since.

Root on that box is not a foothold. It is a credential harvest with a policy engine attached. And because the attacker also controls authorisation decisions, they can quietly add their own MAC address to an authorisation profile that drops them onto a server VLAN, no exploit required for the second hop. The policy engine will happily do it, and the resulting session looks completely legitimate downstream. That is the same shape I wrote about when CVE-2026-59310 let attackers mint vpxuser sessions on vCenter: own the control plane, and every identity it vouches for becomes yours to issue.

Palo Alto Networks Unit 42 put identity weaknesses in 89 percent of the incidents it responded to across more than 750 engagements in its Global Incident Response Report 2026, with identity-based techniques driving 65 percent of initial access. Appliances like ISE are why that ratio keeps climbing. You do not need to phish 400 people if you can own the machine that decides who the 400 people are.

The detection problem nobody wants to say out loud

Cisco's hunting guidance for this CVE is short. Review the access log on every node in a distributed deployment for suspicious usernames. Reporting on the advisory calls out dummyuser specifically as an artefact worth grepping for. Then cross-check network and firewall logs from outside the device for anomalies like unexpected uploads or downloads.

That second instruction is the tell. Cisco is telling you not to trust the box's own telemetry, because the exploit grants root and root can rewrite logs. And Cisco's remediation advice closes the loop: "If malicious activity is suspected, it is strongly recommended to re-image the affected nodes and restore from configuration backup if needed."

Now map that onto how most SOCs are actually built. ISE is a log source. It ships RADIUS accounting, authentication passed and failed events, and posture results into your SIEM, and those events are treated as ground truth for network access. Detection engineers write correlation rules on top of them. "Alert when a corporate asset authenticates from an unexpected VLAN." "Alert on MAB authentication for an unknown endpoint."

Every one of those rules has an unstated assumption: that ISE is telling the truth. When the attacker has root on the appliance, the SIEM is not blind, which would at least be obvious. The SIEM is being lied to with high confidence and a clean timestamp. That is worse. Blind gaps get noticed during a hunt. Confident false data gets used to close tickets.

I have watched an IR team spend a full day arguing that lateral movement could not have happened because the NAC logs showed no new authorisations. The logs were fine. The appliance writing them was not.

This is the same failure mode as the SharePoint forged-JWT bug where no login event ever fired, and the same one behind FortiBleed's 86,644 working credentials pulled straight out of appliance storage. Different vendors, one pattern: the security device is inside its own trust boundary, so its evidence is only as honest as its patch level.

Fourteen months, two maximum-severity pre-auth bugs

This is not ISE's first CVSS 10.0.

In June and July 2025, CVE-2025-20281 and CVE-2025-20337 gave unauthenticated attackers root through a crafted API request, the same broad shape as today's bug. Trend Micro's Zero Day Initiative reported them, and ZDI's Dustin Childs said researchers observed active exploitation of CVE-2025-20281 on 17 July 2025, with proof-of-concept code public since 27 June. Cisco confirmed attempted exploitation on 21 July. CISA added both to KEV on 28 July 2025.

Two maximum-severity pre-auth API bugs in the same product family inside fourteen months, both exploited, both reachable without credentials. The common denominator is the API surface. ISE grew a REST and ERS API layer for automation, that layer sits on the same management interface as the admin portal, and network teams expose that interface far more widely than they would ever admit in a design review.

If your ISE admin nodes are reachable from a user VLAN, from a site-to-site VPN peer, or from a jump host that 40 people share, you should be planning for the next one of these rather than closing the book on this one.

Where deception earns its place here

I am not going to pretend a decoy would have stopped root exec on an unpatched appliance. It would not. Patching stops that.

What deception fixes is the evidence problem, and it fixes it for exactly the reason Cisco's own guidance implies: the trip signal has to originate somewhere the attacker does not control.

Two placements matter after an appliance compromise like this one. The first is decoy credentials salted into the places an attacker looks once they have root and start hunting for reusable secrets: config exports, backup shares, the admin workstations used to manage the appliance, and the documentation folders where TACACS+ secrets always end up despite everyone's best intentions. A honeytoken service account that looks exactly like a real network device admin login generates zero events while it sits there and one unambiguous event the moment it is used. No baselining, no tuning window, no false positive to argue about in triage, because there is no legitimate reason for that credential to ever authenticate.

The second is decoy services in the management VLAN itself. Post-exploitation from a NAC appliance means enumeration: the attacker wants to know what else answers on those subnets. MineField's decoy TCP listeners answer, and the connection attempt is logged by the decoy, not by the compromised box. That distinction is the whole point. When your primary log source is suspect, a detection that fires from independent infrastructure is the only kind you can still reason about.

There is an edge case worth naming. If you run an ISE guest or sponsor portal, seed a sponsor account that no real person uses and watch for authentications against it. Attackers who land on ISE routinely browse the identity stores looking for accounts with portal access, because those often survive the incident and the password reset sweep that follows.

The next four hours

Patch to 3.1 P12, 3.2 P11, 3.3 P12, 3.4 P7 or 3.5 P4. Then, and this is the step I see skipped on nearly every appliance incident: treat every secret the appliance held as burned. The patch closes the door. It does not rotate the AD join account, the TACACS+ shared secrets, the pxGrid keys, the ERS service accounts or the internal CA. An attacker who was in before Wednesday still has all of it, and unlike the exploit, those credentials leave no trace when reused. Pull firewall and NetFlow records from outside the appliance for the exposure window rather than relying on what the node says about itself, grep every node's access log for unfamiliar usernames, and if anything looks wrong, take Cisco's advice and re-image.

The uncomfortable truth in this advisory is that the fastest detection anybody got came from a support ticket. If you want to find out you have been breached before your vendor's TAC engineer does, you need a tripwire that does not live on the thing being attacked, and a short walkthrough of what that looks like in a real management VLAN is the quickest way to judge whether it fits yours.