Cisco ISE CVE-2026-76460: Auth Bypass to Root on the Identity Authority

On 16 September 2026 CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities catalogue and gave US federal agencies until 19 September to patch or pull the product offline. That is a three-day clock on a CVSS 10.0 flaw, which is CISA's way of saying the exploitation is real, ongoing, and not theoretical. The affected product is Cisco Identity Services Engine — the box that decides who is allowed onto your network at all. An unauthenticated attacker who reaches its API can bypass authentication and run commands as root. There is no workaround. The only fix is a patch.

Losing a web server to a CVSS 10.0 is bad. Losing the appliance that issues the network's identity decisions is a different category of bad, because everything downstream of it trusts what it says.

What CVE-2026-76460 actually is

Cisco describes the flaw as insufficient authentication controls on an API endpoint. In plain terms: a specific set of API requests that should require a valid session don't check for one. A remote, unauthenticated attacker sends a crafted HTTP request to the management interface, the endpoint answers as though the caller were an administrator, and the chain terminates in command execution as root on the underlying appliance (Help Net Security, 17 Sep 2026).

The blast radius is deliberately wide. Cisco states the bug affects Cisco ISE and the ISE Passive Identity Connector (ISE-PIC) across releases 3.0 through 3.5, regardless of device configuration (The Hacker News, 17 Sep 2026). There is no hardening toggle that takes you out of scope, no feature you can disable. If the management API is reachable and the version is vulnerable, you are exposed.

This is not the first time ISE has been the target rather than the guard. In July 2025, attackers exploited a separate ISE zero-day, CVE-2025-20337, to deploy a custom in-memory web shell Cisco later named IdentityAuditAction — a Java implant that ran entirely in memory and evaded the appliance's own detection (BleepingComputer). The precedent matters, because it tells you what a competent actor does once they own an ISE node, and where they hide.

Why an authentication bypass leaves no fingerprint

Here is the operational problem that makes this CVE worse than its CVSS already implies. The attack is an authentication bypass. There is no failed login, no brute-force pattern, no anomalous successful logon for a SIEM to correlate — because the attacker never authenticated. The whole point of the vulnerability is that the identity layer is skipped. The event you would normally hunt for does not exist.

Then it gets worse. Because the exploit lands the attacker at root, the appliance's own logs become attacker-writable. Cisco's own compromise guidance is unusually candid about this. It tells defenders to review access.log on every deployment node for suspicious usernames — and then, in the same breath, to cross-reference network and firewall logs for unexpected uploads to external IP addresses or downloads from malicious ones, precisely because a root-level attacker may have deleted the local evidence (Help Net Security).

Read that again. The vendor is telling you the on-box telemetry cannot be trusted after compromise, and that the surviving evidence lives on the wire.

"Show me the ISE audit log for that window." "It's clean." "Clean because nothing happened, or clean because someone with root edited it?" "…that's the same question, isn't it."

An identity appliance that has been rooted is the one log source you can least afford to believe, because its entire job is to be the authoritative record of who did what. The 2025 in-memory web shell is the proof of concept for evasion: it left nothing on disk to grep for.

The identity authority is the worst box to lose

ISE is not a passive logger. It is the RADIUS/TACACS+ brain and the network-access-control policy engine. It decides whether an endpoint gets onto the corporate VLAN, the quarantine VLAN, or nothing at all. It authorises switch ports and VPN sessions. It holds — or brokers — the credentials and posture rules that gate the network.

An attacker with root on ISE does not merely have a foothold. They have the ability to:

• Authorise rogue endpoints — mint valid network access for devices that should never pass posture.
• Manipulate authentication policy — downgrade or disable MFA and posture checks for chosen accounts (MITRE ATT&CK T1556, Modify Authentication Process).
• Create or elevate accounts on the appliance itself (T1098, Account Manipulation).
• Harvest secrets — RADIUS shared secrets, TACACS+ keys, integration credentials to Active Directory and the CA.

Every one of those actions produces legitimate-looking authentications downstream. Once the identity authority is compromised, "this session authenticated successfully" stops being reassurance and becomes noise. You cannot audit your way out of a compromised auditor. What you have left is behaviour: the traffic the attacker's newly-authorised devices actually generate, and the beacons the rooted appliance itself sends outbound.

Remediation

Treat any internet-reachable or DMZ-reachable ISE running an unpatched 3.0–3.5 release as presumed-compromised until you have hunted and cleared it. The federal deadline was 19 September; the exploitation predates it.

