CVE-2026-46389: Critical Authentication Bypass in Defense Unicorns UDS Identity Config
| Field | Value |
|---|---|
| CVE ID | CVE-2026-46389 |
| CVSS score | 10.0 |
| Attack vector | Network |
| Auth required | None for the attack path described, beyond knowing a valid client_id and reaching the token endpoint |
| Patch status | Fixed in 0.26.1 |
TL;DR - A logic flaw in
client-kubernetes-secretlets affected Keycloak clients authenticate with anyclient_secret. - UDS Identity Config0.11.0through0.26.0are affected; upgrade to0.26.1. - Treat as urgent if your Keycloak token endpoint is reachable and privileged clients use this authenticator.
Vulnerability at a glance
CVE-2026-46389 is a critical authentication bypass in Defense Unicorns UDS Identity Config, the component that builds the Keycloak configuration image used by UDS Core’s Identity deployment. According to the NVD description, the flaw exists in the client-kubernetes-secret Keycloak client authenticator shipped by uds-identity-config. In affected releases, the submitted client_secret is overwritten with the mounted Kubernetes secret before validation, which collapses the authentication check.
The practical result is severe: an attacker who can reach the Keycloak token endpoint and knows a client_id configured to use this authenticator can obtain OAuth2 tokens for that client while supplying any client_secret value. This is not a vague hardening issue or a low-confidence edge case. If the vulnerable authenticator is in use, client secret verification for those clients is effectively broken.
The NVD record states that versions 0.11.0 through 0.26.0 are affected, and that version 0.26.1 patches the issue. The CVSS score is 10.0, but the CVSS vector string was not confirmed from the fetched NVD output in the research note, so defenders should avoid assuming specific sub-metrics that were not published in the data provided.
What this vulnerability actually means in practice
This issue affects service-to-service authentication in environments where Keycloak clients rely on the client-kubernetes-secret authenticator. That matters because many teams treat client credentials as lower-friction plumbing rather than as high-value identity controls. In this case, the client credential check itself is the failing boundary. An attacker does not need to steal the real secret if the server-side authenticator accepts any secret during token issuance.
The research note highlights a particularly important blast-radius example: if the affected client is uds-operator, the resulting token may allow the attacker to register or modify other clients. That moves the risk from single-client impersonation into identity-plane compromise. Even if your initial exposure seems limited to one client, a privileged service account can turn this into broader administrative abuse inside Keycloak or the surrounding UDS environment.
Defenders should also note what is not currently confirmed. Based on the provided sources, there is no confirmed public PoC and no confirmed in-the-wild exploitation at the time of writing. The CVE is not listed in CISA KEV. That does not reduce urgency much for internet-reachable or flat internal identity infrastructure. Authentication bypasses against token endpoints are usually straightforward to operationalize once the behavior is understood.
Who is affected
The affected product is Defense Unicorns UDS Identity Config (uds-identity-config), specifically the client-kubernetes-secret Keycloak client authenticator that it ships. The vulnerable deployment context is UDS Core’s Identity deployment, where the component builds the Keycloak configuration image including realms, plugins, themes, truststore material, and JARs.
The affected version range is explicitly quoted in the NVD description as 0.11.0 through 0.26.0. The fixed version is 0.26.1. If you are running any release in that range, you should assume exposure until you verify whether the vulnerable authenticator is actually used by any configured clients.
There is an important scoping detail here: the issue does not necessarily affect every Keycloak client in the environment. The CVE description ties exploitation to clients using the client-kubernetes-secret authenticator. If you run uds-identity-config in the affected range but do not use that authenticator for any clients, your practical exposure may differ. In the absence of complete inventory data, defenders should assume at least some clients may be affected and verify configurations directly rather than relying on assumptions.
Exploitation status and attacker requirements
At the time of writing, the available research for this article confirms no public proof-of-concept and no confirmed active exploitation in the wild. It is also not currently in the CISA Known Exploited Vulnerabilities catalog. Those are useful facts for reporting, but they should not be interpreted as evidence of safety. Authentication bypass flaws with simple preconditions often move quickly from advisory to opportunistic scanning.
The known attacker requirements are relatively simple. The attacker needs network reachability to the Keycloak token endpoint and knowledge of a valid client_id configured with the vulnerable authenticator. No legitimate client_secret is required for exploitation according to the NVD description. That means exposure depends heavily on token endpoint reachability, client ID predictability or disclosure, and whether privileged service clients are tied to the vulnerable authentication path.
From an operational risk standpoint, environments with externally reachable identity endpoints, broad east-west connectivity, or easily guessable client names should prioritize remediation first. Even if exploitation has not been publicly observed yet, the preconditions are weak enough that defenders should assume rapid weaponization is possible after disclosure.
Technical root cause
The root cause, as described in the NVD record, is a logic error in the client-kubernetes-secret authenticator. Instead of comparing the attacker-supplied client_secret to the expected secret loaded from Kubernetes, the implementation reportedly overwrites the submitted value with the mounted secret before the comparison occurs. When that happens, the comparison becomes meaningless because the code is no longer validating attacker input.
This class of flaw is especially dangerous in authentication components because it creates a false sense of control. Administrators may believe service-account access is protected by Kubernetes-managed secrets, while the actual validation path always succeeds for any provided secret. In identity systems, broken verification logic is usually worse than missing controls because it hides behind normal-looking configuration and can evade casual testing if teams only verify that “valid” credentials work.
From a defensive engineering perspective, this is also a reminder to treat custom Keycloak authenticators and plugins as high-risk code. They sit directly on the trust boundary for token issuance. Even small logic mistakes in input handling can turn into full authentication bypasses with broad downstream impact.
Detection and validation
Detection is challenging because successful exploitation may resemble normal client-credentials token requests at the protocol layer. If the authenticator accepts arbitrary secrets, standard “invalid client secret” error rates may not spike. Instead, defenders should focus on unusual token issuance patterns, requests targeting known high-value client_id values, and administrative follow-on actions such as client registration or modification.
Start by inventorying which clients use the client-kubernetes-secret authenticator and whether any of them have elevated rights. Then review Keycloak and reverse-proxy logs around the token endpoint for anomalous request volumes, unexpected source IPs, unusual user-agent patterns, or bursts of token requests for service accounts that normally authenticate from a narrow set of systems. If uds-operator is present, investigate any recent client creation or changes as potentially related follow-on activity.
Technical Notes
A practical first step is to search Keycloak or ingress logs for token endpoint requests involving client credentials flows. Exact log fields vary by deployment, but common HTTP access logs will include POST requests to the token endpoint.
POST /realms/<realm>/protocol/openid-connect/token HTTP/1.1
grant_type=client_credentials&client_id=<client_id>&client_secret=<value>
If you log request bodies or parsed form parameters at the reverse proxy, look for repeated requests to the same client_id from unusual hosts, especially where authentication should normally fail. Example grep patterns:
grep -E 'POST .*/protocol/openid-connect/token' /var/log/nginx/access.log
grep -E 'grant_type=client_credentials' /var/log/nginx/access.log
grep -E 'client_id=uds-operator|client_id=' /var/log/nginx/access.log
For SIEM hunting, a generic Splunk-style query might look like this:
index=proxy OR index=keycloak
("protocol/openid-connect/token" AND "grant_type=client_credentials")
| stats count values(src_ip) values(user_agent) by client_id, host
| sort - count
If you have Keycloak admin event logging enabled, review recent client changes:
index=keycloak_admin_events
(action=CREATE OR action=UPDATE OR action=DELETE)
(resourceType=CLIENT OR resourcePath="clients/*")
| table _time, actor, action, resourcePath, ipAddress
Because no vendor-published detection signature was provided in the source material, defenders should assume logging fidelity may be insufficient and compensate with network telemetry, ingress logs, and administrative event review.
Mitigation and patching
The primary remediation is to upgrade UDS Identity Config to 0.26.1 or later. The fixed version is explicitly identified in both the NVD record and the linked release/advisory references. If you operate in a controlled deployment pipeline, do not stop at updating source manifests. Confirm that the updated image is built, deployed, and active in the Keycloak/Identity environment actually serving requests.
Patching alone may not be enough if you cannot rule out prior exploitation. Any affected client may have had tokens issued without possession of the legitimate secret. That means you should review and rotate relevant credentials, expire or invalidate tokens where feasible, and closely examine privileged clients first. If uds-operator or similar administrative service accounts are affected, treat this as a possible identity control-plane incident until proven otherwise.
If an immediate upgrade cannot be completed, reduce exposure by restricting network access to the Keycloak token endpoint, especially from untrusted networks or broad internal segments. Also identify and temporarily disable or isolate high-risk clients using the vulnerable authenticator where business impact allows. Since the vulnerability depends on both endpoint reachability and client configuration, narrowing either side of that equation reduces risk.
Technical Notes
The exact upgrade command depends on how you deploy uds-identity-config. If you manage it through GitOps or Helm values, update the image or release reference from an affected version to 0.26.1. For example, if a manifest or values file pins the release tag, change it explicitly:
udsIdentityConfig:
image:
tag: "0.26.1"
If you are using helm, the workflow may resemble:
helm upgrade <release-name> <chart-name> \
--namespace <namespace> \
--set udsIdentityConfig.image.tag=0.26.1
If your deployment is GitOps-managed, update the pinned tag in source control and force reconciliation:
git grep -n "0.26.0\|0.25.\|0.24.\|0.11."
# edit manifests to 0.26.1, then commit and push
flux reconcile kustomization <name> -n <namespace>
To identify whether clients are configured with the vulnerable authenticator, review exported realm configuration or client settings in the admin console. In environments where emergency containment is needed before patching, restrict access to the token endpoint at the ingress or service mesh layer. Example NGINX-style allowlist control:
location ~ /realms/.*/protocol/openid-connect/token {
allow 10.0.0.0/8;
allow 192.168.0.0/16;
deny all;
}
After upgrading, retest expected client authentication behavior and review logs for any continued anomalous token requests. If you suspect abuse, rotate the Kubernetes-backed secrets associated with affected clients and assess whether downstream systems trusted tokens that may have been illicitly obtained.
References
The authoritative references for this CVE are the NVD record and the project references it cites. Defenders should use those sources first for version confirmation and patch tracking, then validate deployment-specific behavior in their own environment.
Primary references:
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-46389
- Defense Unicorns UDS Identity Config repository: https://github.com/defenseunicorns/uds-identity-config
- Fix release v0.26.1: https://github.com/defenseunicorns/uds-identity-config/releases/tag/v0.26.1
- GitHub security advisory GHSA-8mg2-6588-r4hw: https://github.com/defenseunicorns/uds-identity-config/security/advisories/GHSA-8mg2-6588-r4hw
- CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
For further reading on related vulnerabilities, you can check out CVE-2026-40965 and CVE-2026-42882.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.