Overview
Keycloak 26.5.7, released in April 2026, addressed two notable security vulnerabilities affecting organisations using Keycloak as their identity and access management platform. While neither carries the same shock factor as a pre-auth RCE, both have meaningful real-world impact: one can be used to knock an authentication service offline without any credentials, and the other allows authenticated users to silently access data belonging to other users through a flaw in Keycloak's UMA authorisation model.
Keycloak is the dominant open-source IAM solution in enterprise and cloud-native environments — an authentication outage or an authorisation bypass here affects every application behind it.
CVE-2026-4634: Unauthenticated DoS via OIDC Token Endpoint
What Happened
A flaw in how Keycloak processes the scope parameter on the OpenID Connect token endpoint allows an unauthenticated attacker to trigger excessive server-side resource consumption. By sending a POST request to the token endpoint with a specially crafted, excessively long scope value, the server enters a prolonged processing loop that ties up CPU and memory for the duration of the request.
POST /realms/{realm}/protocol/openid-connect/token HTTP/1.1
Host: keycloak.target.corp
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&scope=AAAA[...50,000 chars...]The root cause is classified as CWE-1050: Excessive Platform Resource Consumption within a Loop — the scope string is parsed iteratively without an upper bound on length or iteration count, causing the server to burn resources proportional to the input size.
Impact
An attacker with no account or prior knowledge beyond the realm name can send a sustained stream of these requests to render the Keycloak server unresponsive for all users and applications in that realm. In single-realm deployments this means a complete authentication outage — users cannot log in, and applications cannot obtain tokens for service-to-service calls. The attack requires no authentication and no user interaction, and the implementation is trivial.
For organisations where Keycloak is the authentication gateway for customer-facing applications, this is a straightforward denial-of-service primitive reachable from any internet-connected host.
Affected Versions and Fix
All Keycloak versions prior to 26.5.7, 26.4.11, and 26.2.15 are affected. The fix adds an upper-bound length check on the scope parameter before it is passed to the processing loop, rejecting oversized inputs with a 400 response before any significant computation occurs.
CVE-2026-4636: UMA Policy Bypass — Unauthorised Cross-User Resource Access
Background: Keycloak UMA
User-Managed Access (UMA) is an OAuth 2.0-based protocol that Keycloak implements to allow resource owners to control who can access their resources. A resource owner registers resources under their account and creates policies defining who is permitted access. Requesting parties then obtain a Requesting Party Token (RPT) by going through the UMA flow, which Keycloak validates against the registered policies before granting access.
The Flaw
CVE-2026-4636 is an authorisation logic flaw in the UMA policy creation endpoint. When an authenticated user with the uma_protection role creates a policy, the request body specifies which resources the policy applies to via resource identifiers. The flaw: Keycloak validates that the resource in the URL path belongs to the requesting user, but does not validate the resource identifiers in the request body against the same ownership check.
An attacker can therefore craft a policy creation request where the URL path points to a resource they own, but the body contains resource identifiers belonging to other users. Keycloak accepts the request, attaches the policy to the victim's resources, and the attacker can subsequently obtain an RPT granting them access.
POST /realms/{realm}/authz/protection/policy/{attacker-owned-resource-id}
Authorization: Bearer {attacker-token}
Content-Type: application/json
{
"name": "injected-policy",
"resources": ["{victim-resource-id}"],
"scopes": ["view", "edit"]
}The authorisation boundary is enforced on the URL path but not on the request body. This is a classic parsing/canonicalisation mismatch — the server checks the wrong thing.
Impact
Any authenticated Keycloak user holding the uma_protection role can inject themselves into the access policy of any resource owned by any other user in the same realm. Depending on what resources are managed via UMA, this could mean:
- Unauthorised read or write access to user-owned files, records, or API resources protected by UMA policies.
- Privilege escalation within UMA-protected applications — accessing administrative resources owned by higher-privileged users.
- Persistent unauthorised access — the injected policy remains until the resource owner explicitly reviews and removes it.
Affected Versions and Fix
Fixed in Keycloak 26.5.7, 26.4.11, and 26.2.15. The patch adds ownership validation on resource identifiers in the policy request body, ensuring they match the authenticated user before any policy is created or modified.
Remediation
- Upgrade to Keycloak 26.5.7 (or 26.4.11 / 26.2.15 for older release trains). This is the only definitive fix for both vulnerabilities.
- As a temporary mitigation for CVE-2026-4634, place rate limiting and request size limits on the
/protocol/openid-connect/tokenendpoint at your reverse proxy or WAF layer to reject abnormally large request bodies. - For CVE-2026-4636, audit UMA policies in all realms for unexpected entries — particularly policies on sensitive resources created by users who should not have access to them.
- Review which users hold the
uma_protectionrole and restrict it to those who genuinely require it.
Detection Guidance
For CVE-2026-4634:
- Unusual request volume to
/protocol/openid-connect/tokenwith large POST bodies from a single source IP. - Keycloak CPU/memory spikes coinciding with token endpoint traffic — check JVM metrics and Keycloak access logs together.
For CVE-2026-4636:
- UMA policy creation events in Keycloak audit logs where the policy creator does not own the resource IDs referenced in the policy body.
- Unexpected RPT issuance for resources owned by a user different from the token requester.
Takeaways
These two vulnerabilities represent distinct failure modes in IAM systems. CVE-2026-4634 is an availability attack against the authentication layer itself — the target is not the data but the gate. CVE-2026-4636 is a classic broken object-level authorisation flaw (OWASP API3), where the server enforces ownership on one field but not another in the same request.
For penetration testers, both are worth probing on engagements that include Keycloak: the DoS primitive is a simple availability finding with clear business impact, and the UMA bypass warrants deeper investigation in any deployment where UMA-protected resources contain sensitive data or administrative capability. Check the Keycloak version first — if it is below 26.5.7, both issues are in scope.