Published · 11h agoSecurity9 min read
Keycloak, miniOrange and a UDS Core client bypass all end in a valid credential rather than a shell. Oracle's WebLogic timeline shows the fix date is the start of the race.
Not a builder's beat, but builders have a standing stake in it.
Compiled by The WatchSomething wrong?How this is made
An authentication bypass does not deliver a shell. In the Xecurify miniOrange SAML 2.0 Single Sign On plugin the payoff is a function call: PHP's `openssl_verify()` returns a tri-state integer, `mo_saml_validate_signature()` applies a loose boolean check to it, and the error value of -1 evaluates as truthy, so a deliberately malformed signature is treated as a successful verification [2]. The result is that a crafted SAMLResponse carrying an attacker-controlled NameID causes `wp_set_auth_cookie()` to be called for the targeted account, which means a login as any existing WordPress user, administrators included [3].
That is why the fix and the fallout run on separate tracks. Patchstack credits the DigitalOcean security team with reporting the flaws, which it found after observing an anomalous WordPress administrator session attempt from outside its trusted network [4]. By that point, according to Patchstack, the attacker already held a WordPress admin session cookie and was stalled only because admin panel operations themselves sat restricted behind the trusted network [5]. Version 17.0.6 of the Standard edition closes the flaw that issued the cookie [1]. It does not go back and invalidate the cookie, and it was not the control that contained the intrusion.
The Keycloak flaw disclosed this month has the same shape at a larger radius. CVE-2026-18963 is rated 9.1 by Red Hat, which is the CVE Numbering Authority for it, and is classified as a weak password recovery mechanism for a forgotten password, CWE-640 [1]. The mechanism is state, not cryptography: an attacker sends a specially crafted request to the reset-credentials endpoint, the authentication session transitions directly to the password update phase, and the action token that Keycloak normally emails is never required [2]. Red Hat assessed it Critical because an unauthenticated remote attacker can do this with no user interaction, and the outcome is complete account takeover of any user, including administrative accounts [3].
Escape researcher Enzo Mongin, writing about a separate Keycloak access-control flaw he disclosed in July, put the consequence plainly: an attacker who crosses one of the server's boundaries does not stop at Keycloak, and they get into everything sitting behind it [8]. The Defense Unicorns advisory for UDS Core is what that looks like with the roles filled in. A logic error in the `client-kubernetes-secret` authenticator causes the submitted `client_secret` to be overwritten with the mounted Kubernetes secret before the comparison happens [1]. Anyone who can reach the realm token endpoint and knows a `client_id` using that authenticator can therefore authenticate as that client with any secret value at all and receive OAuth2 tokens carrying the client's service-account roles [2]. In a default deployment the `uds-operator` client holds `manage-clients` in `realm-management`, so a bypass-issued token could in principle create, modify or delete OIDC clients in the `uds` realm, which opens the door to attacker-registered confidential clients, redirect-URI tampering on existing clients, and secondary credential theft [3].
Note what limits that, because it is not the patch. The UDS Client Policy tags clients created by the operator with `created-by=uds-operator` and refuses UPDATE, VIEW and UNREGISTER operations against clients lacking the attribute, while rejecting Full Scope Allowed and restricting protocol mappers and client scopes to an allowlist [5]. A design decision made earlier is doing the containment work, exactly as the network restriction in front of the WordPress admin panel did.
The advisory's own remediation section is the tell for how these incidents end. Alongside the upgrade, it recommends reviewing Keycloak event logs for unexpected `CLIENT_LOGIN` events on `uds-operator` and admin-event logs for unexpected client CREATE, UPDATE and DELETE [6]. Its interim path is to switch the authenticator to Client Id and Secret, regenerate the client secret, and patch the `keycloak-client-secrets` object in-cluster, with an optional rotation of that secret again after the upgrade [7]. That is a change window built around revocation, log review and rotation. The version number is one line in it.
The vulnerable code was introduced in uds-identity-config v0.11.0 and present through v0.26.0; uds-core first pulled a vulnerable config in v0.39.0, the Kubernetes secret mechanism became the default for the UDS Operator in v0.41.0 and the only mechanism in v0.42.0, and the fix landed in identity-config v0.26.1, shipped in uds-core v1.0.1, v1.1.1 and v1.2.2 [4]. That is sixteen minor version lines of exposure by the advisory's own numbering [10].
Now read the release that fixed it. uds-identity-config v0.26.1, dated 2026-04-27, publishes a changelog consisting of dependency and GitHub Action updates under the heading Miscellaneous [8]. Nothing in those notes references a client authentication bypass [9]. Any team that triages upgrades by reading release notes for security relevance had no signal to act on, and any team on uds-core v0.42.0 or later could not simply disable the affected mechanism, because it was the only one [4] - hence the advisory's instruction to move deliberately backwards to Client Id and Secret with a fresh secret [7].
Oracle's WebLogic case sets the pace. CISA added CVE-2026-21962, CVSS 10.0, to the Known Exploited Vulnerabilities catalog on Monday, citing evidence of active exploitation; the flaw lets an unauthenticated attacker with network access over HTTP reach Oracle HTTP Server and the WebLogic Server Proxy Plug-in and gain unauthorized creation, deletion or modification access to critical data [1]. Oracle released patches in January of this year, and exploitation followed, per reports from GreyNoise and CloudSEK, with a single IP probing multiple known flaws in February and honeypot hits in March [2]. Federal Civilian Executive Branch agencies have been told under Binding Operational Directive 26-04 to fix it by August 27, 2026 [4]. Between the patch and the compliance date sits roughly seven months of live exploitation [5].
CloudSEK's honeypot data explains why that window never really closes. Alongside CVE-2026-21962, it captured attacks on CVE-2020-14882 and 14883, CVE-2020-2551 and CVE-2017-10271, and concluded that threat actors continue to rely on a small set of highly effective, simple-to-exploit vulnerabilities to compromise WebLogic environments [3]. Cisco Talos describes the industrial version of the same behaviour: UAT-10147 leveraged publicly disclosed vulnerabilities to gain initial access at scale, working from an exposed target list of roughly 170,000 URLs that the operator split into 17 files of about 10,000 each [1].
For anyone in that list, the version bump arrives after the interesting part. Talos documents the actor using EfsPotato to elevate privileges, configuring Microsoft Defender exclusions, deleting initial payloads to frustrate forensics, planting a web shell that leads to BadIIS, and running Quasar RAT from a scheduled task named "Google Chrome Start" [2]. None of that is removed by patching the flaw that let it in.
The volume case for treating this as an identity problem comes from ANY.RUN's research on Mirage2FA, a commercial phishing-as-a-service toolkit that abused legitimate Microsoft 365 login flows from 2024 to 2026. The vendor links the activity to 4,532 unique organization email domains, says 48 percent of targeted email addresses were potentially compromised, puts the United States at 63.7 percent of victims, and counts more than 9,000 potential compromise events involving cookie and password theft, SSO logins and 2FA bypass [1]. The mechanism is theft of passwords and session cookies, which yields authenticated Microsoft 365 sessions and access to SSO-connected services even where two-factor authentication is in place [2]. ANY.RUN, which sells the sandboxing and threat intelligence products it recommends in the same write-up, argues that session theft should be handled as an identity incident, with compromised sessions and tokens revoked and activity investigated against the affected identity rather than a password reset alone [3].
The operations that argument implies are already in the product. Keycloak exposes a revocation endpoint that supports both refresh and access tokens, and revoking a refresh token also revokes the user consent for the corresponding client, while the logout endpoint terminates the active user session [1]. Its Admin REST API includes an operation to invalidate the rotated secret for a client [2]. The gap is not tooling. It is whether the ticket that goes into tonight's window stops at the version string.
The author of a Frontier AI piece published this month argues that CVSS alone is not enough, that EPSS and KEV prioritization have become table stakes, and that programs need an exposure management function assessing reachability, misconfiguration and business impact to decide what actually matters [1]. Put these three cases through a queue keyed only to the table stakes and see what happens. WebLogic is a 10.0 with a KEV entry and a federal deadline [1] [4]. Keycloak's 9.1 has no evidence of exploitation and no verified public exploit located as of August 24, 2026 [5]. The UDS Core bypass arrives as a version range in a GitHub advisory [4]. Ranked by score and exploitation status, the identity flaws sort last, and they are the ones whose successful exploitation issues credentials that outlive the patch.
Reachability is where the honest answer lives, and the published record is thin. Red Hat's interim mitigation is to turn off the Forgot password function, and it must be applied to every realm [6]. Univention said on August 20 that its Nubus product is not affected because the forgotten-password feature is not activated in its Keycloak deployments [10]. Whether every realm with that feature enabled is exploitable, or only certain reset-credentials configurations, is not stated by any published source, the GitHub advisory lists affected and patched versions as unknown, the product status for Red Hat Single Sign-On 7 and the JBoss EAP Expansion Pack is not established, and no source addresses whether the fix fully resolves the flaw [9]. Compare that with miniOrange, where proof-of-concept code chains CVE-2026-61979, an 8.1 signature algorithm confusion bug fixed in 17.0.5, with the malformed-signature bypass to obtain admin privileges [7], and Patchstack reports scanning from six IP addresses that suggests opportunistic activity, thrown at every site with the plugin installed without checking which edition or version is behind it [6].
One more thing about the Keycloak upgrade. CVE-2026-18963 was one of eight CVE identifiers fixed in 26.7.2, which also addressed CVE-2026-15571, a predictable account-linking hash that enables takeover through a malicious OIDC client, and 26.7.1 two weeks earlier fixed twelve CVEs, among them a SAML identity-provider-initiated broker login that bypassed a link-only restriction and a default dynamic client registration policy that allowed role forgery via user property mappers [7]. The fixes are available upstream in 26.7.2, released August 19, 2026, with Red Hat build updates in 26.4.15 and 26.6.6 and four errata issued on August 18 [4]. A team that deploys those and calls it done has patched account-linking, broker login and client registration defects in an identity server whose tokens, sessions and client secrets were minted under all of them, and has revoked none of it.
Ranked by verification strength, evidence, and original report placement.
Keycloak flaw CVE-2026-18963 is rated 9.1 on CVSS by Red Hat, which acts as CVE Numbering Authority for it, and is classified as a weak password recovery mechanism for a forgotten password (CWE-640).
Red Hat says the root cause is improper state validation within the reset-credentials authentication flow: an attacker sends a specially crafted request to the reset-credentials endpoint, the authentication session transitions directly to the password update phase, and the action token Keycloak normally sends by email is never required.
Red Hat assessed the severity as Critical because an unauthenticated remote attacker can exploit the flaw without any user interaction; successful exploitation results in complete account takeover of any user, including administrative accounts.
Upstream Keycloak is fixed in 26.7.2, released August 19, 2026; Red Hat build of Keycloak customers should apply updates shipped for 26.4.15 and 26.6.6; Red Hat issued four errata on August 18, 2026 (RHSA-2026:56519, 56520, 56523, 56524).
There is no evidence that CVE-2026-18963 has been exploited, and no verified public exploit had been located as of August 24, 2026.
For deployments that cannot update immediately, Red Hat published a temporary mitigation of turning off the Forgot password functionality, and said the setting must be applied to every realm.
The reporting this story was synthesized from, earliest first. Every link goes to the original.