CVE-2026-76460: Cisco ISE Auth Bypass (CVSS 10.0) Exploited as Zero-Day

This week in our InSEKurity of the Week series: the vulnerability that turns your network access control platform into the attacker’s network access control platform. On September 16, 2026, Cisco published advisory cisco-sa-ISE-ABP-VNSW7Tn5 for CVE-2026-76460, an authentication bypass in Cisco Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC). It scores CVSS 3.1 10.0 — the ceiling — and is classified as CWE-648, Incorrect Use of Privileged APIs. Cisco PSIRT stated plainly that it “is aware of active exploitation of this vulnerability.” It was a zero-day.

CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a remediation deadline of September 19 — three days — and flagged it for forensic triage under BOD 26-04. That last flag is the one worth reading twice. CISA is not only telling federal agencies to patch. It is telling them to go and find out whether they were already compromised.

The bug itself is almost boring to describe: insufficient authentication control on an API endpoint. Send a crafted request to that endpoint and you are past the web-based management interface, with no credentials, from anywhere the interface answers. What makes it a CVSS 10.0 rather than a CVSS 9.8 is the scope change — the thing you compromise is not the thing that suffers. ISE is the authority that decides which devices and which people are allowed onto the corporate network, and with what rights. Successful exploitation leads to command execution with root privileges on the node, and Cisco’s own guidance is unusually blunt about the consequence: evidence of exploitation and indicators of compromise may be removed or hidden by the threat actors.

It also did not arrive alone. CVE-2026-76460 was added to KEV on September 16; the day before, CVE-2026-76461 — an unauthenticated SQL injection to root in Cisco Secure Email Gateway — had been added on September 14, also actively exploited. And on September 17, Cisco shipped a bundled disclosure of 20+ CVEs across ISE, Secure Firewall Management Center, Nexus Dashboard and ASA/FTD, of which four ISE flaws are also rated CVSS 10.0. That was not a good week to run Cisco security infrastructure.

🚨 Summary

CVE ID: CVE-2026-76460
CVSS 3.1 Score: 10.0 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
CWE: CWE-648: Incorrect Use of Privileged APIs
Cisco Advisory: cisco-sa-ISE-ABP-VNSW7Tn5, first published 2026-09-16 16:00 GMT
Cisco Bug ID: CSCww39530
Affected Software: Cisco ISE and ISE-PIC, releases 3.0 through 3.5 — regardless of device configuration. There is no feature to disable, no setting that makes you safe
Attack Vector: Network — anywhere the ISE management interface answers
Authentication Required: None
Root Cause: Insufficient authentication control on an API endpoint. A crafted request reaches a privileged API without passing the authentication the web-based management interface is supposed to enforce
Impact: Unauthorised access to the device, escalating to command execution as root — and from there the RADIUS secrets, the Active Directory join account, the internal CA, and the authorisation policy for your entire network
Patch Status: Available — 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, 3.5 Patch 4
Release 3.0: End of support. No fixed release. Migration is the only path
Workarounds: None. Cisco offers a mitigation — infrastructure access control lists — not a workaround
Exploitation Status: Actively exploited as a zero-day. No public proof-of-concept had been published at the time of writing; the attackers did not need one
CISA KEV: Listed — added 2026-09-16, remediation due 2026-09-19, ransomware use recorded as Unknown, forensic triage required: Yes
The part people miss: patching does not answer the question. Cisco recommends re-imaging any node you suspect was touched, because root on an ISE node includes root over the logs you would use to decide whether it was touched

🖥️ What is Cisco Identity Services Engine?

Cisco Identity Services Engine (ISE) is Cisco’s network access control and policy platform. In the simplest terms: it is the system that answers the question “is this device allowed on the network, and if so, with what access?” — thousands of times a minute, for every switch port, every wireless association, and every VPN session in the estate.

