Red Hat Keycloak EUVD-2026-30888

The attacker must already hold valid credentials for a target Keycloak user (PR:L) and must know the client_id of an OIDC client where the administrator has explicitly disabled the implicit flow - the bug only matters where that hardening was applied. Exploitation occurs by manipulating client data on the 'session restart' authentication code path in Keycloak's OIDC endpoint, so the attacker must reach the Keycloak HTTP endpoints over the network (AV:N) and drive an authentication session, but no end-user interaction is needed (UI:N). Limiting factors: the bug does not yield tokens without prior credential possession, it does not by itself elevate privileges within Keycloak, and confidentiality impact depends on whether downstream logs/proxies retain URL fragments or Referer values - environments that strip these reduce, though do not eliminate, real-world impact.

The CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N yields 7.1 (High) and aligns with the description: network-reachable, low complexity, requires low privileges, no user interaction, high confidentiality impact, low integrity impact. The PR:L rating is consistent with the described prerequisite that the attacker must already possess another user's credentials and a client ID, so this is not a pre-auth bug despite the network vector. EPSS data was not supplied, the vulnerability is not in CISA KEV, and no POC reference appears in the provided sources, so realistic risk skews toward credential-aware insiders or post-compromise lateral movement rather than mass exploitation. The real priority depends on deployment posture: tenants who explicitly disabled implicit flow to comply with OAuth BCP are precisely the ones whose security assumption is broken here, making the practical impact higher than the 7.1 score might suggest for a regulated identity provider.

A help-desk operator or compromised low-tier account holder who has phished or otherwise learned a target user's password navigates to a Keycloak-protected OIDC client whose administrators disabled implicit flow, then triggers the session-restart path while supplying manipulated client parameters to request an implicit response. Keycloak issues an access token in the URL fragment that should have been refused, and the attacker either captures it directly or later harvests it from reverse-proxy logs and outbound Referer headers, escalating from credential knowledge to a full bearer token. No public POC has been identified at time of analysis.