1. Am I affected?

• Check the running version and patch level: on the admin CLI, show version. Any ISE or ISE-PIC node on 3.0–3.5 below the fixed patch (table below) is vulnerable regardless of configuration.
• Determine reachability of the management/API interface. Exploitation is a remote HTTP request to that interface — if it is reachable from an untrusted segment or the internet, you are in the active-exploitation path, not the theoretical one.

2. Patch — exact fixed releases

Cisco provides no workaround. Upgrade to at least the first fixed patch on your branch (Cisco advisory via The Hacker News):

ISE / ISE-PIC branch	First fixed release
3.0 and earlier	No patch — migrate to a fixed branch
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

3. Can't patch this hour? Compensating controls

• Take the management/API interface off any untrusted path now. Restrict administrative and API access to a dedicated management network with strict ACLs; the exploit is a network request, so removing the network path removes the exploit path. This is a stopgap, not a fix — patch behind it.
• Terminate ISE administration behind a bastion; deny direct reachability from user and DMZ segments.

4. Hunt for compromise

On-box evidence is necessary but not sufficient, because root can erase it. Hunt on both planes:

• On the appliance: review access.log on every deployment node for anomalous or dummy usernames — Cisco's own indicator, e.g. show logging application ise-kong/access.log | include dummyuser. Look for unexpected admin accounts and configuration changes (T1070, Indicator Removal — expect gaps where logs were cleared).
• On the wire (the trustworthy plane): hunt for outbound connections from the ISE node itself to never-before-seen ASNs or IPs (T1041/T1567, exfiltration and web-service C2); unexpected file uploads to external addresses; interactive-shell traffic patterns from an appliance that normally only speaks RADIUS/TACACS+/LDAP/SQL. The initial exploit is T1190 (Exploit Public-Facing Application); watch for the 2025-style in-memory web shell, which by design leaves nothing on disk.
• Correlate downstream: sudden authorisation of new or non-compliant endpoints, MFA/posture policy changes, new NADs (network access devices) added to ISE.

5. Eradicate and verify

Cisco's guidance for suspected-compromised nodes is to re-image, not clean — an in-memory implant and root-level tampering make surgical removal unreliable. After re-imaging to a fixed release:

• Rotate everything ISE brokered: RADIUS shared secrets, TACACS+ keys, AD join credentials, PKI/CA integration secrets, admin passwords.
• Invalidate active administrative sessions and API tokens.
• Confirm clean after patch and rotation by watching the wire for a full cycle: the appliance should return to its baseline protocol profile with no outbound anomalies.

Where the wire is the only honest witness

Everything above converges on a single uncomfortable fact: when the box that owns your identity decisions is rooted, its logs are the adversary's to edit, and an authentication bypass means there was never a login to record in the first place. The vendor's own compromise advice — go look at network and firewall logs — is an admission that the only evidence you can trust is the one the attacker cannot reach into. That evidence is the traffic.

This is the case Zero Hunt's AI Traffic Analysis engine was built for. It runs a proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, and application fingerprinting — on the appliance GPU at a 2.7+ Gbit/s baseline, entirely on-prem, with no cloud callback. The application-fingerprinting head knows what an ISE node's normal conversation looks like: RADIUS, TACACS+, LDAP, its database replication. An interactive shell, a beacon to a never-seen ASN, or a file upload leaving that same host is anomalous the moment it appears — while it is happening, not in the next morning's SIEM digest, and regardless of what the appliance's own access.log has been rewritten to say. When the identity authority itself is the compromised asset, behaviour on the wire is the only ground truth left.

Two capabilities close the loop. Because the exploit is a reachability problem — a crafted request that has to reach the management API — Zero Hunt's 10-agent generative pentest answers the question CVSS cannot: is this specific ISE interface reachable from a realistic foothold on your topology, and does the bypass actually land on your build? A change-triggered campaign fires within the hour of a new ISE interface appearing on the perimeter, writes a per-target probe with a local model rather than a public PoC, backtests it in the AI Gym before it touches production, and signs the result — reachable from the DMZ — with an ECDSA evidence chain, proof rather than assumption. And because ISE sits squarely inside NIS2 and DORA scope as critical identity infrastructure, that same finding maps once against all 32 compliance frameworks, signed at write time for the auditor who will ask how you knew.

A CVSS 10.0 on the identity authority is not a patch ticket. It is a question about whether you would even see it — and the honest answer depends on where you are looking when the logs go quiet.