The check that was supposed to compare two secrets compares one secret with itself. According to the advisory, the `client-kubernetes-secret` authenticator overwrites the submitted `client_secret` with the value read from the mounted Kubernetes secret before the comparison runs [1]. Any submitted value therefore satisfies it, and the preconditions for abuse are network reach to the realm token endpoint plus knowledge of a `client_id` that uses the authenticator [2]. A `client_id` is an identifier, not a credential.
What the resulting token carries is the client's service-account roles [2]. In a default deployment that matters because `uds-operator` holds `manage-clients` in `realm-management`, which in principle covers creating, modifying and deleting OIDC clients in the `uds` realm, with attacker-registered confidential clients, redirect-URI tampering and follow-on credential theft as the consequences the advisory names [7].
The exposure window is long. Vulnerable code entered `uds-identity-config` at v0.11.0 and survived through v0.26.0 [3], sixteen minor version lines [1], and UDS Core first pulled a vulnerable identity-config in v0.39.0 [4]. The mechanism then became the UDS Operator default in core v0.41.0 and the only mechanism in v0.42.0 [5]. The fix landed as identity-config v0.26.1, shipped in core v1.0.1, v1.1.1 and v1.2.2 [6]. Three parallel trains means the version string is not self-describing: on the 1.1 line the patch is 1.1.1, so a cluster on 1.1.0 is below the fix line while a cluster on the numerically lower 1.0.1 is above it [2]. The reliable question is which identity-config version is mounted, not which core tag is in the values file.
The thing that keeps this from being realm takeover is the UDS Client Policy, which the identity config installs. On `REGISTER` and `UPDATE` requests authenticated as `uds-operator` it refuses Full Scope Allowed, holds protocol mappers and client scopes to an allowlist, and stamps created clients with `created-by=uds-operator`; later `UPDATE`, `VIEW` and `UNREGISTER` calls are refused against clients lacking that attribute [8]. The advisory's position is that a bypass-issued token therefore cannot read or mutate clients it did not create, nor register one with privilege-escalating scopes or mappers [9]. Note where that leaves the documented workaround for operators who cannot upgrade: it begins by disabling that same policy, switches `uds-operator` to `Client Id and Secret`, regenerates the secret and patches `keycloak-client-secrets` in the `keycloak` namespace, then re-enables the policy [11].
Detection is retrospective and judgement-based. The advisory asks operators to review Keycloak event logs for unexpected `CLIENT_LOGIN` events on `uds-operator` and admin-event logs for unexpected client `CREATE`, `UPDATE` or `DELETE` [10]. It does not claim the bypass leaves a distinguishing signature, so the answer depends entirely on log retention and on knowing what that client's normal login volume looks like. Anyone who took the workaround also has a second job later: the advisory says to switch back to the Kubernetes secret authenticator only after upgrading, and optionally to delete `keycloak-client-secrets` and restart the `pepr-uds-core-watcher` deployment in `pepr-system` [12].
