CISA lists Cisco ISE privileged API flaw CVE-2026-76460 as actively exploited

CISA has placed CVE-2026-76460, a flaw affecting Cisco Identity Services Engine, on its Known Exploited Vulnerabilities catalog — the listing the agency reserves for vulnerabilities confirmed to be under active attack in the wild. According to a write-up published on dev.to, the entry was added on 16 September 2026, classifies the bug as an incorrect use of privileged APIs, and lists its use in ransomware campaigns as unknown.

A weakness in the network's gatekeeper

Identity Services Engine is Cisco's network access control and policy platform. It decides which users and devices are permitted onto a network and what they are allowed to reach once connected. As the dev.to analysis points out, a weakness in that decision layer affects the trust model for the entire network, not just a single application.

What the flaw description covers

The defect class named in the catalog entry covers situations where an application invokes an interface with more authority than the operation actually requires, or calls it without properly validating who is making the request. The practical result is that a lower-privileged actor can set off actions that should demand higher privilege.

Inside a policy platform, those privileged operations include modifying authorization rules, reading identity data, and managing the certificates and keys used for network authentication. If a lower-privileged interface can trigger any of them, the separation between administration and ordinary operation collapses.

Why compromise of ISE hits harder than most

The dev.to piece explains that Identity Services Engine is frequently deployed as the authority for 802.1X authentication and device posture decisions. An attacker who seizes that authority could grant network access to a device that should be rejected, or rewrite the policies that segment the network.

The trust concentration makes things worse. Network equipment accepts the platform's decisions by design, and the rest of the security stack commonly treats its logs as authoritative. A compromise therefore distorts both access control and the record of what happened on the network. The KEV listing itself is the pivotal fact: it establishes that exploitation has been observed, which raises the priority of the patch and broadens the investigation that should follow it.

What administrators should check

The dev.to article lays out a response checklist:

• Verify deployed versions and patch levels against the vendor advisory, covering every node in a distributed deployment, because a partially patched deployment can still expose the vulnerable interface.
• Review administrative audit logs for actions performed by accounts that should not hold those rights, and for API calls arriving from unexpected sources.
• Look for policy changes that fall outside documented change requests, especially edits to authorization rules or to the set of devices allowed on the network.
• Rotate credentials and certificates shared between the policy platform and the network devices it manages.
• Confirm the administrative interface is restricted to known management networks and cannot be reached from user or guest segments.

What the catalog entry leaves out

The KEV record supplies only the CVE identifier, the affected product, the defect description and the addition date, according to the dev.to write-up, which cites catalog version 2026.09.22 released on 22 September 2026. It does not include affected versions, CVSS scores or exploitation mechanics. Operators therefore need to read the vendor advisory for full scope and remediation steps rather than relying on the catalog alone.

Why it matters

A KEV listing transforms a routine patch into an active incident-response item, and for US federal agencies it typically starts the clock on mandated remediation timelines. The target amplifies the stakes: Identity Services Engine is a trust anchor whose decisions other systems accept without question, so a flaw there is more consequential than the same flaw in a self-contained system.

The dev.to analysis also draws a broader architectural lesson — reduce what the platform can do if it is ever compromised. Where the architecture permits, limiting which devices the policy engine can reach and separating its management plane from the data plane shrink the blast radius of an exploited flaw. Patching closes this particular door; those design measures limit the damage when the next one opens.