The gatekeeper was the target: identity appliances got bypassed

The most-exploited flaws we tracked this week were not buried in some web app behind the login page. They were in the login page itself. Cisco's Identity Services Engine, the appliance whose entire job is to decide who reaches a network and with what rights, shipped two flaws rated CVSS 10.0 that Cisco confirms are being exploited in the wild, and CISA added one of them to its Known Exploited Vulnerabilities catalog with a three-day federal patch deadline. The gatekeeper was the target.

Across the week our desk logged a decision on nearly 6,000 vulnerabilities. Command injection and cross-site scripting topped the queue by raw count, as they almost always do. But the flaws that actually mattered, the handful being used rather than merely disclosed, clustered somewhere narrower and more consequential: the identity and access-control layer. That is the pattern worth your attention this week, and it changes what the word "patched" is supposed to buy you.

The week's exploited flaws were in the gate, not the app

Start with the numbers, because they set the frame. Of the nearly 6,000 vulnerabilities we triaged, around 45 carried a signal of active or likely exploitation by our tracking. That is a small fraction, and it is the fraction that decides where you spend Tuesday. This week two of the loudest sat in Cisco ISE: CVE-2026-20192, an improper access-control flaw, and CVE-2026-76460, an unauthenticated API authentication bypass. Both are CVSS 10.0, both are reachable over the network with no credentials, and both were exploited before many teams had finished the previous patch cycle.

They did not arrive alone. Kong's Enterprise Gateway disclosed CVE-2026-14917, a SAML authentication bypass: with the plugin's signature validation switched off, an assertion that was never signed is still accepted, letting an attacker log in as any account they name, administrators included. There is no public exploit for the Kong flaw yet, which is exactly why it belongs in this column and not in the breaking feed. It is the same shape as the Cisco bugs, one step earlier in its life. An API gateway and a network access-control appliance are different boxes with the same purpose: they stand at the boundary and answer one question, is this request allowed. This week, three times over, the answer could be forced to yes.

Our own count for the authentication and account-takeover bug class was 172 triaged items this week, behind command injection at 296 and cross-site scripting at 258. So this is not the largest category by volume. It is the category where volume and exploitation diverged: fewer bugs, but the live ones sat on the trust boundary. That divergence, not the raw ranking, is the signal.

An auth bypass is worth more than an RCE of the same severity

It is tempting to file a CVSS 10.0 authentication bypass next to a CVSS 10.0 remote code execution and treat them as the same emergency. They are not the same, and the difference favors the attacker holding the bypass. A memory-corruption RCE has to survive the target's defenses: it can crash the process, trip an exploit mitigation, leave a core dump, and it usually drops you in as some service account you then have to escalate from. An authentication bypass skips all of that. It does not defeat the system's security; it uses the system's security. You are not an intruder who broke in, you are a principal the system issued a session to, frequently an administrator.

That has three consequences worth sitting with. It is quiet: no crash, no shellcode, no anomalous binary, just a login the appliance itself considers valid. It is durable: a valid session, a valid API token, or an identity record you were able to write survives the reboot that would have killed a memory exploit. And it inherits trust: whatever that gateway or ISE node is trusted to reach, the RADIUS clients, the TACACS-managed switches, the directories it binds to, the attacker now reaches with the same blessing. An RCE hands an attacker a foothold. A bypass of the identity plane hands them the keys, and the keys look real.

You will not find it in the authentication log

Here is the part that makes this a detection problem and not only a patching one. When the thing that was abused is authentication, the evidence of abuse is a successful authentication. The auth-success log, the first place most teams would look, shows a normal login by a valid-looking user. Cisco's guidance for the exploited ISE bypass is blunt about the limits here: there is no workaround, and the interim control is to restrict the administrative and API interface to trusted networks. That is a containment measure, not a detection one, and it is worth keeping in place long after the patch, because it shrinks the surface where the next bypass can even be reached.

So detection has to invert. You cannot catch this at the door, because the door opened correctly. You catch it in what the session does after it is inside: configuration changes on an appliance that rarely changes, identity records written outside a change window, API calls from a source that has never made them, an administrator active at an hour that administrator never works. And you catch it on the host, because an appliance like ISE is a Linux system underneath, and process, file, and integrity signals on the box itself do not care whether the session that spawned them was "authenticated." That is the host-centric read on a week like this. Patching the ISE nodes closes the hole. It does not tell you whether anyone walked through it in the days before the fix landed, and for an exploited, KEV-listed bypass, that window is the question that matters.

This is not a one-week accident of the calendar. In July we wrote that the appliances organizations install to be safer were the week's most dangerous bugs, when authorization-bypass CVEs were disclosed in products from Dell, Progress, and BeyondTrust. The through-line is structural: we keep concentrating identity into single, network-reachable boxes, and a single box that answers "who are you" for an entire estate is a single box whose bypass compromises that entire estate. Concentrating the decision concentrates the blast radius. The trade can be worth making, but only if those boxes are treated as the crown jewels they are, not as set-and-forget infrastructure.

What to do with the boxes that guard the door

Rank your patch backlog by where a flaw sits, not by when it was disclosed. A CVSS 10.0 in an appliance on your trust boundary outranks a higher-scoring bug in an app that already sits behind three other controls. If you run Cisco ISE, confirm the fixed build on every node rather than assuming one patch covered the estate, and because one of the fixed flaws exposed stored credentials, rotate the secrets that box held: RADIUS shared secrets, TACACS keys, directory-join accounts, and administrator passwords. If you run Kong, check whether SAML signature validation is enabled before you even reach for the patch, because the flaw only bites where that flag is off. More broadly, inventory every product whose job is to authenticate or authorize, the SSO brokers, the gateways, the VPN and NAC appliances, and put their admin and API interfaces on networks only your operators can reach.

Then instrument for the session, not just the login. Assume that at some point one of these boxes will issue a valid session to the wrong person, and decide now what post-authentication behavior would tell you. On an appliance that means watching for configuration and identity writes out of band, and watching the host underneath the product, not only the product's own logs, because those logs are written by the very thing that was fooled. The patch is the easy part. Knowing whether you were used before it arrived is the work.