It does this by acting as the RADIUS and TACACS+ server for the network. A laptop plugs into a switch port; the switch does not decide anything itself, it asks ISE. ISE evaluates its policy set — who is the user, what is the device, is it corporate-owned, is its posture compliant, what time is it, where is it — and answers the switch with an authorisation result: permit, deny, assign VLAN 40, apply this downloadable ACL, put it in the guest portal. The switch obeys. That is the entire design.

ISE-PIC (Passive Identity Connector) is the cut-down sibling: it does not do RADIUS policy, it learns user-to-IP mappings passively from Active Directory and shares them with other Cisco products. It is affected by this vulnerability too.

A production ISE deployment is distributed across nodes with personas:

PAN (Policy Administration Node) — hosts the administration GUI and the configuration database; the primary PAN is the single source of truth for the whole deployment
MnT (Monitoring and Troubleshooting Node) — collects logs and reporting data from everything
PSN (Policy Service Node) — the workhorses that actually answer RADIUS/TACACS+ requests from network devices
pxGrid controller — publishes identity and context to other security products (Secure Firewall, Secure Network Analytics, Catalyst Center)

Since ISE 3.1, these nodes expose their REST interfaces through an API Gateway, which consolidated the older ERS API (historically on TCP/9060) and the newer OpenAPI interface behind TCP/443. The gateway’s access log is the one Cisco names in its indicators-of-compromise guidance: ise-kong/access.log. That filename is the tell — the gateway is a Kong deployment, and the vulnerable endpoint lives behind it.

Typical Use Cases

802.1X wired and wireless authentication for corporate endpoints and users
MAB (MAC Authentication Bypass) for printers, cameras, badge readers and everything else that cannot speak 802.1X
Guest and BYOD onboarding portals, including device registration and certificate provisioning
Posture assessment — checking patch level, disk encryption and AV state before granting full access
TACACS+ device administration — controlling and logging who can log into switches, routers and firewalls, and which commands they may run
VPN authentication for Cisco Secure Client / AnyConnect, including MFA integration
Profiling — fingerprinting every device on the network and classifying it
TrustSec / SGT policy — assigning security group tags that downstream enforcement points act on
pxGrid context sharing with firewalls, NDR and SIEM tooling

Why a NAC Compromise Is Different

Most critical vulnerabilities give an attacker a foothold that they then have to expand. This one gives them the arbiter. Consider what is stored on, or reachable from, a compromised primary PAN:

RADIUS shared secrets for every network device in the estate. These are the keys that let a device speak authoritatively to ISE — and let ISE speak authoritatively to it.
The Active Directory join account. ISE joins the domain to authenticate users. That machine account is a real domain object with real rights.
TACACS+ keys and device administration policy — i.e. the control plane of every switch, router and firewall that uses ISE for admin login.
The ISE internal Certificate Authority. ISE issues certificates to endpoints for BYOD and EAP-TLS. Anyone who controls that CA can mint a certificate that the network is configured to trust for 802.1X.
The authorisation policy itself. An attacker who can edit policy does not need to bypass NAC. They can simply write a rule that places their device in a privileged VLAN, disables posture checking for it, and logs nothing.
The monitoring node’s records — which is to say, the evidence of everything above.

There is a meaningful difference between “an attacker got past the network access control” and “an attacker is the network access control.” This vulnerability produces the second one.

🔍 Technical Analysis

Vulnerability Description

CVE-2026-76460 is an authentication bypass in an API exposed by Cisco ISE and ISE-PIC. Cisco’s description of the root cause is one sentence long: the vulnerability “is due to insufficient authentication control on an API endpoint.” An attacker exploits it by “sending a crafted request to an affected API endpoint,” and a successful exploit allows them to “gain unauthorized access to the affected device by bypassing the web-based management interface.”

Cisco has not published the endpoint path, the shape of the crafted request, or the technical mechanism by which authentication is skipped. That is deliberate and, given active exploitation with no public PoC, defensible. What Cisco did publish is the CWE classification, and it is the most informative thing in the advisory: CWE-648, Incorrect Use of Privileged APIs.

