Cisco ISE CVE-2026-76460: Exploited at CVSS 10, and the Patch Does Not Close the Investigation

Cisco's fix for CVE-2026-76460 closes an API endpoint that never checked who was calling it. The fix says nothing about who called it before you installed it.

Cisco published advisory cisco-sa-ISE-ABP-VNSW7Tn5 on September 16 with a CVSS base score of 10.0 and a line that matters more than the score: "The Cisco PSIRT is aware of active exploitation of this vulnerability." An unauthenticated attacker sends a crafted request to an API on Identity Services Engine, bypasses the web-based management interface, and, per Cisco's own indicators-of-compromise section, "may obtain command execution with root privileges." CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day and set the federal remediation deadline at September 19. There are no workarounds.

Who this is for, and who can close the tab

This one belongs to you if you run Cisco ISE or the ISE Passive Identity Connector anywhere in the estate, including the appliance a network team stood up years ago for wired 802.1X and nobody has logged into since. Cisco lists first fixed releases for the 3.1, 3.2, 3.3, 3.4 and 3.5 trains, so every one of those is in scope until patched.

If your network access control is the RADIUS server built into your firewall, a cloud-hosted NAC, or a wireless controller with a local user database, CVE-2026-76460 is not yours. Patch nothing, page nobody. Read the last section anyway, because the exposure that made this bug worth exploiting is a design decision you probably also made.

For everyone still here: ISE is the machine that decides which port, which VLAN, and which user gets onto the network. A typical deployment holds the RADIUS shared secrets for every switch and wireless controller that points at it, the TACACS+ keys used for device administration, the Active Directory or LDAP account that joined it to the domain, and the certificates that sign its portals and its pxGrid feed. Root on that appliance hands an attacker the authority that every switch in the building already trusts.

What the bug is, stated precisely

Cisco classifies it as CWE-648, incorrect use of privileged APIs, and describes the cause as "insufficient authentication control on an API endpoint." The API accepts a request, performs work that should require an authenticated administrator, and returns the result. No credential is involved at any point.

The published vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The part doing the work is S:C, scope changed. That flag means the component holding the flaw and the component that suffers the damage are different things: a defect in the web API reaches the operating system underneath it. Scope change is the difference between a 9.8 and a perfect 10, and in this case it is the accurate description of what happens. You arrive at an unauthenticated HTTP endpoint and you leave with a root shell.

This is the second time in fourteen months that an ISE API has produced a maximum-severity unauthenticated bug under active exploitation. In June and July 2025, CVE-2025-20281 and CVE-2025-20337 both scored 10.0, both allowed unauthenticated code execution as root through a crafted API request, and both were exploited before most operators had scheduled the upgrade. Two separate defects, the same attack surface, the same outcome. Treat the ISE management API as a component with a track record rather than a product with an unlucky month.

Get the version right before you schedule anything

Cisco publishes one fixed patch level per train. Applying the wrong one wastes the change window:

• ISE 3.1 and ISE-PIC 3.1: Patch 12
• ISE 3.2 and ISE-PIC 3.2: Patch 11
• ISE 3.3 and ISE-PIC 3.3: Patch 12
• ISE 3.4 and ISE-PIC 3.4: Patch 7
• ISE 3.5 and ISE-PIC 3.5: Patch 4

Check what you are actually running, on every node, not just the primary admin node:

ise/admin# show version
ise/admin# show application version ise

If a node reports a train older than 3.1, Cisco's fixed-release table has nothing for it. That box needs a migration to a supported train, and until that finishes it needs to be unreachable from anything but a jump host. Cisco's only interim control is an infrastructure access control list that restricts management traffic to the appliance. That is containment, not remediation, and Cisco says so plainly: there are no workarounds that address this vulnerability.

Hunt before you trust the upgrade

Cisco's advisory ships an indicator you can run today. It tells you to review the access log on every node in the deployment for usernames that should not be there:

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

Run it, but understand what it is. dummyuser is the sample string Cisco chose to demonstrate the technique, not a signature. An attacker picks their own name. The useful version of this check enumerates every username and every API path the log contains and asks which of them you recognise. Export the log off the appliance first, then work on the copy:

# On a jump host, against an exported copy of access.log.
# Ranking usernames and paths beats grepping for one literal string.
awk '{print $1, $7}' access.log \
  | sort | uniq -c | sort -rn | head -40

# Any API call that arrives from outside the management range is a lead.
grep -E '"(GET|POST|PUT|PATCH|DELETE) /(api|ers|admin)/' access.log \
  | grep -vE '^(10\.10\.20\.|10\.10\.21\.)' \
  | awk '{print $1}' | sort -u

Now the uncomfortable part. Cisco states that an attacker with root "could allow the threat actor to conceal evidence of the exploitation," and the advisory tells you to cross-check network and firewall logs outside the affected device for unexpected uploads or downloads. The appliance's own logs are a witness the attacker was able to edit. Treat a clean access log as weak evidence, not as an all-clear, and corroborate from a system the bug did not reach:

index=firewall dest_ip IN (10.10.30.11, 10.10.30.12) dest_port IN (443, 9060)
| where NOT cidrmatch("10.10.20.0/24", src_ip)
| stats count, sum(bytes_out) AS bytes_out, values(dest_port) AS ports BY src_ip
| sort - bytes_out

Two signals are worth more than the rest: any source outside your management range that reached TCP/443 or the ERS port on an ISE node, and any outbound transfer from an ISE node to the internet. ISE nodes talk to a short, boring list of destinations. A large upload to an address nobody can explain is the finding.

What to rotate, and the order that keeps the network up

If the hunt produces anything, or if the node was reachable from a network you do not control and you cannot rule out the window between disclosure and patch, the secrets on that appliance are suspect. Rotating them is a network change, so sequence matters:

• ISE administrative and API accounts first. Local admin passwords, ERS and Open API service accounts, and any automation credential stored in a script. These are cheap to change and they are the attacker's route back in.
• The domain join account next. The AD or LDAP account ISE uses to read your directory. Reset it, then re-verify the join before you touch anything downstream.
• Certificates after that. System, portal and pxGrid certificates, plus any private key that lived on the appliance. Certificate replacement forces a re-trust on every pxGrid subscriber, so plan it as its own window.
• RADIUS and TACACS+ shared secrets last, and in stages. Every switch, wireless controller and VPN concentrator that authenticates against ISE holds a copy. Change them device by device with a rollback ready. Get this wrong across the whole estate at once and you have taken the network down yourself, which is the failure mode attackers do not even have to arrange.

Write down the time you patched. Every log question for the next month resolves to "was this before or after the fix," and nobody remembers the date by week three.

The management plane is the control you actually control

You cannot stop Cisco shipping another API defect. Three maximum-severity unauthenticated bugs on the same ISE API surface in fourteen months says the next one is a scheduling question. What you can decide is who is able to send a crafted request to it.

The version of this that works is dull and cheap. Put the admin interface of every identity and access appliance on a management VLAN that only a jump host and the monitoring collector can reach. Enforce it with an infrastructure ACL on the switch or firewall in front of the appliance, not with the appliance's own settings, because a root shell on the appliance edits those. Then verify the rule from outside once a quarter and keep the output; an untested management ACL has the same defensive value as a comment in the config file.

The same rule applies if you never open the Cisco advisory. The firewall admin page, the hypervisor console, the backup server's web interface, the wireless controller: each of them is a box that holds credentials for everything it manages, each of them ships an API you did not audit, and each of them is one authentication bug away from being the story. Restricting who can reach those interfaces survives every CVE that has not been published yet.

Assume the API was reachable and work backward

Patch to the fixed release for your train tonight, because the KEV deadline is September 19 and the exploitation is confirmed rather than theoretical. Then do the three things the patch does not do: pull the access log from every node to storage the appliance cannot write to, corroborate it against firewall and netflow records the attacker could not edit, and rotate the secrets in the order above if anything looks wrong or if the node was reachable from a network you do not own. The upgrade is the start of the work.

If you are unsure which of your appliances hold directory credentials, or who can currently reach their management interfaces, that inventory is the assessment we run most often for small and mid-size networks. It usually takes less time than the patch window you are about to schedule.