Cisco ISE Zero-Day Hits 10.0 CVSS as CISA Flags Active Exploitation

Cisco patched a 10.0 CVSS zero-day in its Identity Services Engine on Wednesday, September 17, and CISA added it to the Known Exploited Vulnerabilities catalog the same day. That same-day KEV listing is the tell: exploitation is not theoretical, and defenders had roughly zero window between disclosure and being told to treat it as an active incident.

The math here is what should stop platform teams cold. CVE-2026-76460 is the third maximum-or-near-maximum CVSS API authentication bypass Cisco has shipped in seven months: 10.0 in February-adjacent SD-WAN Manager territory (CVE-2026-20129 at 9.8), 10.0 in Secure Workload (CVE-2026-20223) in May, and now 10.0 in ISE. Three strikes on the same failure mode is a pattern, not a coincidence.

What Happened

According to Dark Reading, CVE-2026-76460 is an authentication bypass in an API endpoint of Cisco's Identity Services Engine, the product Cisco markets as its network access control and zero-trust solution. Cisco's own advisory language pins the root cause on "insufficient authentication control" on an ISE API endpoint, and describes exploitation as sending a crafted request to that endpoint to bypass the web-based management interface.

Successful exploitation gives an unauthenticated remote attacker root privileges and command execution. No credentials, no user interaction, no configuration prerequisite: the flaw affects ISE and ISE-PIC regardless of device configuration. Cisco released patches for versions 3.1 through 3.5. Version 3.0 is end-of-support and will not receive a fix; those customers are told to upgrade.

CISA's decision to add the CVE to its KEV catalog the same day it was disclosed is worth pausing on. Federal civilian agencies now have a hard deadline to remediate. That normally happens after some window of observed exploitation in the wild; here it was concurrent with disclosure, which implies CISA had telemetry or trusted reporting before the patch went public.

Cisco also disclosed and patched several other bugs in ISE and ISE-PIC with similar API authentication issues. The company did not respond to Dark Reading's request for comment. What we do not know, and this matters, is who is exploiting the bug and at what scale. The upper bound on victim count is essentially the deployed ISE 3.1 to 3.5 install base minus whatever fraction patched inside 48 hours, which for enterprise identity infrastructure is historically small.

Technical Anatomy

The mechanism is boring and that is exactly the problem. Johannes Ullrich, founder of the SANS Internet Storm Center, told Dark Reading that "missing authentication for API endpoints is an industry-wide problem," and pointed to the specific pathology: "APIs that were not directly reachable in the past are exposed, and in the process, proper authentication and access control are skipped." This "easily happens as more extensive APIs are exposed to support more modern web application interfaces."

Translated into engineering terms: an internal RPC or admin-only endpoint gets promoted to the public API surface to feed a new dashboard, single-page app, or automation hook. The auth middleware that guarded the old surface does not always get carried forward. In monolithic products with decades of accreted routing code, whether a given handler runs behind the session check or in front of it becomes a question nobody can answer without reading the router config line by line. This is OWASP Broken Access Control territory, and it has been the number one web app risk category for several years running.

The blast radius is what elevates this from a bad bug to a systemic one. ISE is not a leaf node. Emma Stevens, senior threat intelligence advisor at Bitsight, wrote in the firm's advisory that ISE "helps determine which users and devices can connect to a network and what they can access after connecting," and that "root-level access to that infrastructure can create visibility, integrity, and availability risks across a much wider environment." Ullrich made the same point more bluntly: other Cisco APIs use ISE for authentication and access control decisions, so compromising ISE lets an attacker disable the solution, gain access to networks it fronts, or impersonate other hosts. His analogy: "It is like replacing a building's security guard with an imposter."

There is a nastier second-order effect. Cisco's advisory notes that successful exploitation gives attackers the ability to delete or conceal evidence of exploitation and indicators of compromise on the device itself. That is why the company explicitly recommends cross-checking network and firewall logs from outside the affected device for unexpected uploads to external IPs or downloads from malicious ones. Any forensic story that relies solely on ISE's own logs after compromise is unreliable by construction. The source does not disclose whether patched instances retain forensic artifacts of pre-patch exploitation, which matters because responders need to know if the window of exposure is auditable at all.