CWE-648 describes a specific and recognisable shape of failure. An application has an internal, privileged API — one that is trusted to perform sensitive operations because it is only ever supposed to be invoked by another trusted component, after that component has done the authentication. The bug is not that the privileged API is broken. The bug is that it can be reached directly, by someone who never went through the component that was doing the checking.

This is the classic failure mode of a gateway-fronted architecture, and ISE has exactly that architecture. Authentication for the management plane is enforced at one layer; the privileged operations live behind it; and the security of the whole arrangement rests on the assumption that no request can arrive at the second layer without having traversed the first. When a routing rule, a path-normalisation quirk, an internal listener, or an endpoint that was simply never added to the protected set breaks that assumption, the privileged API answers the attacker directly — doing exactly what it was designed to do, for exactly the wrong caller.

That is also why “regardless of device configuration” appears in the advisory. There is no feature flag to turn off, because the vulnerable endpoint is part of the platform, not part of a feature.

Root Cause Analysis

A privileged API reachable without the authentication layer in front of it. Per CWE-648: an interface designed to be called only by an already-authenticated, trusted component can be invoked directly by an unauthenticated caller.
Authentication enforced at a gateway rather than at the operation. When the check lives in one layer and the capability lives in another, any path that reaches the second layer without crossing the first is a total bypass. There is no partial failure mode here.
An endpoint outside the protected set. Either through an omission in the gateway’s route configuration or through an internal listener that was never expected to receive external traffic, one endpoint answered requests that should never have reached it.
No defence in depth at the operation itself. The privileged API did not independently verify the caller’s identity. It trusted its position in the architecture — and that position turned out to be reachable.
A management plane that is routinely exposed. ISE’s admin interface and API gateway share TCP/443 with portals that genuinely must be reachable by endpoints. Separating “the guest portal must answer everyone” from “the admin API must answer almost nobody” is an operational discipline, not a product default.
Root-capable command execution behind the bypass. Once past authentication, the access available is not read-only administration. Reporting from Cisco’s advisory guidance and independent analysis converges on the same outcome: command execution with root privileges on the underlying operating system.

Attack Vector

The exact request is not public. The following diagram shows the architectural shape of a CWE-648 bypass against a gateway-fronted management plane — it is not the exploit, and the endpoint path below is a placeholder.

+---------------------------------------------------------------------+
|  ILLUSTRATIVE ARCHITECTURE DIAGRAM                                   |
|  This is NOT a functional exploit. Cisco has not published the       |
|  vulnerable endpoint path or the crafted request. <undisclosed>      |
|  below is a placeholder, not a real URI.                             |
+---------------------------------------------------------------------+

   INTENDED PATH (authentication enforced)

   Admin ----> TCP/443 ----> API Gateway ----> AuthN check ----> OK
                             (ise-kong)             |
                                                    v
                                            Privileged API
                                            (config, policy,
                                             system operations)

   EXPLOIT PATH (CVE-2026-76460, CWE-648)

   Attacker --> TCP/443 --> crafted request --> Privileged API
   (no creds)                     |             (answers directly)
                                  |
                          reaches the operation
                          WITHOUT traversing the
                          authentication check
                                  |
                                  v
                    unauthorised management access
                                  |
                                  v
                    command execution as root on the node
                                  |
                                  v
                  RADIUS secrets / AD join account / internal CA
                  / authorisation policy / the logs themselves

What is not speculative is the outcome and the trace it leaves. Cisco’s indicator-of-compromise guidance points administrators at the API gateway’s access log, and gives dummyuser as an explicitly non-exhaustive example of a suspicious username that has been observed in it. The presence of any unexplained username in that log is the signal; dummyuser is one instance of it, not a signature to match on and stop.

That is a genuinely useful detail, because it tells you what the exploitation looks like from the defender’s side: API requests logged by the gateway, associated with a user identity that does not exist in your deployment. The bypass does not make the request invisible. It makes it authorised.

Exploitation in the Wild

