Уязвимость Keycloak: ограниченный администратор получает имена и email пользователей за пределами своей зоны

Keycloak устранила уязвимость сломанного контроля доступа, которая позволяла ограниченным администраторам получать имена пользователей, адреса email и другие данные профиля за пределами их разрешённой области. Проблема зарегистрирована как CVE-2026-17059 и находится в Admin REST API Keycloak. Нашёл её исследователь из Escape Энцо Монгин, известный как Orionexe. Red Hat опубликовала CVE 24 июля 2026 года, а исправление вышло 28 июля с релизом Keycloak 26.7.0.

В чём была дыра

Уязвимость затрагивала эндпоинт, который перечисляет участников конкретной роли: GET /admin/realms/{realm}/roles/{role-name}/users. Администратор с правами только query-users и view-realm мог вызвать этот эндпоинт и получить полные записи пользователей — участников ролей, которые ему разрешено просматривать. В раскрытых данных: имена, email, имя и фамилия, статус учётной записи и статус верификации email.

В Escape выяснили, что основной эндпоинт списка пользователей Keycloak защищал корректно: когда ограниченный администратор запрашивал стандартный users API, Keycloak возвращал пустой ответ, потому что у аккаунта не было привилегии view-users. А вот эндпоинт участников роли проверял только широкие права на просмотр ролей и запрос пользователей, не применяя тот же фильтр авторизации по каждому пользователю. В итоге тот же токен, который получал пустой список из основного users-эндпоинта, мог вытащить персональные данные через role-members API.

Это классический broken object-level authorization — сломанная авторизация на уровне объекта, по классификации CWE-639. Оценка CVSS — 6.5, уровень Medium. Эксплуатация требует аутентифицированный, но намеренно ограниченный аккаунт администратора, поэтому проблема особенно актуальна для организаций, которые делегируют частичное администрирование Keycloak службам поддержки или бизнес-подразделениям.

Где жила ошибка и что изменилось

Уязвимый путь кода находился в RoleContainerResource.getUsersInRole: метод получал участников роли и напрямую превращал их в представления пользователей, не проверяя, авторизован ли вызывающий на просмотр каждого конкретного пользователя. Исправление добавляет необходимую проверку видимости пользователей до того, как записи возвращаются.

Реалмы с fine-grained admin permissions версии 2 не затронуты — там фильтрация происходит на уровне хранилища данных. Под ударом в первую очередь развёртывания с моделью разрешений по умолчанию, где adminPermissionsEnabled имеет значение false.

Что делать

Организациям следует обновить Keycloak до версии 26.7.0 или новее. Администраторам стоит пересмотреть аккаунты с ролями query-users и view-realm, особенно в средах с несколькими командами. Также имеет смысл протестировать «соседние» эндпоинты API на согласованность авторизации: защищённый основной маршрут не гарантирует, что альтернативные пути применяют те же проверки доступа.

Для тех, кто раздаёт в Keycloak частичные права техподдержке — а это распространённая практика в компаниях с общими realm на сотрудников и клиентов, — обновление стоит провести в приоритетном порядке, пока в руки ограниченного администратора не попали чужие персональные данные.

Источник: cybersecuritynews.com