Cisco ISE under fire: zero-day CVE-2026-76460 with CVSS 10.0 enables authentication bypass and is already exploited in real attacks

Cisco has shipped emergency patches for Identity Services Engine (ISE) and ISE Passive Identity Connector (ISE-PIC) for a zero-day that warrants every possible bit of attention: CVE-2026-76460, with a CVSS score of 10.0 — the maximum possible — and, more disturbingly, with active exploitation confirmed by the vendor itself. The flaw is an insufficient authentication check on an API endpoint that allows a remote attacker to enter without credentials, bypass authentication on the API gateway, and from there execute commands with root privileges if the intrusion is chained with subsequent actions. For security teams managing network and authentication infrastructure, this is not just another vulnerability: it is a breach of access control on the very piece that decides who enters the network. The maximum CVSS severity is not a technicality — it is the recognition that the combination of ease of exploitation, potential impact and absence of alternative mitigations places this CVE in the category of incidents that can define the year for an organisation.

The scope is global and the affected version matrix is broad. Cisco has published patches for the 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7 and 3.5 Patch 4 branches. The 3.0 branch was already at end of software maintenance when the zero-day was discovered, so organisations still on that version must plan a migration to a supported branch that includes the fix — there is no patch, no workaround, no configuration change that will help. And here lies the uncomfortable nuance: Cisco acknowledges that the flaw affects ISE and ISE-PIC regardless of configuration, which means there is no combination of settings that removes the risk while the version remains unpatched. Real mitigation depends on installing the corrected versions. The latter is important because it eliminates the typical response of "we will mitigate it with configuration in the meantime" — here there is nothing to mitigate with configuration, only patch or accept the risk.

To understand the operational severity of CVE-2026-76460 one has to understand the role of Cisco ISE in a modern network architecture. ISE is the policy decision point that controls who enters the network, with which permissions, from which device and under which conditions. In a typical deployment, ISE receives context from switches, access points and firewalls via RADIUS or TACACS+, evaluates the policies defined by the organisation, and returns an authorisation decision that the network equipment applies. If an attacker gains privileges on ISE, they can alter those policies — authorising access for devices that should not be allowed, relaxing authentication conditions, redirecting traffic through sensitive segments. ISE is, in many ways, the brain of the organisation's Zero Trust architecture. That this brain is vulnerable to a credential-less authentication bypass is exactly the kind of failure the entire Zero Trust philosophy is designed against, which is why this case resonates particularly strongly. The irony is not lost on anyone who has worked in network security for years: the piece that implements access control has no access control over itself.

The technical exploitation vector requires no credentials, no particular network position, and no user interaction. An attacker who knows about the vulnerable endpoint can send a specifically crafted request that bypasses the authentication check. Once inside, the attacker gains access to the API gateway without having gone through the web administration interface — a complete bypass. The web interface is the surface administrators know and monitor; the API gateway is a parallel surface that many security teams have not even fully inventoried. That creates an asymmetry: security teams are looking at the wrong side while the intrusion happens. The anomaly detection tools typically deployed in organisations — SIEM, IDS, NDR — capture suspicious access to web interfaces far more easily than anomalous access to internal APIs, because traffic to internal APIs is usually permitted by firewall rules and does not generate the same alert patterns as a web login attempt.

What comes after the entry depends on the attacker. The post-exploitation chain described by Cisco is chilling in its simplicity: with system access, the attacker can execute commands with root privileges. From there, options include deleting logs — particularly relevant for an authentication platform, where logs are the primary forensic defence — manipulating policy configuration to open access paths that were previously closed, exfiltrating sensitive identity data (user credentials, device attributes, network topology), and pivoting to other systems that trust ISE as a source of truth. One of the less discussed but more important implications is the effect on the trust chain: if an attacker can modify policies on ISE, they can have the network authorise a device that should not be authorised, and from that now-inside device, launch attacks against systems that would otherwise be inaccessible. Persistence is particularly concerning in this scenario: once ISE is compromised and the policies have been manipulated, reversing the damage requires rebuilding the policies from a verified source of truth, not just patching the vulnerability — because the attacker may have left active policies that continue to authorise illegitimate access even after the patch.

Cisco recommends several containment and verification actions while patches deploy. The first is to review ise-kong access.log and per-node access.log for suspicious usernames in requests to the API gateway. That review gains value when cross-referenced with external logs — perimeter and firewall — because they help detect unexpected loads and uploads to external IP addresses. The logic here is simple: if authentication was bypassed, you will not see a legitimate login in the ISE logs — but you will see requests that do not add up, unusual geographic origins, or query patterns that do not correspond to normal operations. The absence of successful authentication logs for a given event is not reassurance — it is cause to investigate further. It is important to understand that the review is not only technical but also procedural: do you have a defined playbook to search for indicators of compromise on ISE? If the answer is no, this is the moment to write it before the next similar CVE catches you without a process.

If solid indications of exploitation or compromise appear, the recommended response escalates: reinstall affected nodes and restore configuration from backups. This is a heavy operation — ISE is not a trivial appliance — but it is the only way to guarantee the attacker left no persistence. A reinfected installation is worse than one known to be compromised, because it destroys traceability. Cisco also suggests applying iACLs (infrastructure Access Control Lists) to minimise management and control plane traffic, a way to reduce attack surface while patches deploy in environments where stopping services is not always trivial. iACLs are a classic defence-in-depth pattern: they do not replace the patch, but they shrink the exposure window. The operational rule should be: apply iACLs immediately, patch as soon as possible, and only then consider the window closed.