Cisco PSIRT confirmed active exploitation in the advisory at first publication on September 16, 2026. There was no window in which defenders knew about the bug before attackers were using it.
CISA added CVE-2026-76460 to KEV on September 16, 2026, the same day, with a due date of September 19 — a three-day remediation window, and among the shortest CISA issues.
The KEV entry sets forensicTriage: Yes under BOD 26-04, which requires agencies not merely to patch but to run a forensic triage of affected assets. CISA reserves this for vulnerabilities where it expects compromise to have already occurred.
Known ransomware campaign use: Unknown as of the KEV entry. This is a statement about CISA’s visibility, not a statement that ransomware operators are uninterested in a NAC platform.
No verified public proof-of-concept had been published at the time of writing. That does not lower the risk in the near term — exploitation preceded disclosure — but it does mean the population of attackers is currently smaller and more deliberate than it will be once a PoC lands.
Cisco explicitly warns that IoCs may have been removed or hidden by the threat actors. Root on the node includes root over the logs.

Context matters here too. ISE has been a priority target for two consecutive years. In 2025, CVE-2025-20281, CVE-2025-20282 and CVE-2025-20337 — all unauthenticated RCE, all CVSS 10.0 — were disclosed across June and July, and exploitation followed. An attacker who built tooling against ISE in 2025 had every reason to keep looking at it in 2026.

Post-Exploitation Impact

Root on the ISE node. Full control of the operating system underneath the appliance, including the configuration database and the logging subsystem.
Extraction of RADIUS and TACACS+ shared secrets for every network device configured in ISE — the credentials that make a device authoritative on the access control plane.
Compromise of the Active Directory join account. ISE holds a real domain identity in order to authenticate users against AD.
Control of the ISE internal CA. Certificates minted from it are trusted by the network’s own EAP-TLS configuration. An attacker can issue themselves a credential the network is built to accept.
Rewriting of authorisation policy. A rule that grants an attacker-controlled MAC address full access to a privileged VLAN, with posture assessment disabled, is a two-minute change in the ISE GUI.
Creation of administrative accounts on the deployment, for access that survives the patch.
Manipulation or deletion of monitoring data on the MnT node — the same data an incident responder would use to establish what happened.
Lateral movement into every pxGrid consumer — firewalls, NDR platforms and SIEM integrations that trust ISE’s identity feed by design.
Persistence that is indistinguishable from configuration. A malicious authorisation rule is not malware. It is a policy object, in a product whose job is to hold policy objects.

📊 Impact Assessment

Immediate Impact

Unauthenticated, remote, no-user-interaction compromise of a Tier-0 identity system
A three-day CISA remediation deadline with a mandatory forensic triage flag
No workaround — the only in-product remediation is the patch; everything else is network-layer containment
Detection uncertainty by design: the advisory’s own IoC guidance warns that local evidence may have been destroyed
Cisco’s remediation advice for suspected compromise is re-imaging, not cleanup — an operation with real downtime on a system the network cannot function without

Affected Versions

Release	Status	First Fixed Release
ISE / ISE-PIC 3.0	Vulnerable — end of support	None. Migrate to a supported release
ISE / ISE-PIC 3.1	Vulnerable	3.1 Patch 12
ISE / ISE-PIC 3.2	Vulnerable	3.2 Patch 11
ISE / ISE-PIC 3.3	Vulnerable	3.3 Patch 12
ISE / ISE-PIC 3.4	Vulnerable	3.4 Patch 7
ISE / ISE-PIC 3.5	Vulnerable	3.5 Patch 4

Cisco states the vulnerability affects these releases regardless of device configuration. There is no “we don’t use that feature” exemption.

Affected Environments

Any enterprise running Cisco ISE for 802.1X, VPN or device administration — which is a very large share of medium and large Cisco-based networks
Deployments with the admin interface or API gateway reachable from untrusted network segments, including from user VLANs, not only from the internet
Organisations running ISE 3.0, who have a vulnerable, unfixable, end-of-support system holding their network’s access policy
Managed service providers and integrators who operate ISE on behalf of customers and reach it remotely
Environments where ISE is joined to Active Directory — effectively all of them — where compromise of the node extends into the identity estate
Anyone who deferred the September 17 Cisco bundle because there were twenty other CVEs in it and this one looked like just another entry in the list

