Actively Exploited Cisco ISE Flaw Can Give Attackers Root Access

A critical vulnerability in Cisco Identity Services Engine is being exploited in real-world attacks, allowing an unauthenticated attacker to get past the authentication protecting affected systems and potentially execute commands with root privileges.

Tracked as CVE-2026-76460, the vulnerability carries the maximum CVSS score of 10.0 and affects Cisco Identity Services Engine, or ISE, as well as ISE Passive Identity Connector.

The vulnerability sits in an API endpoint that does not properly enforce authentication. An attacker who can reach the affected service can send a specially crafted request and bypass the normal authentication protecting the web-based management interface.

No existing ISE account is required. The attack also does not depend on convincing an administrator to open a file, follow a link or approve a login.

If exploitation succeeds, the attacker can move beyond simply reaching the management interface and execute commands as root, giving them the highest level of control over the affected ISE system.

That is particularly serious because ISE is not an ordinary application server. It is commonly positioned at the centre of enterprise identity and network-access decisions, determining which users and devices are allowed onto networks and what they can access once they are connected.

Cisco has confirmed that the vulnerability is already being exploited. CISA has also added CVE-2026-76460 to its Known Exploited Vulnerabilities catalog, moving the issue from a theoretical patching risk to one that organisations need to investigate as a possible compromise.

The attack starts before authentication

The important part of CVE-2026-76460 is where the security failure occurs.

Normally, the management functions of a system such as ISE sit behind authentication. An administrator proves who they are, the system verifies that identity and only then provides access to privileged functionality.

This vulnerability breaks that sequence.

The affected API endpoint does not perform authentication correctly. A remote attacker can craft a request that gets around the authentication protecting the web management interface.

That means the attacker does not first have to steal an administrator password.

They do not need to defeat MFA.

They do not need an existing low-privileged account that can later be escalated.

The vulnerability itself provides the path past authentication.

From there, successful exploitation can lead to command execution with root privileges.

On a Linux-based system, root is the highest level of operating-system privilege. An attacker operating at that level may be able to control the system in ways that would not be possible through an ordinary administrative account.

It also creates a difficult incident-response problem.

An attacker with root control may be able to modify or remove local evidence of what happened. Cisco specifically warns that successful exploitation could allow an attacker to conceal activity on the affected system.

So patching the vulnerability answers one question: can the same flaw still be exploited?

It does not necessarily answer another: was this system exploited before it was patched?

Why Cisco ISE makes this vulnerability important

Cisco ISE is used to enforce identity and access policies across enterprise networks.

When an employee connects a laptop to a corporate network, a contractor attempts to access a restricted environment or an organisation needs to decide what a particular device should be allowed to reach, ISE can be part of that decision-making process.

It can integrate information about users, devices, authentication and security policies to determine whether access should be granted and what level of access is appropriate.

That makes the system itself a sensitive security component.

Compromising the infrastructure responsible for making access-control decisions is different from compromising an ordinary endpoint. The attacker is gaining control over a system that sits close to the organisation’s identity and network-security architecture.

What an attacker can ultimately achieve from a compromised ISE deployment will depend on how that environment is designed, what systems are connected to it and what additional access becomes available.

There is currently no public evidence showing that every theoretical post-compromise action has been performed in the observed attacks.

But root-level command execution on an identity and network-access system is enough to make previously exposed systems worth investigating rather than simply patching and forgetting.

Affected systems need more than a configuration change

CVE-2026-76460 affects Cisco ISE and ISE-PIC, and the vulnerability is not limited to an unusual optional configuration.

Cisco has released patched versions across the supported ISE branches.

Affected deployments should move to:

• ISE 3.1 Patch 12
• ISE 3.2 Patch 11
• ISE 3.3 Patch 12
• ISE 3.4 Patch 7
• ISE 3.5 Patch 4

ISE 3.0 has reached the end of software maintenance, so organisations still running that branch need to move to a supported release containing the security fix.

