Identity providers exist to be the single, tightly controlled source of truth for who your users are. That makes any gap in their own access controls more consequential than the same bug almost anywhere else in a stack, because the data behind it is, by definition, personal.
What the role-users endpoint got wrong
Keycloak’s admin REST API exposes an endpoint, GET /admin/realms/{realm}/roles/{role-name}/users, that lists every user assigned to a given role. The endpoint checked two things before returning data: could the caller view the role, and could the caller run generic user queries at all. What it never checked was whether the caller had permission to view each individual user it was about to hand back. An admin account deliberately scoped to a narrow slice of users could query a role’s membership instead of the main user directory and receive full records, usernames, email addresses, first and last names, account status and email verification status, for users well outside their intended visibility.
A one-line fix for a structural gap
Escape’s research team, credited to researcher Enzo Mongin, reported the flaw to the Keycloak team on 18 July 2026 and received acknowledgement the same day. Red Hat published CVE-2026-17059 on 24 July, and Keycloak shipped the fix in version 26.7.0 on 28 July, adding a single filter call that checks each returned user against the caller’s actual view permission. The vulnerability carries a CVSS 3.1 score of 6.5 and is classified as CWE-639, broken object-level authorisation, the same bug class behind a long list of API data-exposure incidents in recent years. The small size of the fix does not reflect the size of the exposure: any deployment relying on Keycloak’s restricted-admin model to enforce least privilege was not getting the isolation it was designed to provide.
Why this is a GDPR question, not just a bug report
Keycloak is one of the most widely deployed open-source identity and access management platforms in Europe, used directly and as the base for Red Hat’s single sign-on offering across public-sector portals, universities and enterprise IT. GDPR’s Article 32 requires organisations to implement access controls appropriate to the risk of the personal data they process, and “restricted admin accounts that are not actually restricted” is exactly the kind of gap a data protection audit is meant to catch. If your organisation grants scoped admin roles in Keycloak on the assumption that scope is enforced everywhere, this bug is a reminder that assumption needs to be tested, not just configured.
If you run Keycloak or a Red Hat SSO deployment and need help confirming you are on 26.7.0 or later, auditing what your restricted admin roles can actually see, or reviewing your identity infrastructure against GDPR’s security-of-processing requirements, contact Excello Digital. We help European organisations close the gap between how access control is configured and how it actually behaves.