When Cisco’s product security team pushed an emergency advisory on Wednesday, the message was blunt: a flaw in one of the most trusted gatekeepers on the enterprise network, Cisco Identity Services Engine, was already being exploited in the wild, and there was no workaround. For IT teams that rely on ISE to decide who and what gets onto the network, that is the kind of notice that ends a normal Wednesday.

The vulnerability, tracked as CVE-2026-76460, scores a perfect 10.0 on the CVSS severity scale, the maximum possible rating. It stems from insufficient authentication controls on an API endpoint in ISE and its Passive Identity Connector, ISE-PIC. An unauthenticated attacker who sends a single crafted request to that endpoint can walk past the web based management interface entirely and land on the system with root level command execution. From there, attackers can plant persistence, pull data, or erase the very logs an incident response team would use to find them.

“The Cisco PSIRT is aware of active exploitation of this vulnerability,” the company said in its advisory, language Cisco reserves for confirmed attacks, not theoretical risk. The Cybersecurity and Infrastructure Security Agency, or CISA, moved just as fast, adding the flaw to its Known Exploited Vulnerabilities catalog and giving federal agencies until September 19 to patch.

Why This One Cuts Deeper Than a Typical CVE

ISE is not a peripheral tool. It is the system many enterprises use to enforce who connects to the network, what device posture they need, and what segment of the network they are allowed to touch. A flaw that hands an outside attacker root access to that system does not just expose one server. It potentially undermines the access control decisions being made for every device on the network behind it. For organizations that built zero trust segmentation on top of ISE, this is the equivalent of losing the lock on the front gate.

The affected footprint is broad. Every ISE and ISE-PIC deployment, across current supported versions, is exposed until patched.

What Cisco Says to Do Right Now

Cisco has shipped fixes across its supported branches, including 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, and 3.5 Patch 4, and is telling customers there is no interim workaround beyond restricting access. The company’s guidance for IT and security teams breaks down into three immediate moves.

Patch without waiting for a maintenance window. Given active exploitation and no workaround, Cisco and CISA are both treating this as an out of cycle, patch today situation rather than one to queue behind change control review.

Restrict management plane exposure. Until systems are patched, Cisco recommends infrastructure access control lists, known as iACLs, to limit who can even reach the vulnerable API endpoint, cutting off the path of least resistance for opportunistic attackers scanning for exposed instances.

Hunt for signs of prior compromise, not just future risk. Cisco is specifically pointing teams to their ISE access.log files, flagging unusual or placeholder style usernames, “dummyuser” among them, as a known indicator tied to exploitation attempts. Because a successful attacker gets root access, Cisco is also advising that any node showing signs of compromise be re-imaged rather than simply patched, since a root level intruder can leave persistence that a patch alone will not remove.

The Bigger Lesson for IT Leaders

This is the second time in recent memory that Cisco has had to rush a fix for a maximum severity flaw in identity and access infrastructure, the kind of system organizations tend to configure once and rarely revisit. That is precisely the risk. Access control and identity platforms sit deep in the network, are operationally painful to take offline, and are exactly the systems attackers now know to target first, because compromising the gatekeeper compromises everything the gatekeeper was protecting.

For IT and security leaders, the immediate task is patching ISE. The longer term one is auditing how much implicit trust sits behind any single identity or access control system, and building the kind of monitoring that would catch a “dummyuser” login attempt before an advisory tells you to look for it.