Cisco ISE CVE-2026-76460 Hit CISA’s KEV — Patch Identity Services Engine Now

If your Midtown professional firm, Staten Island clinic, or Brooklyn warehouse still runs Cisco Identity Services Engine (ISE) — or ISE Passive Identity Connector (ISE-PIC) — as the brain behind 802.1X, guest Wi-Fi, VPN posture, or NAC, treat CVE-2026-76460 as an emergency change, not a quiet weekend ticket. Cisco published advisory cisco-sa-ISE-ABP-VNSW7Tn5 on September 16, 2026. The same day, CISA added the flaw to its Known Exploited Vulnerabilities (KEV) catalog. Federal civilian agencies face a remediation due date of September 19, 2026. Private NYC shops are not under Binding Operational Directive the same way, but a CVSS 10.0, actively exploited identity-platform bypass with a three-day federal clock should jump the queue ahead of “nice to have” patching.

Cisco’s score for this one is CVSS 3.1 base 10.0 (Critical). There are no workarounds that fix the bug. Temporary network mitigations exist; the only real remediation is a fixed ISE / ISE-PIC patch. This post is a practical checklist for NYC SMBs and the MSPs who support them. Sources: Cisco’s advisory, CISA’s September 16 KEV alert and catalog language, and secondary reporting that restates those primary facts. No invented percentages. No exploit recipes.

What CVE-2026-76460 actually is

Per Cisco’s security advisory (first published September 16, 2026, 16:00 GMT), a vulnerability in an API of Cisco Identity Services Engine can allow an unauthenticated, remote attacker to bypass authentication.

Cisco’s summary is blunt: insufficient authentication control on an API endpoint. An attacker can send a crafted request to an affected API endpoint. A successful exploit can allow unauthorized access to the affected device by bypassing the web-based management interface. Cisco also notes that successful exploitation may yield command execution with root privileges — which is why this sits at a perfect 10.0 and why CISA moved it into the KEV catalog on the day of disclosure.

Important scope notes from Cisco:

• Affected: Cisco ISE and Cisco ISE-PIC, regardless of device configuration.
• Workarounds: none that address the vulnerability.
• Mitigation (temporary only): infrastructure access control lists (iACLs) that allow only required management and control-plane traffic destined to the appliance.

If you do not run ISE or ISE-PIC, this CVE is not your patch target. If you run either product anywhere in the environment — including a quiet lab node, a passive identity connector, or a DR pair someone forgot about — keep reading.

Why CISA put it on the KEV — and why September 19 matters

CISA’s September 16 news alert states it added two vulnerabilities to the KEV catalog based on evidence of active exploitation, including CVE-2026-76460 Cisco Identity Services Engine Incorrect Use of Privileged APIs Vulnerability (alongside an Acronis Backup permissions issue that is out of scope for this post). Public reporting and catalog summaries for the ISE entry align on:

• Vendor / product: Cisco / Identity Services Engine (and ISE-PIC)
• Date added: 2026-09-16
• Due date: 2026-09-19
• Related CWE: CWE-648 (Incorrect Use of Privileged APIs)
• CVSS: 10.0 Critical
• Known ransomware campaign use: Unknown (per catalog-style summaries)

Required action language points agencies at Cisco’s vendor instructions and BOD 26-04 guidance (including forensics triage expectations for exposed assets that grant total control after exploitation). For a five-person accounting firm on South Avenue or a multi-site practice in Queens, the practical takeaway is simple: when Cisco and CISA both say an unauthenticated remote caller can bypass the ISE management plane — and possibly land root — you do not wait for the next scheduled NAC maintenance window if any node is still on an affected build.

Fixed software — what to upgrade to

Cisco’s Fixed Software table in advisory cisco-sa-ISE-ABP-VNSW7Tn5 is the authoritative map:

• ISE / ISE-PIC 3.1 → first fixed release 3.1 Patch 12
• 3.2 → first fixed release 3.2 Patch 11
• 3.3 → first fixed release 3.3 Patch 12
• 3.4 → first fixed release 3.4 Patch 7
• 3.5 → first fixed release 3.5 Patch 4

Cisco notes that ISE Software Release 3.0 has reached End of Software Maintenance. Customers on 3.0 should migrate to a supported release that includes the fix — there is no 3.0 patch for this CVE. Cisco strongly recommends upgrading to the fixed software indicated in the advisory; mitigations are temporary until that upgrade lands.

For upgrade mechanics, use Cisco’s Identity Services Engine upgrade guides on the product support page. Plan node-by-node downtime the way you would for any ISE patch train: confirm persona roles (PAN, PSN, MnT), confirm distributed-deployment order, and do not assume a single “admin GUI” reboot covers every node.

Active exploitation and what Cisco told operators

Cisco’s Exploitation section is unambiguous: the Cisco PSIRT is aware of active exploitation of this vulnerability. The issue was found during resolution of a Cisco TAC support case — not a theoretical lab finding. Cisco strongly recommends upgrading to a fixed software release.

