A newly disclosed broken access control vulnerability in Keycloak, the widely deployed open-source identity and access management server that underpins the Red Hat build.
Tracked as CVE-2026-17059, the flaw allows a deliberately restricted admin account to harvest the personal data of users it should never be able to view by querying a role’s membership rather than the main user directory.
Keycloak’s primary user-listing endpoint, GET/admin/realms/{realm}/users, correctly enforces visibility.
An account with only query-users and view-realm permissions receives an empty array when it searches for users, exactly as the access model intends, because the endpoint routes every result through a helper method that filters each user against the caller’s permissions before returning any results.
Keycloak Flaw Exposes User PII
The problem sits in a sibling endpoint. GET /admin/realms/{realm}/roles/{role-name}/users, which lists a role’s members, only checks that the caller can view the role and run generic user queries.
It never applies the same per-user visibility filter. The result: the identical restricted account that gets nothing from the front door can pull full user records, including username, email, first and last name, enabled status, and email-verification state, for every member of any role it can see.
In a multi-team realm, that turns a narrowly scoped helpdesk or support account into a directory of everyone else’s personal data.
Escape confirmed the issue end-to-end on a live Keycloak 999.0.0-SNAPSHOT build at commit 33695405ea, reproducing it with just two API calls from a single restricted token; the flaw is medium severity, with a CVSS 3.1 score of 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
Exploitation requires an admin account already holding the query-users and view-realm roles on a realm running Keycloak’s default admin permission model.
Realms with fine-grained admin permissions v2 enabled are unaffected, since the role-member query is filtered at the data store layer in that configuration.
The disclosure timeline moved quickly. Escape reported the issue to the Keycloak team on July 18, 2026, and received acknowledgment the same day. Red Hat published CVE-2026-17059 on July 24, crediting Escape researcher Enzo Mongin (Orionexe).
Keycloak shipped a fix on July 28, closing the gap with a single added line, a .filter(auth.users()::canView) call, mirroring a fix already applied to a related group-members endpoint. The patch lands in Keycloak 26.7.0.
Escape’s team notes the flaw was surfaced automatically by testing every user-returning endpoint against the same invariant: any identity the canonical users list denies should be denied everywhere.
Organizations running self-hosted Keycloak or the Red Hat build should prioritize upgrading to 26.7.0, especially if any admin accounts hold narrowly scoped, non-full-visibility permissions.
Enabling fine-grained admin permissions v2 offers an additional layer of protection against this specific class of sibling-endpoint filtering gaps.
Cut SOC investigation blind spots and contain threats earlier to reduce response costs and business disruption with ANY.RUN.