Who Gets Burned

Anyone running ISE 3.1 through 3.5 as the identity control plane for their enterprise network is in the immediate blast radius, and that is a large set: ISE is a default choice in Cisco-heavy shops, which means large banks, telcos, healthcare systems, government agencies, and any regulated enterprise that standardized on Cisco networking in the last decade. The version 3.0 customers are worse off: no patch is coming, so they inherit an upgrade project on an emergency timeline.

For iGaming and fintech platform teams that use ISE for NAC on corporate networks (rather than production), the exposure is less about payment rails and more about lateral movement. An attacker with root on ISE can pivot into any network segment ISE arbitrates access to, including admin VLANs, jump hosts, and the management planes of production infrastructure. In regulated verticals, that turns a network access control bug into a mandatory breach disclosure conversation.

Crypto custody and DeFi infrastructure operators who run cold-signing environments behind Cisco NAC should treat this as a segmentation validation event, not a patch event. If ISE decides which endpoints reach your HSM management network, the trust boundary you thought existed does not exist during the exploitation window.

Ad-tech and enterprise SaaS with Cisco identity infrastructure at HQ or in colocation face a subtler problem: their SOC dashboards likely trust ISE-sourced authentication events. Any detection logic that says "user X authenticated via ISE therefore this session is legitimate" is temporarily unsound. The unknown here is how many downstream SIEM rules implicitly rely on ISE assertions; I'd bound it as "more than the security team currently has documented."

The 90-day picture: expect at least one publicly disclosed breach attributed to this CVE by end of Q4 2026, and expect Cisco's competitors (Aruba ClearPass, Fortinet FortiNAC, and the various zero-trust overlay vendors) to weaponize this in enterprise sales cycles through the first half of 2027.

Playbook for Security Teams

Patch first, then verify. Cisco released fixes for ISE and ISE-PIC 3.1 through 3.5. Version 3.0 needs an upgrade, not a patch, and that is a project not a change ticket. Cisco offers a partial mitigation via infrastructure access control lists (iACLs) restricting who can reach the vulnerable API endpoint, but the company itself says mitigations are temporary. Do not treat the iACL as the finish line.

Assume pre-patch compromise if your ISE management interface was reachable from anything wider than a hardened admin subnet. Because on-box logs can be tampered with post-exploit, pull correlating evidence from upstream firewalls, netflow collectors, and any out-of-band syslog destinations. Look specifically for unexpected outbound uploads from ISE appliances and inbound connections from IPs outside your normal admin sources.

Rotate anything ISE knew about. If ISE held RADIUS shared secrets, TACACS keys, PKI trust material, or API credentials for downstream integrations, treat those as burned during the exposure window. This is the boring, expensive work that most teams will skip and later regret.

Cross-reference the CVE record at MITRE and confirm your asset inventory reflects every ISE and ISE-PIC instance, including the ones running in lab, DR, and acquired-subsidiary environments that nobody has touched in two years. Shadow ISE deployments are where this bug lives longest.

Prediction: if this exploitation is as active as CISA's same-day KEV listing implies, we should see at least one named threat actor attribution and one KEV-driven mandatory disclosure from a US federal agency within 60 days. If that does not happen by mid-November, the exploitation activity was narrower than the CISA action suggested.

Key Takeaways

• CVE-2026-76460 is a 10.0 CVSS unauthenticated remote root on Cisco ISE, actively exploited, patched September 17 with same-day CISA KEV listing.
• This is Cisco's third max-or-near-max CVSS API auth bypass in 2026, after CVE-2026-20223 (Secure Workload, 10.0, May) and CVE-2026-20129 (SD-WAN Manager, 9.8, February). Pattern, not accident.
• ISE compromise cascades: other Cisco APIs rely on it for auth decisions, so root on ISE undermines trust across every network segment it arbitrates.
• On-box forensic logs are unreliable post-exploit. Investigate from upstream firewalls and out-of-band log destinations, not the appliance itself.
• Testable bound: if same-day KEV listing reflects real breadth of exploitation, expect named attribution or a federal disclosure within 60 days. Absence of either by mid-November means the activity was narrower than signaled.