On indicators of compromise, Cisco tells administrators to review access.log and look for suspicious usernames. If the device is part of a distributed deployment, review the logs of each node. Cisco’s non-exhaustive detection example uses:

admin#show logging application ise-kong/access.log | include dummyuser

Cisco also documents collecting a support bundle with include-debug-logs selected (shared-key encryption), then reviewing additional access logs under the decrypted support-bundle path for API gateway access logs. Presence of matching suspicious entries may indicate malicious activity. That is detection hygiene from the vendor — not a how-to for attackers.

Two operational warnings matter for NYC shops:

1. Root can erase the crime scene: After successful exploitation, threat actors may remove or hide evidence on the appliance. Cisco strongly recommends cross-checking network and firewall logs outside the impacted device for unexpected uploads initiated from the affected device to external IPs, or downloads from malicious addresses.
2. If compromise is suspected — re-image: Cisco strongly recommends re-imaging affected nodes and restoring from configuration backup if needed. Do not “clean in place” a management-plane root compromise on the system that decides who gets on your network.

That last point is the one that separates ISE from a random web app. Compromised ISE is not just a stolen admin password — it is the admission-control brain. A rooted ISE can influence who joins corporate Wi-Fi, who passes posture checks, and how VPN and switchport decisions land across every downstream site.

What to do this morning (MSP / NYC SMB checklist)

1. Inventory every ISE and ISE-PIC node

List physical and virtual nodes, software train and patch level, persona roles, and whether the management interface is reachable from the internet or from overly broad internal VLANs. Include quiet lab boxes, ISE-PIC connectors, and DR nodes. Confirm you are not confusing ISE with unrelated Cisco security products (FMC, Secure Email Gateway) that had their own September KEV drama — different CVEs, different patch trains.

2. Patch — land on the fixed release for your train

Schedule an emergency change for every affected node. Target 3.1 Patch 12, 3.2 Patch 11, 3.3 Patch 12, 3.4 Patch 7, or 3.5 Patch 4 as appropriate. If you are still on 3.0, plan migration to a supported fixed train — there is no EoS Band-Aid. Document reboot and persona-failover windows for Midtown and outer-borough sites that still gate badge-adjacent Wi-Fi and VPN during business hours.

3. Temporary iACL while you stage the patch

Cisco states there are no workarounds that address the vulnerability, but iACLs that allow only required management and control-plane traffic to the appliance can reduce remote exposure until the fixed release is installed. Treat that as a bridge, not a destination. If management is already internet-exposed, pull it behind VPN or jump hosts the same day you inventory.

4. Hunt access.log on every node

Using Cisco’s guidance, review ise-kong access logs for suspicious usernames, including the vendor’s example filter. Repeat on each node in a distributed deployment. If anything looks off, preserve support bundles and external firewall history before you re-image.

5. Cross-check firewall and network logs

Because root on ISE can scrub local evidence, pull egress logs for the management interfaces. Look for unexpected outbound connections initiated from ISE nodes to unfamiliar destinations. Pair that with SIEM or MSP monitoring for the same window as any Cisco outreach or anomalous admin sessions.

6. If compromise is suspected — re-image, rotate, rebuild trust

Follow Cisco’s guidance: re-image affected nodes, restore from known-good configuration backup, and treat credentials, certificates, and trust relationships as suspect. Rotate admin accounts, API keys, and any secrets that lived on the compromised node. Re-validate switch and WLC integrations after the rebuild — NAC that “mostly works” after a root incident is not a success criterion.

7. Harden the boring controls after the patch

Keep management interfaces off the open internet. Restrict admin access to known jump hosts. Ship ISE logs to an external collector so a rooted box cannot erase your only trail. Separate management and service planes where your design allows. None of that replaces the patch — it reduces how ugly the next management-plane incident gets.

How MicroSky thinks about this for managed clients

Identity and NAC platforms sit in a high-trust choke point. Staten Island offices, Queens clinics, and Manhattan professional firms often treat ISE as “set and forget” infrastructure — until an unauthenticated API path turns management access into root. We treat KEV-listed identity appliances the same way we treat firewall and remote-access KEVs: inventory first, emergency patch second, IoC and egress review third, re-image and credential rotation if anything looks off.

For clients we manage, the work looks like confirming ISE / ISE-PIC patch levels across every node (including quiet DR and PIC boxes), pushing the correct fixed patch for each train, reviewing access logs and external firewall history, and escalating anything that matches Cisco’s IoC language to a formal incident path. For clients who self-manage on-prem ISE, the same checklist applies — and if management was ever reachable from the open internet, close that path the same day you schedule the patch.

Bottom line

CVE-2026-76460 is a critical, actively exploited authentication bypass in Cisco ISE / ISE-PIC APIs. CISA added it to the KEV catalog on September 16, 2026, with a September 19 federal remediation due date. Patch to the fixed release for your train, use iACLs only as a temporary bridge, hunt access logs on every node, and re-image if compromise is suspected. If you need a local MSP to run that checklist across Midtown, Staten Island, Brooklyn, or Queens sites, call MicroSky at (718) 672-2177 or visit https://microskyms.com.