Attacker Profiles

State-aligned intrusion sets, for whom a NAC platform is close to an ideal position: persistent, privileged, trusted, and sitting on the authentication path of every device in the organisation
Access brokers, who can convert one ISE compromise into durable, policy-level network access and sell it as such
Ransomware affiliates, who benefit from an authorisation authority that can grant their tooling a path into segments that were supposed to be isolated
Opportunistic scanners, who are not a factor today for lack of a public PoC — and will be the moment one exists

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

1. Establish the exact version and patch level of every node.

The patch level is per-node and must be confirmed on each of them, not just the primary PAN. From the ISE CLI in EXEC mode:

# Shows the ADE-OS release and the installed Cisco ISE version.
show version

# Shows the ISE application version, build date and install date.
# The application name for Cisco ISE is "ise".
show application version ise

In the GUI, the authoritative view of installed patches — including which nodes have them — is Administration > System > Maintenance > Patch Management. It requires the Super Admin or System Admin role.

2. Back up before you patch.

# Take a configuration backup to a previously configured repository.
# Replace "myrepository" with your repository name and choose your own key.
# "plain" means the encryption key is supplied in clear text on this line;
# use "hash" instead if you are supplying an already-hashed key.
backup ise-cfg-pre-patch repository myrepository ise-config encryption-key plain <YourEncryptionKey>

3. Install the fixed patch.

Patching via the GUI installs on the primary PAN first and then the remaining nodes in a fixed order. Patching via the CLI lets you control the node order, which is why large deployments prefer it:

# Install the patch bundle from a configured remote repository.
# Substitute the exact patch file name you downloaded from Cisco,
# and the repository name configured on this node.
patch install ise-patchbundle-3.4.0.608-Patch7-<build>.SPA.x86_64.tar.gz myrepository

# Confirm afterwards that the node reports the expected patch level.
show version

Target the first fixed release for your train: 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, or 3.5 Patch 4. If you are on 3.0, there is no patch — plan a migration, and treat the ACL step below as a standing control rather than a temporary one.

4. Restrict who can reach the management plane — and keep the restriction after patching.

Cisco is explicit that there is no workaround, but recommends infrastructure access control lists to limit management traffic to the device. This does not fix the bug; it removes the attacker’s path to it. On an IOS/IOS-XE device in front of ISE:

! Cisco IOS / IOS-XE. Permit HTTPS to the ISE node only from the
! management network, deny it from everywhere else, and leave the rest
! of the traffic (RADIUS, TACACS+, portals) to the following lines.
! 10.10.0.0/24 = management network, 10.20.0.10 = ISE node.
ip access-list extended ACL-ISE-MGMT-IN
 permit tcp 10.10.0.0 0.0.0.255 host 10.20.0.10 eq 443
 deny   tcp any host 10.20.0.10 eq 443
 permit ip any any
!
interface GigabitEthernet0/0/1
 ip access-group ACL-ISE-MGMT-IN in

5. Determine whether the interface was reachable from outside at all.

# Run this from an EXTERNAL host, not from the management network.
# Any HTTP status other than a connection failure means the admin
# interface answered a request from that network position.
curl -sk -o /dev/null -w '%{http_code}\n' https://ise.example.com/admin/

# Check which ISE service ports answer from a given network position.
# 443 = admin GUI and API gateway, 9060 = legacy ERS API,
# 9070 = OpenAPI inter-node port. -Pn skips host discovery.
nmap -Pn -p 443,9060,9070 ise.example.com

Detection Measures

Start with the log Cisco names. Run this on every node in the deployment, not only the primary PAN:

# Cisco's own IoC check. "dummyuser" is a NON-EXHAUSTIVE example of a
# suspicious username -- any entry returned here warrants investigation.
show logging application ise-kong/access.log | include dummyuser

Because dummyuser is an example rather than a signature, the more useful hunt is for any username in that log that you cannot account for:

# Read the API gateway access log and page through it. Compare the
# identities that appear against your actual administrator and API
# service accounts -- anything unrecognised is the finding.
show logging application ise-kong/access.log

# Follow the log live while you work, to catch ongoing activity.
# Press Ctrl+C to stop.
show logging application ise-kong/access.log tail

Then stop trusting the box. Cisco warns that indicators may have been removed by the attacker, so the evidence that matters most is the evidence held somewhere else. Pull firewall, proxy, NetFlow and DNS records for the ISE nodes’ own IP addresses and look for traffic an appliance has no reason to generate:

# Splunk SPL -- outbound sessions from ISE nodes to external destinations.
# Replace the index, field names and the ISE addresses with your own.
index=firewall src_ip IN ("10.20.0.10","10.20.0.11")
  NOT (dest_ip="10.0.0.0/8" OR dest_ip="172.16.0.0/12" OR dest_ip="192.168.0.0/16")
| stats count AS sessions, sum(bytes_out) AS total_bytes_out
        BY src_ip, dest_ip, dest_port
| sort - total_bytes_out

# Microsoft Sentinel / Defender KQL -- the same question, for firewall
# logs normalised into CommonSecurityLog. Adjust the address list.
CommonSecurityLog
| where SourceIP in ("10.20.0.10", "10.20.0.11")
| where ipv4_is_private(DestinationIP) == false
| summarize Sessions = count(), BytesOut = sum(SentBytes)
          by SourceIP, DestinationIP, DestinationPort
| order by BytesOut desc

On the deployment itself, the hunt is for policy that nobody wrote. There is no single command for this; it needs a human with knowledge of what the configuration is supposed to look like:

Administrator accounts in Administration > System > Admin Access > Administrators that do not map to a person or a documented service
Changes to authorisation policy and policy sets — especially new rules with permissive results, or rules that place a specific MAC or identity into a privileged VLAN or SGT
Posture policy exemptions added for individual endpoints or groups
Certificates issued by the ISE internal CA that do not correspond to a known onboarding event
New or modified network device entries and RADIUS shared secrets
pxGrid subscribers that you did not authorise
Repository definitions and scheduled backups pointing at destinations you do not own — a clean exfiltration channel that looks like administration
Gaps in the MnT logs: a period with no records at all is itself a finding

If You Find Something

Cisco’s guidance for suspected compromise is unambiguous and unwelcome: re-image the affected nodes and restore configuration from a backup taken before the suspected compromise. Cleaning a rooted appliance in place is not offered as an option, for the good reason that you cannot verify the result using the appliance’s own logs.

Around that, treat everything ISE held as disclosed:

Preserve external evidence first — firewall, NetFlow, proxy, DNS and SIEM data, which the attacker could not reach.
Rotate every RADIUS and TACACS+ shared secret across the estate. This is disruptive and it is also the point.
Reset the Active Directory join account and review its rights and recent activity.
Reissue or revoke certificates from the ISE internal CA, and review what the network trusts for EAP-TLS.
Rotate administrator credentials, API service accounts and pxGrid credentials.
Diff the restored configuration against the last known-good backup, rule by rule. A single added authorisation rule is the whole payload.
Investigate downstream — pxGrid consumers, integrated MDM, and anything that authenticated through ISE during the exposure window.

Long-term Security Improvements

Take the ISE management plane off any network that does not need it. The admin GUI and the API gateway should be reachable from a management segment and nothing else. Endpoint-facing portals can stay where they are; they are a different function on the same box and deserve a different exposure.
Treat ISE as a Tier-0 asset. It holds domain credentials, a certificate authority, and the policy that governs network access. It belongs in the same isolation, monitoring and change-control regime as a domain controller — not in the “network gear” bucket.
Ship ISE logs off the appliance in real time. The single most damaging property of this vulnerability is that the attacker inherits control of the evidence. Centralised, append-only logging is what converts “we patched” into “we know.”
Alert on ISE configuration change, not just on ISE availability. Most organisations monitor whether ISE is answering RADIUS. Far fewer alert when an authorisation policy changes outside a change window — which is precisely the post-exploitation signal.
Keep an offline, verified configuration backup and test the restore. Cisco’s remediation path for compromise is restore-from-backup; a backup you have never tested is a plan you have never tested.
Get off ISE 3.0. An unfixable CVSS 10.0 on the system that decides who gets on your network is not a risk that can be accepted indefinitely.
Read bundled vendor disclosures properly. The September 17 Cisco release contained 20+ CVEs, four of them CVSS 10.0 in ISE alone. Bundles compress attention; attackers rely on that.
Subscribe to Cisco PSIRT notifications and route them to a person with authority to schedule an emergency patch. A three-day CISA deadline is not a change-advisory-board timeline.

⚠️ Why is this Critical?

CVSS 10.0 with a scope change. Network vector, low complexity, no privileges, no user interaction, total confidentiality/integrity/availability impact — and the compromised component controls others.
It was exploited before it was known. Cisco disclosed active exploitation at first publication. There was no safe interval.
Every deployment is affected. “Regardless of device configuration” removes the usual triage step where half the estate turns out not to be exposed.
There is no workaround. ACLs restrict the path; they do not fix the flaw. Anything that can reach the interface can still exploit it.
The blast radius is the access control plane. RADIUS secrets, the AD join account, the internal CA, and the authorisation policy for the entire network are all on the other side of this bypass.
The persistence looks like configuration. A malicious authorisation rule is a legitimate policy object in a policy product. No EDR flags it, because there is nothing to flag.
CISA required forensic triage. The KEV entry does not only say patch. It says go and find out, which is CISA’s clearest available signal that it expects compromise to have already happened.
Three days. Added September 16, due September 19. CISA does not issue that window for theoretical risk.
ISE 3.0 gets nothing. Some fraction of the installed base has a maximum-severity, actively exploited vulnerability with no vendor fix at all.
This is the second consecutive year. Three CVSS 10.0 unauthenticated RCEs in ISE in 2025, another four CVSS 10.0 ISE flaws disclosed in the same week as this one. The attack surface is under sustained examination.

📅 Timeline and Disclosure

2025-06-25 — Cisco discloses CVE-2025-20281 and CVE-2025-20282, unauthenticated RCE in ISE, both CVSS 10.0
2025-07-16 — CVE-2025-20337 disclosed, also CVSS 10.0 unauthenticated RCE; exploitation attempts follow and the flaws reach CISA KEV
2026-09-14 — CVE-2026-76461 (Cisco Secure Email Gateway, unauthenticated SQL injection to root, CVSS 9.8) added to CISA KEV, due 2026-09-17
2026-09-16 16:00 GMT — Cisco publishes advisory cisco-sa-ISE-ABP-VNSW7Tn5 for CVE-2026-76460, confirming active exploitation; fixed patches available for 3.1 through 3.5
2026-09-16 — CISA adds CVE-2026-76460 to KEV, remediation due 2026-09-19, forensic triage required, ransomware use Unknown
2026-09-17 — Cisco publishes a bundled disclosure of 20+ CVEs across ISE, Secure Firewall Management Center, Nexus Dashboard and ASA/FTD, including four further CVSS 10.0 flaws in ISE (CVE-2026-20130, CVE-2026-20192, CVE-2026-76423, and CVE-2026-76460 itself); press coverage of CVE-2026-76460 broadens
2026-09-19 — CISA BOD 26-04 remediation deadline for federal civilian agencies
2026-09-22 — No verified public proof-of-concept has been published

📚 Resources and References

🤝 SEKurity Supports You

There is a pattern in these posts that is becoming difficult to ignore. The VPN concentrator, the build repository, the MSP console, and now the network access control platform — four weeks, four systems whose entire value proposition is being trusted by everything else. They are the least tested software in most organisations precisely because they are infrastructure: they work, they are Cisco-shaped, and nobody schedules an assessment against the thing that decides whether the assessors can get on the network.

