Red Hat Build of Keycloak EUVD-2026-74756

Exploitation requires a valid realm administrator account in the target Keycloak deployment. This is not an unauthenticated or low-privilege attack - the attacker must hold the realm-admin role (or equivalent API permissions) for at least one realm on the target server. The vulnerability is reached through the key provider configuration interface, which is only accessible to realm administrators. In single-tenant or fully-trusted-admin deployments, this issue is mitigated by the trust level already granted to realm admins. The highest-risk scenario is a multi-tenant environment where distinct organizational tenants hold realm admin access, because those tenants may be partially trusted and should not have visibility into the server's filesystem. No special non-default configuration is required beyond having a realm administrator account - the key provider feature is standard functionality.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N yields a score of 4.9 (Medium), and the metric choices are well-calibrated: PR:H (realm administrator required) is the critical limiting factor that prevents this from being a high-priority mass-exploitation target. The C:H rating reflects the potential for reading sensitive server-side files - including private keys, configuration files, or credential stores that the Keycloak process has read access to - which is genuinely impactful if achieved. However, a realm administrator already has broad Keycloak management privileges; the incremental risk is the ability to pivot beyond the Keycloak data boundary to the underlying OS filesystem. No KEV listing or POC code is present in available intelligence, and EPSS data is not provided. Real-world risk is moderate: environments where realm administrator roles are tightly scoped and granted to partially-trusted parties (e.g., per-tenant realm admins in a multi-tenant SaaS deployment) face higher exposure than environments where realm admins are also OS admins. The incomplete-fix nature of the bug slightly elevates confidence that the bypass is real and reachable.

A realm administrator in a multi-tenant Keycloak deployment - for example, a SaaS tenant who has been granted admin rights over their own realm - opens the key provider configuration and submits a series of keystore parameters containing absolute filesystem paths such as /etc/shadow or /opt/keycloak/conf/keycloak.conf. The server's differential responses to valid versus invalid paths allow the attacker to enumerate file existence and infer readability, potentially locating private key material or application secrets stored on the host. No public exploit code has been identified, but the technique is straightforward once the bypass mechanism is known.