A critical Cisco Identity Services Engine flaw is now an active-exploitation problem, not just another vulnerability waiting for a routine patch cycle. CVE-2026-76460 carries a CVSS 3.1 base score of 10.0, allows an unauthenticated remote attacker to bypass authentication through an ISE API, and can lead to command execution with root privileges. Cisco's Product Security Incident Response Team says it is aware of active exploitation. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco published its final advisory on September 16, 2026. The company says there are no workarounds that fix the underlying vulnerability, although an infrastructure access-control-list mitigation can restrict management traffic while an upgrade is being arranged. Fixed releases are available for supported ISE branches from 3.1 through 3.5. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The timing matters. CISA added CVE-2026-76460 to its Known Exploited Vulnerabilities catalog on September 16, according to the Canadian Centre for Cyber Security, while BleepingComputer reported that U.S. federal agencies were given a three-day remediation window. That reported September 19 deadline has now passed, making the issue particularly relevant for administrators still working through unpatched systems. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
What Is CVE-2026-76460?
CVE-2026-76460 is an authentication-bypass vulnerability in Cisco Identity Services Engine, commonly called Cisco ISE. The underlying problem is insufficient authentication control on an API endpoint.
In practical terms, an attacker does not need valid ISE credentials to attempt the attack. Cisco says a malicious actor can send a crafted request to the affected API endpoint and bypass the web-based management interface. A successful exploit can give the attacker unauthorized access to the affected device. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Think of the ISE management interface as a secured control room. Normally, the system should verify who is entering before allowing access to privileged functions. CVE-2026-76460 breaks that authentication boundary through the affected API, which is why the problem is much more serious than a simple information-disclosure bug.
The vulnerability is classified as CWE-648, Incorrect Use of Privileged APIs, and Cisco assigns it the maximum CVSS base score of 10.0. The CVSS vector reflects a remotely reachable attack path, low attack complexity, no required privileges, no user interaction and high potential impact across confidentiality, integrity and availability. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco says the vulnerability was discovered while resolving a Technical Assistance Center support case. The company then published the security advisory on September 16. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Why a Cisco ISE Vulnerability Matters
Cisco ISE is not an ordinary web application sitting on the edge of an organization's network.
Cisco describes ISE as an identity-based network access control and policy-enforcement system. It can gather information about users, devices and network conditions and use that context to control network access across wired, wireless and VPN environments. (https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/ise-aag.html?utm_source=chatgpt.com)
That makes the management plane particularly sensitive.
An attacker who obtains root-level command execution on an ISE appliance is not merely gaining access to a standalone application. The compromised system can sit at an important control point for identity, authentication, authorization and network policy.
For example, imagine an organization where employee laptops, wireless devices and VPN users are all evaluated through ISE before receiving network access. A compromise of the ISE management system does not automatically mean every connected endpoint is compromised, but it does place a security-control system itself in an attacker-controlled environment. That is why administrators need to treat an exposed ISE node differently from an ordinary application server.
The exact consequences depend on the organization's deployment and configuration, but the potential impact helps explain why an authentication bypass against ISE is considerably more serious than a vulnerability affecting an isolated low-privilege service.
Cisco's own advisory warns that successful exploitation may give threat actors command execution with root privileges. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco Confirms Active Exploitation
This is the detail administrators should not overlook.
Cisco does not describe CVE-2026-76460 merely as theoretically exploitable. Its PSIRT says it is aware of active exploitation and recommends upgrading to a fixed release. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The Canadian Centre for Cyber Security repeated that assessment on September 17 and specifically recommended prioritizing CVE-2026-76460 because exploitation has been confirmed in the wild. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
BleepingComputer independently reported the active exploitation and noted that CISA added the vulnerability to its KEV catalog. (https://www.bleepingcomputer.com/news/security/cisco-warns-of-identity-service-engine-zero-day-exploited-in-attacks/amp/?utm_source=chatgpt.com)
The important distinction is simple:
This is not a “patch when convenient” vulnerability. It is an actively exploited authentication bypass affecting security infrastructure.
That does not mean every vulnerable ISE installation has been compromised. It means administrators should not assume that applying the patch alone proves the system was never accessed.
Which Cisco ISE Versions Are Affected?
Cisco's official fixed-release information identifies the following first fixed releases: (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco ISE / ISE-PIC release: 3.1 First fixed release: 3.1 Patch 12
Cisco ISE / ISE-PIC release: 3.2 First fixed release: 3.2 Patch 11
Cisco ISE / ISE-PIC release: 3.3 First fixed release: 3.3 Patch 12
Cisco ISE / ISE-PIC release: 3.4 First fixed release: 3.4 Patch 7
Cisco ISE / ISE-PIC release: 3.5 First fixed release: 3.5 Patch 4
Cisco also states that ISE 3.0 has reached End of Software Maintenance and advises customers running it to migrate to a supported release containing the fix. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The Canadian Centre for Cyber Security likewise recommends migrating unsupported deployments to a fixed release and lists the same first fixed patch levels for ISE 3.1 through 3.5. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
The vulnerability affects Cisco ISE and Cisco ISE Passive Identity Connector, or ISE-PIC, regardless of device configuration, according to Cisco. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
There Is a Mitigation — But It Is Not a Replacement for Patching
One important detail is easy to miss.
Cisco says there are no workarounds that address the vulnerability, but it does provide a mitigation: administrators can use infrastructure access control lists, or iACLs, to allow only required management and control-plane traffic destined for the affected device. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The distinction matters because an ACL changes who can reach the vulnerable management surface; it does not repair the defective API authentication control.
For example, an organization might temporarily restrict access to the ISE management interface so that only approved administrative network segments can reach it. That can reduce exposure while the patch is being prepared. It does not make the vulnerable software itself safe to leave unpatched.
Cisco considers this type of mitigation temporary and continues to recommend upgrading to a fixed software release. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Organizations unable to patch immediately should therefore treat access restriction as an emergency containment measure, not as the final remediation.
How to Check Whether an ISE Device May Have Been Compromised
Patching is only half of the response when exploitation has already been confirmed.
Cisco provides a specific initial indicator-of-compromise check: review the access.log files for suspicious usernames. In a distributed deployment, Cisco says administrators should perform the check across every node. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco gives this example command:
admin# show logging application ise-kong/access.log | include dummyuser
The exact suspicious username or indicator will depend on the activity observed in the environment; the command is an example of how administrators can search the relevant access log rather than a universal compromise signature. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Cisco says additional access.log files can be obtained through a support bundle with debug logs selected, using shared-key encryption, and then examined under the ISE log path documented in its advisory. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
If you're responsible for a distributed deployment, don't check only the primary or most visible node. The value of the investigation comes from looking across the deployment and then comparing what you find with external network telemetry.
There is an important forensic limitation here.
Cisco warns that successful exploitation can provide command execution with root privileges, meaning an attacker may be able to remove or hide evidence of exploitation and indicators of compromise. An apparently clean local log therefore should not automatically be treated as proof that the appliance was never accessed. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
Check Logs Outside the ISE Appliance
For that reason, Cisco recommends cross-checking the ISE appliance against network and firewall logs outside the affected device.
Administrators should investigate suspicious network activity involving the ISE node, including unexpected uploads initiated by the appliance toward external IP addresses or downloads originating from potentially malicious IP addresses. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The Canadian Centre for Cyber Security similarly recommends monitoring firewall, network and authentication logs for anomalous activity. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
This external evidence can be particularly important when local logging cannot provide a complete history.
The goal is not to assume that every unusual connection represents an attack. Instead, correlate the ISE access logs with independent network telemetry and determine whether an unauthorized request, account or outbound connection fits the timeline of the suspected compromise.
What to Do If Compromise Is Suspected
Organizations should move from vulnerability management into incident-response procedures when evidence indicates that an ISE node may have been compromised.
Cisco strongly recommends re-imaging affected nodes and restoring from configuration backup when malicious activity is suspected. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The Canadian Centre for Cyber Security gives the same basic direction: re-image affected nodes and restore from known-good backups because attackers with elevated privileges may be able to remove evidence. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
At the same time, the organization should review what credentials, secrets and access paths were available through the compromised environment and rotate credentials where the incident-response investigation determines that exposure is possible.
That credential-reset step is an incident-response precaution rather than a substitute for re-imaging or restoring a potentially compromised appliance.
The investigation should also consider whether ISE policy, identity information or connected security systems were modified during the compromise window.
If your team has evidence of compromise, the practical objective is not just to remove the vulnerable software. You also need to establish what happened during the exposure window and rebuild trust in the affected system before returning it to normal service.
Emergency Checklist for Cisco ISE Administrators
For organizations running a potentially affected deployment, the immediate workflow should be:
- Identify the ISE version.
Determine whether each ISE or ISE-PIC node is running a vulnerable release.
- Install the applicable fixed release.
Use 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 or 3.5 Patch 4 as applicable. ISE 3.0 requires migration to a supported fixed release. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
- Restrict management-plane access while patching.
Where immediate upgrading is not possible, use iACLs to restrict required management and control-plane traffic. This is mitigation, not a vulnerability fix. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
- Review access.log on every node.
Look for suspicious usernames and unexpected API activity. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
- Correlate with external telemetry.
Check firewall, network and authentication logs outside the ISE appliance for anomalous activity. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
- Do not rely solely on clean local logs.
Root-level command execution may allow attackers to remove or hide evidence. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
- Re-image suspected compromised nodes.
Restore from a known-good configuration backup and follow the organization's incident-response process. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
What the CISA KEV Listing Changes
CISA's Known Exploited Vulnerabilities catalog is an important additional signal because it distinguishes vulnerabilities that have been observed being exploited from flaws that remain theoretical.
The Canadian Centre for Cyber Security says CISA added CVE-2026-76460 to the KEV catalog on September 16, the same day Cisco published its advisory. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
BleepingComputer reported that U.S. federal agencies were given a three-day remediation window following the listing. (https://www.bleepingcomputer.com/news/security/cisco-warns-of-identity-service-engine-zero-day-exploited-in-attacks/amp/?utm_source=chatgpt.com))
As of September 20, that reported September 19 date has passed. For organizations outside the U.S. federal environment, the listing does not by itself create a universal legal deadline, but it is still an important indicator that the vulnerability should be prioritized rather than treated as a normal future maintenance item.
What Remains Unknown
The available public information does not establish every detail of the exploitation campaign.
Cisco confirms active exploitation, but its advisory does not attribute the activity to a particular threat actor. It also does not publish a complete list of compromised organizations or provide a universal forensic signature that can conclusively clear every vulnerable device. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The Register likewise reported that Cisco has not disclosed who is exploiting the flaw, how long the attacks have been underway, or what attackers have done after gaining access. (https://www.theregister.com/security/2026/09/17/cisco-drops-another-exploited-zero-day-this-time-a-perfect-10/5297180)
That matters because administrators should avoid two opposite assumptions.
A vulnerable ISE device should not automatically be described as compromised simply because it was exposed.
At the same time, installing the patch should not automatically be treated as proof that an earlier compromise did not happen.
The correct response is to patch, investigate and preserve relevant evidence according to the organization's incident-response procedures.
The Bigger Security Lesson
CVE-2026-76460 illustrates a particularly important security problem: the management plane of an identity and access-control system can become a high-value target because compromise there can affect the system that decides who and what is allowed to connect.
Cisco ISE is designed to centralize identity, access control and network policy. That architecture provides operational advantages, but it also means that a vulnerability in the management interface can have consequences beyond a single web service. (https://www.cisco.com/c/en/us/products/collateral/security/identity-services-engine/ise-aag.html?utm_source=chatgpt.com)
For security teams, the practical lesson is broader than this individual CVE: management interfaces should be tightly restricted, security telemetry should be collected outside the system being protected, and emergency patching should be accompanied by compromise assessment when exploitation is already confirmed. (https://www.cyber.gc.ca/en/alerts-advisories/al26-021-vulnerabilities-impacting-cisco-identity-services-engine-ise-cisco-ise-passive-identity-connector-ise-pic-cve-2026-20192-cve-2026-76423-cve-2026-76460)
The Bottom Line for ISE Admins
CVE-2026-76460 combines three facts that should drive the response: maximum severity, unauthenticated remote exploitation and confirmed active attacks. Cisco has released fixes, and the company says there is no workaround that repairs the vulnerability. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
The immediate priority is therefore straightforward: identify vulnerable nodes, apply the appropriate fixed release, restrict management access while patching if necessary, and investigate for signs of compromise.
The forensic part should not be skipped. Cisco specifically warns that root-level command execution may let attackers remove or hide evidence, which is why local access.log review should be combined with firewall and network telemetry from outside the affected appliance. (https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html)
For an actively exploited vulnerability in a system responsible for network identity and policy enforcement, “patched” and “not compromised” are two different conclusions. Administrators need evidence for both.
0 Comments
Have a question, feedback, or something to add? Share your thoughts below.