The practical questions for ISE are short and most organisations cannot answer them quickly. What patch level is every node on — not the primary PAN, every node? Which network segments can reach the admin interface and the API gateway, and who verified that recently? Do your ISE logs exist anywhere other than on ISE? Would you notice an authorisation policy change made at 03:00 on a Sunday? And if the answer to the ise-kong/access.log check came back with an unfamiliar username, do you have a backup old enough and clean enough to restore from?

We test management planes the way attackers approach them — from the network position an attacker would actually have, against the appliance nobody wants taken offline for a test window. If your ISE deployment has never been looked at from a user VLAN, that is the gap worth closing before the next CVSS 10.0 arrives. On current form, it will not be a long wait.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your network access infrastructure is our drive.

Sources

Cisco Security Advisory — Cisco Identity Services Engine Authentication Bypass Vulnerability (cisco-sa-ISE-ABP-VNSW7Tn5) — CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, CWE-648, bug ID CSCww39530, first-published date, fixed release table, the ise-kong/access.log IoC command, “no workarounds” statement, iACL mitigation, re-imaging guidance
CISA — Known Exploited Vulnerabilities Catalog — KEV entry for CVE-2026-76460: added 2026-09-16, due 2026-09-19, CWE-648, ransomware use Unknown, forensicTriage: Yes; and CVE-2026-76461 added 2026-09-14, due 2026-09-17
The Hacker News — Cisco Warns of New Zero-Day ISE Auth Bypass (CVSS 10.0) Exploited in Active Attacks — the verbatim IoC command, KEV dates, related ISE and Secure Email Gateway CVEs disclosed the same week
Help Net Security — Unauthenticated attackers are bypassing Cisco ISE’s management interface (CVE-2026-76460) — affected release range, fixed patch levels, per-node log review guidance, external network and firewall log correlation
SecurityWeek — Active Exploitation Triggers Emergency Patch for Cisco ISE Zero-Day — root-level command execution, attacker ability to hide or delete IoCs, advisory reference
Qualys ThreatPROTECT — Cisco ISE Vulnerability (CVE-2026-76460) — ISE 3.0 end-of-life status, KEV dates, fixed version table, QID 317886
SOC Prime — CVE-2026-76460: Cisco ISE Zero-Day Exploited — hunting indicators beyond the vendor example, external telemetry correlation, re-imaging and credential-rotation guidance
Cybersecurity News — Cisco Warns of Critical ISE 0-Day Vulnerability Exploited in Attacks — root privilege outcome, credential theft and lateral movement staging, temporary nature of the iACL mitigation
securityonline.info — Weekly CVE Report: 10 Exploited Flaws (Sept 14-20, 2026) — the calendar-week shortlist used to select this topic, CVE-2026-76460 and CVE-2026-76461 exploitation status
Cisco ISE CLI Reference Guide, Release 3.4 — Cisco ISE CLI Commands in EXEC Show Mode — syntax for show version, show application version, show logging application
Cisco ISE CLI Reference Guide, Release 3.3 — Cisco ISE CLI Commands in EXEC Mode — syntax for patch install and backup
Cisco ISE Upgrade Guide, Release 3.4 — Install Latest Patch — the Administration > System > Maintenance > Patch Management GUI path, required admin roles, GUI vs. CLI node ordering
Cisco ISE Administrator Guide, Release 3.1 — Basic Setup — the API Gateway introduced in ISE 3.1, ERS on TCP/9060 and OpenAPI on TCP/443 and 9070
Cisco — Cisco Identity Services Engine Unauthenticated Remote Code Execution Vulnerabilities (CVE-2025-20281 / CVE-2025-20282 / CVE-2025-20337) — the 2025 ISE CVSS 10.0 sequence used for historical context
EntryZero — Top 5 Hacker-relevante Schwachstellen — weekly vulnerability briefing consulted for topic selection

InSEKurity of the Week (CW38/2026): Cisco ISE Authentication Bypass via Privileged API (CVE-2026-76460)