CVE-2026-46389: Max Severity Keycloak Auth Bypass in UDS

CVE-2026-46389 is an authentication bypass in the client-kubernetes-secret Keycloak authenticator shipped by uds-identity-config for UDS Core. It scores CVSS 10.0. Versions 0.11.0 through 0.26.0 accept any client secret for an affected client, which hands out tokens to anyone who can reach the endpoint. Version 0.26.1 fixes it, so upgrade and review your Keycloak logs.

What's affected

UDS Identity Config builds the Keycloak configuration image (realm, plugins, theme, truststore, JARs) used by the Identity deployment in UDS Core. Per the NVD record, versions 0.11.0 through 0.26.0 are affected. The patched version is 0.26.1.

The GitHub advisory adds detail for UDS Core. Releases that pulled a vulnerable identity config are affected, starting with v0.39.0, which used identity config 0.11.1. The Kubernetes secret authenticator became the default for the UDS Operator in v0.41.0 and the only mechanism in v0.42.0. Patched UDS Core releases are v1.0.1, v1.1.1 and v1.2.2, which include identity config 0.26.1.

How the flaw works

A logic error in the authenticator overwrites the submitted client_secret with the mounted Kubernetes secret before the comparison. The comparison then checks the secret against itself, so it always passes.

According to the record, an attacker who can reach the Keycloak token endpoint and knows a client_id that uses this authenticator can authenticate as that client with any client_secret value. The result is OAuth2 tokens scoped to the client's service account.

For the uds-operator client, the record says the token can be used to register or modify other clients. That is why the score is 10.0 and the scope is changed: control of the identity provider reaches the applications that trust it.

How to check if you're exposed

1. Find the uds-identity-config version in your deployment, and the UDS Core release you run. Compare them with the ranges above.
2. Check whether the uds-operator client, or any other client, uses the Client Id and Kubernetes Secret authenticator. In the Keycloak admin console, open the client's Credentials tab and read the Client Authenticator field.
3. Check network reach to the Keycloak token endpoint from untrusted networks.
4. Review Keycloak event logs for unexpected CLIENT_LOGIN events for the uds-operator client.
5. Review admin event logs for client CREATE, UPDATE or DELETE operations you did not expect.

If you find unexpected activity, treat tokens and client definitions as suspect. Check every client for changes, and rotate secrets after the upgrade.

What to do now

1. Upgrade uds-identity-config to 0.26.1, or move UDS Core to v1.0.1, v1.1.1 or v1.2.2 depending on your line.
2. If you cannot upgrade yet, the advisory describes a workaround that switches the uds-operator client to the Client Id and Secret authenticator. It involves temporarily disabling the UDS Client Policy, changing the authenticator on the client's Credentials tab, regenerating the secret, patching the keycloak-client-secrets secret in the keycloak namespace, and re-enabling the policy. Follow the advisory for the exact steps.
3. After upgrading, the advisory says to switch back to Client Id and Kubernetes Secret using the same procedure.
4. Restrict network access to the token endpoint to what needs it.
5. Review the logs described above, going back to when you first ran an affected version.
6. Record the identity config version in your inventory so you can answer the next question quickly.

Why it matters

The record lists CWE-287, improper authentication, and CWE-303, incorrect implementation of an authentication algorithm. This is the second kind. The design is sound, a secret mounted in a pod compared with a secret presented by a client, but the code replaces one value with the other before checking.

Identity providers sit at the center of trust. A client that can register other clients can, in principle, create a path to anything that relies on that provider. The record's KEV flag is false, and neither the record nor the advisory reports exploitation in the wild.

A defensive habit that helps here is a dependency and configuration inventory that shows which components in your stack ship identity code, so a notice like this one can be matched in minutes. You can run a free in-browser dependency scan at Gold to see what your projects pull in.

A closer look at the exposure window

The advisory's timeline is worth reading against your own upgrade history. The flaw was introduced in identity config 0.11.0, and UDS Core began consuming a vulnerable build with v0.39.0. The Kubernetes secret authenticator was not the default for the UDS Operator until v0.41.0, and it became the only mechanism in v0.42.0.

That means the practical exposure depends on which UDS Core line you run and when you adopted it. A team on an older core release may carry the vulnerable identity config without the operator using the affected authenticator. A team on v0.42.0 or later had no alternative path until a patched release.

Work out two dates for each environment: when the affected identity config first went in, and when you upgrade to a fixed build. Your log review should cover that whole window, not only the last few days. Keycloak event retention may be shorter than the window, so check how long events are kept and export them before they age out.

It also helps to separate production from test. Test clusters often have the same identity configuration and a looser network boundary, and a token from a test cluster is still a token for that cluster's service accounts.

Quick check

Sources

• uds-identity-config advisory GHSA-8mg2-6588-r4hw
• uds-identity-config release v0.26.1 (listed in the NVD record, not fetched)
• Gold page for this CVE

Last reviewed: 19 October 2026.