There is no workaround that completely fixes the vulnerability.

Restricting which systems can communicate with the ISE management and control plane can reduce exposure. Infrastructure access-control lists can, for example, prevent unnecessary hosts from reaching sensitive interfaces.

That is useful as a containment measure, particularly while patches are being deployed.

It is not a replacement for installing a fixed version.

Patching does not show whether the attacker was already there

For vulnerabilities under active exploitation, remediation has two separate parts.

The first is closing the vulnerability.

The second is determining whether somebody used it while the system was still exposed.

That distinction matters even more with CVE-2026-76460 because successful exploitation can provide root privileges.

Cisco recommends examining the ISE access.log for suspicious usernames associated with exploitation attempts. In distributed environments, logs need to be examined across the relevant ISE nodes rather than assuming activity would appear on only one system.

But local logs should not be the only source of evidence.

If an attacker obtained root access and was able to interfere with information stored on the compromised node, evidence elsewhere in the network becomes much more valuable.

Firewall logs, network-flow records, proxy telemetry and other systems monitoring traffic to and from ISE can provide an independent view of what the device was doing.

Security teams should pay particular attention to unusual outbound connections and unexpected transfers involving an ISE node, especially communication with infrastructure that the system would not normally contact.

The absence of a suspicious entry in a local log should therefore not automatically be treated as proof that exploitation never occurred.

Where evidence indicates that a node may have been compromised, simply installing the patch may not be enough. Cisco recommends re-imaging affected systems and restoring their configuration from a trusted backup where necessary.

We still don’t know who is exploiting it

Active exploitation has been confirmed, but the campaign behind it remains poorly understood.

There is currently no public attribution identifying the threat actor using CVE-2026-76460.

The number of organisations successfully compromised has also not been disclosed.

It is unclear when exploitation began, whether attackers are concentrating on particular industries or regions, or whether the activity belongs to one coordinated campaign or several unrelated attackers exploiting the same vulnerability.

There is also no confirmed evidence connecting the exploitation to ransomware.

Those distinctions matter.

A vulnerability appearing in CISA’s KEV catalog establishes that there is evidence of exploitation. It does not mean every internet-accessible ISE deployment has been compromised, nor does it tell us what attackers did after gaining access.

As more incident-response investigations are completed, that picture may become clearer.

What organisations should check now

The first priority is identifying every ISE and ISE-PIC deployment and determining whether it is running a vulnerable version.

That inventory should include systems that may not be directly exposed to the public internet. Limiting internet exposure reduces attack surface, but it should not be used as a reason to leave an affected system unpatched.

Fixed releases should be deployed as quickly as operational requirements allow.

Management-plane access should also be reviewed. Only systems and administrative networks that genuinely need to communicate with ISE management services should be allowed to do so.

But organisations that had vulnerable systems should not stop after confirming that the patch installed successfully.

They should establish how long each system was vulnerable, review the available ISE logs for suspicious requests or usernames and compare those findings with independent network telemetry.

If unexplained activity is discovered, the investigation should expand beyond the ISE appliance itself.

The important question becomes not only whether someone reached the vulnerable API, but what happened after that access was obtained.

The next evidence will tell us how serious the campaign became

CVE-2026-76460 combines several characteristics defenders generally do not want to see together: remote exploitation, no authentication requirement, no user interaction, root-level impact and confirmed exploitation in the wild.

But there is still a large difference between knowing that a vulnerability is being exploited and understanding the campaign using it.

We do not yet know how long attackers have been exploiting the flaw, how many organisations were compromised or what they did after obtaining control of vulnerable ISE systems.

Those are now the most important unanswered questions.

For organisations running Cisco ISE, however, there is little reason to wait for those answers before acting. The vulnerability has been fixed, exploitation has been confirmed, and a compromised system may not preserve all the evidence needed to show what happened.

The patch closes the authentication bypass. The investigation determines whether somebody got through it first.