Keycloak EUVD-2026-32300

The attacker needs valid authentication to the Keycloak realm at low privilege (PR:L) and must be able to authenticate as, or on behalf of, a confidential or public OAuth client that has the token-exchange grant enabled - token exchange is not enabled by default on every client, so realms that have never configured token exchange are not exposed via this code path. Exploitation also requires that the targeted client has a service account whose roles are more privileged than the attacker's own user, otherwise the 'escalation' yields no net gain. No user interaction is required (UI:N), the attack is fully remote over the network to the Keycloak token endpoint (AV:N), and complexity is low (AC:L) - the attacker just inflates the subject_token JWT past 4000 characters. Limiting factors: requires an existing account, requires token-exchange to be enabled on a reachable client, and the practical impact is bounded by the service account's role assignments.

Signals are mixed and lean toward a credible but not urgent priority. CVSS 8.8 (AV:N/AC:L/PR:L/UI:N) reflects network-reachable exploitation with low complexity, only low privileges required, and full confidentiality/integrity/availability impact on the realm - meaningful because the attacker pivots to a service-account identity with potentially broad scopes. However, EPSS is only 0.04% (11th percentile) and CISA SSVC scores Exploitation: none and Automatable: no, indicating no observed in-the-wild activity and no straightforward mass-exploitation pathway; Technical Impact is rated total, consistent with the privilege-escalation outcome. Real-world risk depends heavily on how privileged the target client's service account is - a client whose service account holds realm-admin or sensitive resource-server roles makes this a critical issue, whereas a client with minimal service-account scopes makes it a low-impact bug. No public exploit identified at time of analysis, and no KEV listing.

An attacker who has obtained any low-privileged Keycloak user account (for example via self-registration in a realm that allows it, or through compromise of a non-privileged employee account) sends a crafted POST to the OAuth2 TokenEndpoint requesting a token-exchange grant, attaching client credentials for any client they can authenticate as and a subject_token JWT padded beyond 4000 characters. The server silently drops the oversized subject_token and falls back to client credentials, returning an access token bound to that client's service account; the attacker then uses that token to call APIs or Keycloak admin endpoints with the service account's roles. No public exploit identified at time of analysis, but the technique is straightforward to script once the behavior is understood.