From an operational standpoint, there are several lessons that go beyond the immediate patch. The first is that identity management platforms are priority targets and must be treated as such. The investment in hardening, monitoring and response for ISE should be proportional to its criticality — and for many organisations, ISE has for years been the component that received the least relative attention precisely because "it always worked". This CVE should serve to reverse that inertia. The second lesson is that monitoring the API gateway is as important as monitoring the web interface. Many security teams have tools to detect suspicious access to administrative portals but not to detect anomalous access to internal APIs — a gap this vulnerability exploits directly. The third lesson is that software branches at end of maintenance are non-negotiable: the 3.0 branch was out of support when this CVE was discovered, and organisations still on it have no patch option. Migration planning must account for the fact that any critical support platform will have serious vulnerabilities that can only be fixed by migrating. The latter has budgetary implications: migration projects must be in the roadmap with high priority, not in the backlog waiting for a better moment.

There is also a reading about the broader Cisco Security ecosystem. ISE is a central piece in many architectures that include other Cisco platforms — DNA Center, Stealthwatch, Firepower Management Center, Secure Network Analytics. The reasonable question many security teams should ask is whether these related platforms share the same Kong-based API gateway model — because if they do, the failure pattern could replicate. Cisco has not said anything public about that yet, but operational prudence suggests auditing other platforms with Kong as an attack surface. Organisations running multiple Cisco Security appliances should review the documentation of their other platforms to understand what API gateways they use and whether they have authentication processes equivalent to the one that failed here. The operational question is not only "are we patched" but "what other surfaces do we have based on Kong or the same model".

It is also worth analysing the post-exploitation detection vector. Once the attacker has root on an ISE node, what indicators remain on the system? Cisco suggests reviewing Kong logs and the nodes' access.log, but one must assume a sophisticated attacker will have tried to delete or alter those logs. Robust detections in this case require external telemetry: perimeter firewall logs showing connections to the API gateway from unexpected origins, DNS logs showing resolutions to ISE-associated domains from anomalous sources, EDR telemetry on endpoints that interacted with ISE during the exposure window. This triangulation is laborious but is the only realistic way to reconstruct what happened when the internal system has been compromised. Teams that already have external telemetry instrumentation on ISE are in a much better position to respond; those that do not should start building it now, before the next CVE.

There is also an angle on the software supply chain worth attention. The vulnerability is in the code Cisco ships to its customers for ISE. Organisations using ISE have trusted Cisco as a critical software vendor, and that vendor has just shipped a piece with a maximum-severity security flaw. Vendor audits of critical security software should include questions about what kind of security testing is applied before release, whether there are external audits, and whether customers have visibility into the security state of the code they are running. This is not exclusive to Cisco — it is a systemic problem with the proprietary security appliance model, where customers cannot audit the code they are running and depend entirely on the vendor for security quality. The trend towards SBOMs (Software Bills of Materials) and security attestation attempts to address this gap, but ISE does not ship a public SBOM for its releases.

Finally, it is worth noting that Cisco's advisory has an unusual tone for a production zero-day: it explicitly acknowledges active exploitation, offers no configuration workarounds, and points administrators to a clear matrix of patched versions by branch. It is the right combination of transparency and urgency. The hard part — installing patches without disrupting operations — falls on the teams. And there the decision has to be made quickly: if your ISE is on a patched version, the risk window closes; if it is on 3.0, the migration conversation can no longer wait; if it is on an unpatched 3.x version, iACLs and intensive API gateway monitoring are the absolute minimum until the patch reaches production. Each day of delay is one more day of exposure to a vulnerability with confirmed active exploitation. The cost of an extended patching window in this case is measurable in terms of accumulated risk; the cost of a poorly deployed patch, on the other hand, is mitigated by testing in staging and a planned rollback.

The incident leaves an uncomfortable question for CISOs: how many ISE instances in the organisation are on vulnerable versions, and how many of those are being monitored at the level the situation requires? The answer to that question is usually unknown until something like CVE-2026-76460 puts it on the table. And when the answer is unknown, the operational vulnerability is doubled: that of the zero-day itself, and that of not knowing where we are exposed. The reasonable answer should be to build a real-time inventory of versions of critical security components, with alerts when those components fall below a support threshold. That inventory is platform engineering work, not incident response, and should exist before CVEs arrive — not be built while trying to patch.

---

Primary sources: - Hispasec Una al Día, "Cisco corrige un zero-day crítico en ISE que ya se explota en ataques" — https://unaaldia.hispasec.com/cisco-corrige-un-zero-day-critico-en-ise-que-ya-se-explota-en-ataques/ - Cisco Security Advisory, "Cisco Identity Services Engine Authentication Bypass Vulnerability" — https://www.cisco.com/c/en/us/support/docs/csa/cisco-sa-ISE-ABP-VNSW7Tn5.html - BleepingComputer, "Cisco warns of max severity ISE zero-day exploited in attacks" — https://www.bleepingcomputer.com/news/security/cisco-warns-of-identity-service-engine-zero-day-exploited-in-attacks/ - MITRE CVE, CVE-2026-76460 — https://www.cve.org/CVERecord?id=CVE-2026-76460