A Door That Was Supposed to Stay Locked

Keycloak, the widely used open-source identity and access management platform, has patched a privacy flaw that let administrators with deliberately limited permissions pull personal data on users they were never meant to see. The issue, tracked as CVE-2026-17059, was discovered by researcher Enzo Mongin (known online as Orionexe) at security firm Escape, and it lived in a corner of the Admin REST API that most teams probably weren’t watching closely.

Red Hat published the CVE on July 24, 2026, and the Keycloak project shipped a fix five days later in version 26.7.0. The turnaround was fast, but the underlying lesson is one that keeps recurring in access control bugs: protecting the front door doesn’t guarantee every side door is locked too.

How the Bypass Actually Worked

Keycloak’s main user-listing endpoint behaved exactly as intended. A restricted administrator — say, a helpdesk account granted narrow permissions — who queried that endpoint without the view-users privilege got back an empty response, just as designed. Escape’s researchers confirmed that protection worked correctly.

The problem surfaced in a different, related endpoint: the one used to list which users are assigned to a specific role, reachable at /admin/realms/{realm}/roles/{role-name}/users. That endpoint checked only for broad role-viewing and user-query permissions, without applying the same per-user authorization filter used on the primary users API. The result was that a token which returned nothing from the main endpoint could still pull full user records — usernames, email addresses, first and last names, account status, and email verification status — through the role-members path instead.

Technically, the flaw traces back to a single method, RoleContainerResource.getUsersInRole, which fetched role members and converted them directly into user-facing data without first verifying the caller was authorized to view each individual record. It’s classified as broken object-level authorization (CWE-639), also commonly known as broken access control, and carries a CVSS score of 6.5, rated Medium.

Who Was Actually at Risk

Exploitation required an authenticated account that had been intentionally restricted — not an anonymous outsider, but someone already inside the system with limited privileges. That profile matters, because it’s precisely the kind of account many organizations create for support staff, contractors, or business-unit administrators who are supposed to see only a slice of the user directory.

Not every Keycloak deployment was affected equally. Realms using fine-grained admin permissions version 2 were safe, since filtering happens at the data-store layer in that model. The exposure was concentrated in deployments still running the default permission model, where the adminPermissionsEnabled setting is left at false — likely a large share of production installations, given that it’s not the newer opt-in configuration.

What Changed in the Fix

Version 26.7.0 adds the missing per-user visibility check before returning role-member data, closing the gap between the two endpoints. Administrators who manage multi-team or delegated Keycloak environments should treat the upgrade as a priority, particularly if they rely on scoped admin accounts as a security boundary rather than a convenience feature.

Recommended Follow-Up Steps

• Upgrade to Keycloak 26.7.0 or later as soon as possible.
• Audit accounts holding the query-users and view-realm roles, especially in environments where administration is split across teams or business units.
• Consider migrating to fine-grained admin permissions version 2, which enforces filtering at the data layer rather than per-endpoint.
• Test sibling and related API endpoints for consistent authorization behavior — this bug is a clear reminder that a hardened primary route says nothing about how alternate paths to the same data are protected.

Broken object-level authorization bugs like this one rarely make headlines the way a full authentication bypass does, but they’re arguably more common in real-world identity systems, precisely because they hide in the gaps between endpoints that look similar but were built or reviewed at different times. Any organization running its own identity provider — Keycloak or otherwise — should treat this disclosure as a cue to revisit how consistently authorization logic is applied across every API surface, not just the ones most obviously tied to sensitive data.