Skip to content

Build1 publisher2 min readPublished

Exploited Cisco ISE flaw gives unauthenticated attackers root on the node that grants network access

Cisco confirmed attackers are exploiting CVE-2026-76460, a CVSS 10.0 flaw giving unauthenticated root on Identity Services Engine. ISE decides which devices join the network, so a rooted node hands over every access decision and the device credentials it stores.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

Illustration accompanying Exploited Cisco ISE flaw gives unauthenticated attackers root on the node that grants network access
Generated illustration

What happened

  • CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities catalog on September 16, giving federal civilian agencies until September 19 to remediate.
  • The bug is CWE-648: an API endpoint behind the ISE management interface does not enforce authentication, so a crafted request bypasses the web login entirely.
  • Cisco says the flaw does not depend on configuration and has no software workaround; its only interim measure is an infrastructure ACL on management and control-plane traffic.
  • Where compromise is confirmed or suspected, Cisco says to reimage the node and restore configuration from a known-good backup, because cleaning it in place is unsupported.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • exposure Downstream identity-based authorisation and logging keep working normally on forged ISE decisions, so an intrusion can pass through the audit trail with nothing that looks out of place.
  • cost Any node exposed to the internet or a broad internal segment commits its owner to rotating every credential ISE holds and re-checking administrator accounts and TOTP enrolments.
  • constraint Sites still on ISE 3.0 have to finish a migration to a supported release before a fix exists for them, so their patch date depends on a migration project.

The bypass sits in front of the login. That means each node's exposure comes down to who can reach its management interface. A dev.to write-up summarising Cisco's advisory recommends listing every ISE and ISE-PIC node and checking which ones accept management traffic from anything wider than a tightly scoped administrative network [16]. The infrastructure ACL does not change the vulnerable code. According to the write-up, it removes the unauthenticated reachability the exploit needs, and it is the measure to apply while a change window is arranged [14].

The fix shipped in Cisco's September 16 batch, which covered 77 CVEs [1]. All supported configurations are affected, and Cisco cut the fixes per maintenance branch [8]. The write-up does not list the fixed builds. Its warning is about inventories. The fix lands at the patch number, so an asset record that stores only the major version cannot say whether a node is safe [17].

Cisco's detection step is a filter on the ise-kong access log. Cisco says to run it on every node in a distributed deployment, because an attacker can target any reachable node [10]:

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

Cisco says any output from that filter is potentially indicative of malicious activity [10].

The same advisory says an attacker with root can delete or hide evidence, local logs included [11]. A check that asks a compromised host to testify about itself has an obvious limit, and Cisco put that limit in writing [11]. The write-up's answer is to correlate upstream firewall and network logs for unusual uploads, downloads or outbound connections from ISE nodes. It also says to treat an empty local log as inconclusive [12].

I think the scope of recovery should follow reachability. ISE stores management credentials for the devices it governs, shared secrets, and machine accounts joined to Active Directory [5]. Take any node whose management interface answered to more than the admin network during the exposure window. I'd assume those secrets were read, because the node's own logs cannot rule it out [11]. A node reachable only from a locked-down administrative segment is a different case. For that one I'd limit the response to the upgrade and the upstream log review [12].

What to watch

  • Whether Cisco or CISA publish indicators beyond the dummyuser filter, such as source addresses, that teams can match against upstream firewall logs.
  • Reports showing whether attackers have pulled device credentials or Active Directory machine accounts off compromised ISE nodes.
  • Whether Cisco offers ISE 3.0 customers any route to a fix short of migrating to a supported branch.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories