Cisco has disclosed a maximum-severity vulnerability in Identity Services Engine (ISE) — tracked as CVE-2026-76460 (CVSS 10.0) — that allows an unauthenticated, remote attacker to bypass authentication entirely. This is not a theoretical exercise: Cisco has confirmed the flaw is being exploited in active attacks.
Per Cisco's advisory language, the root cause is "insufficient authentication control on an API endpoint." An attacker who can reach the vulnerable API over the network can invoke it without presenting any credentials.
Let me be blunt about why this one keeps me up at night: ISE is the policy brain of your network. It decides who and what gets on the wire — 802.1X, TACACS+ device administration, guest access, posture assessment, pxGrid integrations with your firewall and EDR. An unauthenticated bypass against ISE is not just a web app bug; it is a potential takeover of your entire network access control plane. Attackers who control ISE can whitelist rogue devices, disable 802.1X enforcement, push policy changes, and harvest credentials from authentication flows. In every IR engagement I've led where NAC infrastructure was compromised, lateral movement became trivially easy afterward.
If your ISE PAN (Policy Administration Node) or any node exposing management/API interfaces is reachable from user segments, guest networks, or — worst case — the internet, treat this as an emergency change window.
Technical Analysis
What We Know
- CVE: CVE-2026-76460
- CVSS: 10.0 (Critical) — consistent with a network-reachable, unauthenticated bypass with no user interaction required
- Affected component: A Cisco ISE API endpoint with insufficient authentication control
- Attack vector: Remote, unauthenticated. The attacker needs network reachability to the ISE node's API/management interfaces (typically TCP 443 on the PAN, and ERS/OpenAPI-enabled interfaces)
- Exploitation status: Confirmed active exploitation in the wild. At the time of writing there is no patched release — this is an unpatched zero-day, which dramatically raises the priority of network-layer mitigations and detection
Why the Attack Surface Is Broader Than You Think
The classic mistake I see in enterprise ISE deployments: the management/API plane is reachable from far more of the network than intended. ISE nodes frequently sit on a "management VLAN" that, in practice, is routable from server segments, partner VPNs, and sometimes wireless. ERS (External RESTful Services) is often enabled to support integrations with ServiceNow, Splunk, or custom automation — and left with broad ACLs. If an attacker has any internal foothold — a phished workstation, a compromised contractor laptop — they can likely reach ISE.
Exploitation requires no credentials, no user interaction, and (given the API nature of the flaw) likely no malformed-packet wizardry — just well-formed HTTP requests to the vulnerable endpoint. That means exploitation is fast, scriptable, and low-noise at the network layer.
Post-Exploitation Behaviors to Expect
Based on how auth-bypass flaws in network appliances are typically operationalized, watch for:
- New or modified local ISE admin accounts (especially accounts created outside change windows)
- Policy changes: modified network access policies, disabled 802.1X/MAB enforcement, new allowed MAC addresses, changes to downloadable ACLs or TrustSec policy
- ERS/OpenAPI API calls from unusual source IPs — legitimate automation usually comes from a small, known set of orchestration hosts
- Configuration backups or exports triggered from the API (data staging for credential and policy theft)
- Shell-level artifacts on the ISE node itself: unexpected processes under the ISE application, new files in application directories, or outbound connections from the appliance to unknown destinations
Detection & Response
The detections below assume you are forwarding ISE logs (local logging targets and remote syslog) to your SIEM, and that your ISE management/API access logs are being captured either on the appliance or via a load balancer/WAF/NetFlow in front of it. If you are not shipping ISE audit and access logs to your SIEM today, that is your first action item — you cannot hunt what you do not collect.
---
title: Cisco ISE Administrative Account or Policy Modification Outside Known Automation
description: Detects ISE configuration audit events indicating administrator account creation or network access policy changes, which may indicate post-exploitation activity following CVE-2026-76460 authentication bypass.
references:
- https://thehackernews.com/2026/09/cisco-warns-of-new-zero-day-ise-auth.html
author: Security Arsenal
date: 2026/09/25
status: experimental
tags:
- attack.initial_access
- attack.t1190
- attack.persistence
- attack.t1136
logsource:
product: cisco
service: ise
detection:
selection:
Message|contains:
- 'Administrator added'
- 'Admin user created'
- 'Network Access Policy'
- 'Authorization policy updated'
- 'Authentication policy updated'
- 'ERS'
filter_known_automation:
UserName|contains:
- 'svc_ers'
- 'ers_automation'
condition: selection and not filter_known_automation
falsepositives:
- Legitimate ISE administrative changes during change windows
level: high
---
title: API Requests to Cisco ISE from Non-Automation Source Hosts
description: Detects HTTP requests to Cisco ISE management/API endpoints (ERS, OpenAPI, admin portal) originating from source addresses outside the known management/automation set. Relevant to exploitation of CVE-2026-76460, an unauthenticated API endpoint auth bypass.
references:
- https://thehackernews.com/2026/09/cisco-warns-of-new-zero-day-ise-auth.html
author: Security Arsenal
date: 2026/09/25
status: experimental
tags:
- attack.initial_access
- attack.t1190
logsource:
category: webserver
detection:
selection:
c-uri|contains:
- '/ers/config/'
- '/admin/'
- '/api/'
- '/sdk/'
c-ip|startswith:
- '10.'
- '172.'
- '192.168.'
filter_mgmt:
c-ip:
- '10.10.5.21'
- '10.10.5.22'
condition: selection and not filter_mgmt
falsepositives:
- New automation hosts not yet added to the allowlist
- Administrators browsing the ISE UI from jump hosts
level: medium
A note on the second rule: the example allowlist IPs are placeholders. Replace them with your actual ERS automation hosts and admin jump boxes, or better, invert the logic in your SIEM with a watchlist. The analytic value here is the deviation from a known-good set — for an unauthenticated API flaw, the source IP is often the only discriminating signal you have.
// Hunt: Cisco ISE audit events indicating admin account or policy changes (via Syslog/CEF ingestion)
// Tune KnownAutomationHosts to your environment's ERS/automation source IPs
let KnownAutomationHosts = dynamic(["10.10.5.21", "10.10.5.22"]);
union isfuzzy=true
(Syslog
| where Facility =~ "local4" or Computer has_any ("ise", "pan")
| where SyslogMessage has_any ("Administrator added", "Admin user created",
"Authorization policy", "Authentication policy",
"ERS", "Configuration backup")),
(CommonSecurityLog
| where DeviceVendor =~ "Cisco" and DeviceProduct has "ISE"
| where Message has_any ("Administrator added", "Admin user created",
"Authorization policy", "Authentication policy"))
| extend SourceIP = coalesce(SourceIP, column_ifexists("SourceHostName", ""))
| where SourceIP !in (KnownAutomationHosts)
| project TimeGenerated, Computer, SourceIP, SyslogMessage = coalesce(SyslogMessage, Message)
| order by TimeGenerated desc;
// Hunt: HTTP requests to ISE API/management paths from non-allowlisted sources
// Requires access logs from ISE, a reverse proxy/WAF, or firewall URL logs ingested into Sentinel
let KnownAutomationHosts = dynamic(["10.10.5.21", "10.10.5.22"]);
CommonSecurityLog
| where DestinationPort in (443, 9060)
| where RequestURL has_any ("/ers/config/", "/admin/", "/api/", "/sdk/")
| where SourceIP !in (KnownAutomationHosts)
| summarize RequestCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
by SourceIP, RequestURL, RequestMethod, DestinationHostName
| order by RequestCount desc;
-- Artifact: SecurityArsenal.ISE.PostExploit.Hunt
-- Run against ISE nodes (or any Linux-based network appliance under management)
-- to identify suspicious processes and outbound connections consistent with
-- post-exploitation of CVE-2026-76460 (auth bypass on ISE API endpoint).
-- Suspicious interactive shells or tooling spawned under the ISE application context
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(bash|sh|python|perl|nc|ncat|socat|curl|wget)'
AND (Ppid IN (SELECT Pid FROM pslist() WHERE Exe =~ '(?i)ise|tomcat|java')
OR Username =~ '(?i)ise')
-- Unexpected outbound connections from the appliance (C2 or data staging)
SELECT Pid, Name, Laddr, Lport, Raddr, Rport, Status
FROM netstat()
WHERE Status =~ 'ESTABLISHED'
AND Rport NOT IN (53, 123, 389, 636, 1812, 1813, 443, 8443, 8910)
AND NOT Raddr =~ '^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)'
The VQL artifact is intended for responders who have shell-level collection on ISE nodes (via Cisco TAC-supported root access during an incident) or who manage ISE-adjacent Linux infrastructure. The logic hunts the two highest-fidelity post-exploitation signals: shells/tooling hanging off the ISE application process tree, and outbound connections to ports or destinations that have no business leaving a NAC appliance.
#!/bin/bash
# Cisco ISE CVE-2026-76460 - Exposure verification and hardening helper
# Run from a management host. Adjust ISE_NODES and MGMT_SOURCES to your environment.
ISE_NODES="ise-pan-01.corp.local ise-pan-02.corp.local ise-mnt-01.corp.local"
MGMT_SOURCES="10.10.5.0/24" # Known-good management/automation range
# 1. Verify reachability of ISE management/API interfaces from THIS host's segment
# (run from multiple segments: user VLAN, server VLAN, guest, VPN)
for node in $ISE_NODES; do
echo "[*] Testing $node"
nc -zv -w 3 $node 443 2>&1
nc -zv -w 3 $node 9060 2>&1 # ERS/additional service port as applicable
done
# 2. Pull ISE admin/session audit context via CLI (requires ISE CLI admin)
# On each ISE node, review for unexpected admin logins and config changes:
# ssh admin@<ise-node>
# show logging application ade/ADE.log | include -i "login|authenticat"
# show logging system ade/ADE.log tail 500
# 3. Emergency mitigation: restrict management-plane reachability with an
# infrastructure ACL on the gateway/edge in front of ISE until Cisco
# releases a fixed software version. Example (NX-OS style) - adapt to platform:
# ip access-list extended ISE-MGMT-PROTECT
# permit tcp 10.10.5.0/24 host <ISE_PAN_IP> eq 443
# permit udp any host <ISE_PSNI_IP> eq 1812
# permit udp any host <ISE_PSNI_IP> eq 1813
# deny ip any host <ISE_PAN_IP> log
# permit ip any any
# 4. Confirm ERS is DISABLED if not required (reduces exposed API surface):
# ISE GUI: Administration > System > Settings > ERS Settings
# Uncheck 'Enable ERS for Read/Write' unless an integration depends on it.
echo "[+] Reachability test complete. Any successful 443/9060 connect from a non-management segment = exposed attack surface for CVE-2026-76460."
Remediation
- Isolate the management plane immediately. Until Cisco releases fixed software, the only reliable mitigation is network-layer restriction: ISE administration and API interfaces must be reachable only from a dedicated management subnet and hardened jump hosts. RADIUS (1812/1813), TACACS+ (49), and pxGrid (8910) still need their required flows — lock down everything else, especially TCP 443 to the PAN from non-management sources.
- Disable ERS/OpenAPI if not operationally required. Navigate to Administration → System → Settings → ERS Settings and disable read/write ERS. Audit every integration that legitimately needs it and move those to a dedicated service account with IP restrictions.
- Monitor Cisco's advisory for the fixed release. This is currently unpatched. Subscribe to Cisco Security Advisories and watch for the Cisco PSIRT advisory covering CVE-2026-76460. Given the CVSS 10.0 score and confirmed active exploitation, expect CISA to add this to the Known Exploited Vulnerabilities (KEV) catalog with a short federal remediation deadline — plan your change window now, not after the KEV entry drops.
- Rotate ISE credentials and audit admin accounts. Assume any local ISE admin credentials may have been exposed via the bypass. Rotate local admin passwords, TACACS+/RADIUS shared secrets, and ERS service account credentials. Review Administration → System → Admin Access → Administrators for accounts you did not create.
- Review audit logs for the exposure window. Pull the ISE audit reports (Operations → Reports → Reports → Audit) for at least the last 90 days: look for configuration changes, new endpoints suddenly authorized, policy set modifications, and any admin sessions from unexpected sources.
- Verify ISE log forwarding is complete. Confirm your SIEM is receiving ISE audit logs, admin session logs, and (where possible) web access logs from the management interface. Without these, retro-hunting exploitation is guesswork.
- Hunt, don't just patch. Active exploitation means some organizations are already compromised. Run the queries above against historical data — successful exploitation may predate the public disclosure by weeks.
The bottom line: an unauthenticated CVSS 10.0 against the system that controls who gets on your network, with no patch available and attackers already using it, is a "stop what you're doing" event. Restrict the attack surface today, hunt for the last 90 days, and be ready to deploy Cisco's fix the hour it ships.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.