Keycloak EUVD-2026-112638

Requires a Keycloak deployment configured to use a vault provider (Vault SPI) for storing sensitive values - this is a non-default deployment choice. The attacker must be an authenticated client owner with permission to update their own client's configuration (PR:L); they then set the client secret to a crafted reference pointing at a vault entry and retrieve the client representation to read the value. Limiting factors: no vault provider configured means the flaw is not exploitable, and the attacker needs valid client-owner credentials, so this is not reachable by anonymous/unauthenticated users. No end-user interaction is required.

This is a genuine but moderate-priority confidentiality issue rather than an emergency. The input CVSS is 5.3 (medium) and the vendor-supplied vector CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N shows network reach but gated behind existing low privileges (PR:L - an authenticated client owner) and no availability or integrity impact. There is no public exploit identified at time of analysis, no EPSS score was provided, and the CVE is not listed in CISA KEV, so there is no evidence of active or widespread exploitation. The vuln.today decision label is 'this_month', consistent with a real-but-not-urgent fix window. The most important signals are the two hard preconditions: the deployment must actually use a vault provider for secret storage, and the attacker must already be an authenticated client owner - this is a privilege-boundary/information-disclosure problem, not a remote unauthenticated takeover. One discrepancy to note: the vendor rates AC:H, but the described trigger (repoint a client secret at a vault entry, then read the client config) is a straightforward configuration manipulation once the vault provider is in use, which argues for lower attack complexity; the true limiting factor is the environmental precondition, not attack-time complexity. EPSS and POC data are absent - treat exploitation likelihood as unquantified rather than low.

In a Keycloak / Red Hat build of Keycloak deployment that uses a vault provider to store sensitive values, an authenticated client owner updates their own client's secret to a crafted reference pointing at an arbitrary vault entry, then requests the client configuration/representation and reads the resolved secret in plain text. This exposes credentials the owner was never authorized to see. No public exploit code has been identified for this issue.