Cisco ISE API Authentication Flaw Opens a Remote Path to Root Access

Cisco has released emergency fixes for a critical zero-day vulnerability affecting Identity Services Engine and ISE Passive Identity Connector. The flaw is already being exploited, and successful attacks may lead to command execution with root privileges.

Tracked as CVE-2026-76460, the vulnerability carries the maximum CVSS score of 10.0. It affects Cisco ISE and ISE-PIC regardless of how the products are configured.

Cisco published its advisory at 16:00 GMT on September 16, 2026. On the same date, CISA added the vulnerability to its Known Exploited Vulnerabilities catalog and set a September 19, 2026 remediation deadline for U.S. federal agencies.

There is no complete workaround. Administrators must install the appropriate fixed release and investigate affected appliances for evidence of earlier exploitation.

A Management API Fails to Enforce Authentication

CVE-2026-76460 exists because an ISE API endpoint does not apply adequate authentication controls. Cisco associates the issue with CWE-648, the incorrect use of privileged APIs.

A remote attacker who has not authenticated can send a specially constructed request to an affected appliance. The request can bypass protections around the web-based management interface and provide unauthorized access to the system.

The vulnerability does not require stolen credentials, an existing account, or interaction from an administrator. It is also considered low complexity, meaning exploitation does not depend on unusual race conditions or difficult prerequisites.

Its complete CVSS 3.1 vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:X/RL:X/RC:X

The changed-scope rating reflects consequences extending beyond the initially vulnerable component. Confidentiality, integrity, and availability are all rated as highly affected.

Cisco warns that exploitation may permit command execution as root. At that privilege level, an intruder could modify the appliance, disrupt its operation, or interfere with evidence stored locally. Root access also makes post-incident analysis less reliable because an attacker may delete logs or conceal traces of the intrusion.

Cisco tracks the vulnerability internally as bug CSCww39530. Its advisory identifier is cisco-sa-ISE-ABP-VNSW7Tn5.

Every Supported ISE Release Train Requires a Specific Patch

The vulnerable products are:

• Cisco Identity Services Engine
• Cisco ISE Passive Identity Connector

Cisco says exposure does not depend on device configuration. Organizations should therefore not assume that an unusual deployment mode, disabled feature, or other local setting removes the risk.

The required fixed release depends on the installed software branch:

Installed Cisco ISE or ISE-PIC release	First release containing the fix
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

Administrators running one of these branches should install the listed patch or a later fixed release available for that branch.

Cisco ISE Software Release 3.0 has reached End of Software Maintenance. It does not have a listed corrective patch, so organizations still using it should migrate to a supported release that contains the fix.

The vendor’s security advisory is the authoritative reference for the release mapping. Organizations with distributed deployments must inventory every node rather than checking only the primary administration system.

Active Attacks Create a Three-Day Federal Remediation Window

Cisco’s Product Security Incident Response Team has confirmed exploitation in the wild. The company discovered the vulnerability while resolving a Cisco Technical Assistance Center support case, rather than through a scheduled internal assessment.

No threat actor has been identified. Cisco has not connected the activity to a criminal organization, state-sponsored operation, or named ransomware group, and the available information does not describe the attackers’ targets.

CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities catalog on September 16, 2026. Federal agencies must complete the required remediation by September 19, 2026.

The KEV entry requires agencies to apply Cisco’s mitigations while complying with BOD 26-04, “Prioritizing Security Updates Based on Risk,” and CISA’s Forensics Triage Requirements. Applicable BOD 26-04 provisions also cover cloud services. If mitigation is unavailable, CISA directs affected stakeholders to discontinue use of the product.

Forensic triage is specifically required. Whether the vulnerability is being used in ransomware campaigns remains unknown.

The short deadline reflects observed exploitation rather than a merely theoretical attack path. Asset owners must also evaluate whether each appliance is exposed to the internet or otherwise reachable from networks where an attacker could deliver requests to its management plane.

iACLs Can Reduce Exposure but Cannot Remove the Flaw

Cisco has not identified a workaround that completely addresses CVE-2026-76460. Installing a fixed release is the only stated remediation.

While patching is underway, administrators can deploy infrastructure access control lists, or iACLs, to limit traffic reaching the affected appliance. These controls should allow only required management and control-plane connections from explicitly authorized systems and networks.

This measure can reduce the routes available to a remote attacker, particularly where management services were broadly reachable. It does not correct the deficient authentication logic inside the API endpoint.

Priority should go to internet-exposed systems and appliances reachable from less trusted network segments. However, internal placement alone is not proof of safety. A compromised workstation, server, or remote-access account could provide an attacker with the network position needed to reach an inadequately restricted management interface.

Network restrictions should remain in place after patching where operationally possible. They provide an additional boundary around a high-privilege infrastructure service, but they should not be treated as a substitute for the software update.

Defenders Should Examine Logs on Every Node

Cisco recommends reviewing access.log data for suspicious usernames and API activity. In a distributed ISE deployment, investigators must examine every node because relevant entries may not appear on the primary or central system.

Cisco provides this example for searching the API gateway log:

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

The value dummyuser is an example, not a complete indicator of compromise. A match may indicate malicious activity, but investigators should validate it against the surrounding requests, source addresses, timestamps, and expected administrative behavior. They should also search for other anomalous usernames rather than relying on that value alone.

Additional API gateway logs can be obtained by collecting a support bundle with debug logs included. Cisco recommends protecting the bundle with shared-key encryption, decrypting it in the investigative environment, and examining files under:

./ise/logs/apigateway/access.log..gz

Local evidence may be incomplete. Because the flaw can potentially yield root-level command execution, a successful attacker could modify logs, remove files, or otherwise conceal activity on the appliance.

Investigators should correlate ISE records with telemetry held elsewhere, including firewall events and network-flow data. They should look for unexplained outbound uploads from an ISE node, downloads involving suspicious external addresses, and unusual inbound or outbound connections associated with the deployment.

If compromise is suspected, Cisco strongly recommends re-imaging affected nodes and restoring them from configuration backups where necessary. Simply applying the patch does not remove persistence or unauthorized changes that an attacker may already have introduced.

Patch First, Then Determine Whether Access Already Occurred

The immediate response has two parallel tracks: close the vulnerable API path and establish whether attackers reached it before remediation.

Administrators should identify every ISE and ISE-PIC node, verify its exact release, install the corresponding fixed patch, and restrict management traffic with iACLs until deployment is complete. Release 3.0 systems require migration rather than an ordinary patch.

They should then preserve and review available logs, collect external network evidence, and treat unexplained management-plane activity as a potential incident. Where indicators suggest successful exploitation, re-imaging is safer than trusting the integrity of a system that may have been controlled as root.