Cisco ISE CVE-2026-76460: Rotating Secrets That Live on Every Switch You Own

Some secrets are hard to rotate because they are stored in one place. Others are hard because they are stored in five hundred. Cisco Identity Services Engine is the second category. CVE-2026-76460, a CVSS 10.0 authentication bypass now being exploited in the wild, puts an unauthenticated attacker on the system that decides who is allowed onto your network—and that system shares a secret with every switch, access point and VPN concentrator that asks it for permission.

Patching is the easy instruction. The genuinely difficult work starts the day after, and most incident plans do not have a page for it.

What is confirmed

CISA's Known Exploited Vulnerabilities catalog describes CVE-2026-76460 as an incorrect use of privileged APIs vulnerability in Cisco Identity Services Engine and Cisco ISE Passive Identity Connector that “could allow an unauthenticated, remote attacker to gain unauthorized access to the affected device by bypassing the web-based management interface.” It was added September 16, 2026 with a due date of September 19, 2026, and is not currently linked to a known ransomware campaign.

The flaw carries a CVSS score of 10.0 and stems from insufficient authentication control on an API endpoint; an attacker exploits it by sending a crafted request. It affects ISE and ISE-PIC regardless of device configuration. Cisco is aware of active exploitation, and reporting describes it as a zero-day—Cisco's second actively exploited zero-day disclosed in as many days, following the Secure Email Gateway flaw earlier in the week.

SecurityWeek reports fixed levels of ISE and ISE-PIC 3.5 Patch 4, 3.4 Patch 7, 3.3 Patch 12, 3.2 Patch 11 and 3.1 Patch 12, released out of band. Confirm the exact patch level for your train against Cisco's own advisory before you close the change. There are no workarounds, though infrastructure access control lists restricting who can reach the management interfaces limit remote exploitation.

What remains unknown—and one claim to be careful with

Cisco has not published details of the attacks and the actor is unattributed. There is no public victim count and no proof-of-concept.

One distinction is worth keeping straight while you brief people. Cisco's and CISA's descriptions of this CVE stop at authentication bypass and unauthorized access to the device via the management interface. Some reporting goes further and describes root-level command execution. ISE has had several separate remote-code-execution advisories, so it is easy to blend them together. Plan your response around the confirmed description—an unauthenticated stranger reaching the management plane—which is quite bad enough, and do not put an unverified escalation claim in an incident report.

Why ISE is a secrets problem, not just a box

ISE is the authority other devices consult. That means it holds, or is trusted by, material spread right across the estate:

RADIUS and TACACS+ shared secrets configured identically on every network device that authenticates against it.
Directory bind accounts for Active Directory or LDAP, often with more read access than anyone remembers granting.
Certificates and private keys, including the internal CA material ISE may use to issue device and user certificates.
Administrative and API credentials, plus integration tokens to adjacent systems—MDM, SIEM, firewalls, posture services.
The policy itself, which is not a secret but is an equally interesting target: someone who can edit authorization rules does not need to steal a credential.

A shared secret that is identical on four hundred switches has a specific failure mode. It cannot be rotated quietly, it cannot be rotated quickly, and a half-finished rotation takes devices offline. This is why these secrets are typically the oldest ones in the organisation.

A rotation order that does not lock you out

Patch first, and verify the running level on every node in the deployment, including secondary and monitoring nodes. A partially patched cluster is still exposed.
Investigate before you rotate. Audit administrative access logs for unfamiliar accounts and unexpected logins, and correlate against network and firewall records for unusual transfers to or from ISE. If an attacker reached the management plane, appliance-local evidence is a starting point, not a verdict.
Restore the management boundary. Put management interfaces behind access control lists that permit only your administration network. Do this before rotation rather than after, so you are not rotating secrets into a system a stranger can still reach.
Rotate identity first, infrastructure second. Administrator accounts, API credentials and directory bind accounts change fast and cheaply. Do those immediately.
Stage the shared secrets. RADIUS and TACACS+ secrets need a planned, device-group-by-device-group rollout with a tested rollback. Keep out-of-band console access to a representative device in each group before you start, so a mistake costs one site rather than the network.
Treat certificates as a separate project. If internal CA material is in scope, reissuing is slower than everything above and needs its own plan. Do not let it block the faster wins.

The handover problem, sharpened

Here is what makes this rotation different from most. The new RADIUS secret has to reach the network engineers who will configure it, possibly across sites and time zones, during an incident, while the network they would normally use to coordinate is the thing under suspicion.

Plan that path before you need it. Decide which channel carries the value and which carries the notification; they should not be the same one. Keep the new secret out of the incident ticket, where it will be read by everyone who joins the bridge and everyone who reads the postmortem three months later. For the credentials that unlock everything else —the ISE administrator break-glass account, certificate recovery material—require more than one person to reconstruct the value, so a single compromised mailbox is not a second incident.

And keep a paper answer for the worst case. If network authentication itself is degraded, the recovery procedure cannot assume working network authentication.

Where Secretus fits—and where it does not

Secretus can reduce plaintext exposure when an authorized person must deliver a small, temporary value—a replacement shared secret for one device group, a break-glass credential, an enrolment code—over a channel that does not retain it the way chat and ticketing do. Team Split can require several holders to reconstruct a high-value text secret such as a break-glass password.

It is not a network access control system, not a certificate authority, and not a configuration management tool. It cannot push a RADIUS secret to four hundred switches, will not tell you whether CVE-2026-76460 was exploited against you, and does nothing for a value that is already configured in plaintext across your estate. Patch, restore the management boundary, investigate, and use a one-time channel only for the narrow human step of getting a value to the engineer who has to type it.