Критическая уязвимость Keycloak с идентификатором CVE-2026-18963 получила оценку 9.1 по CVSS и в худшем сценарии позволяет удалённо захватить любой аккаунт, включая административный. Для компаний, которые держат SSO, IAM и клиентские кабинеты на Keycloak, это не очередной «технический баг», а прямой риск потери контроля над всей связкой сервисов, завязанных на авторизацию.
По данным The Hacker News, Red Hat и разработчики Keycloak уже выпустили исправления. Проблема затрагивает сценарий восстановления пароля: злоумышленнику не нужна авторизация, не нужно участие пользователя и, если верить опубликованному описанию, не нужен даже почтовый токен, который обычно должен подтверждать смену пароля. Ошибка классифицирована как CWE-640, то есть слабый механизм восстановления забытого пароля. Для upstream-версии совет простой: обновляться до Keycloak 26.7.2, выпущенной 19 августа 2026 года. Для Red Hat build of Keycloak исправления вышли в ветках 26.4.15 и 26.6.6.
Корень проблемы Red Hat описывает как некорректную проверку состояния во flow reset-credentials. Если перевести с языка advisory на нормальный инженерный русский, баг сидит в логике переходов внутри сценария сброса пароля. Атакующий отправляет специально сформированный запрос на endpoint восстановления доступа, после чего сессия аутентификации перескакивает сразу к этапу обновления пароля. Шаг с action token, который в штатном процессе должен прилететь пользователю на e-mail и подтвердить право на смену пароля, просто выпадает из цепочки. Результат неприятно прямолинеен: можно сбросить пароль любой учётной записи и зайти под ней.
Отдельно настораживает то, что речь идёт не о локальной эскалации и не о сложной атаке с длинной цепочкой условий. Red Hat прямо оценила сценарий как Critical именно потому, что эксплуатировать его можно удалённо, без аутентификации и без взаимодействия со стороны жертвы. На практике это означает, что под удар попадают не только рядовые пользователи, но и администраторы realm'ов, владельцы сервисных учёток и все системы, где Keycloak стоит фронт-дверью для доступа. Исследователь Escape Энцо Монжен, комментируя другую уязвимость Keycloak, найденную им в июле, формулировал это ещё жёстче: если атакующий прошёл границу Keycloak, дальше он получает доступ ко всему, что стоит за ним. В случае с IAM это не драматизация, а обычная архитектурная реальность.
С патчами ситуация относительно ясная, хотя не идеально прозрачная. 18 августа 2026 года Red Hat выпустила четыре errata: RHSA-2026:56519, RHSA-2026:56520, RHSA-2026:56523 и RHSA-2026:56524. Они закрывают проблему как в пакетах standalone-сервера, так и в контейнерных образах для двух потоков RHBK. Для ветки 26.4 безопасными названы operator bundle 26.4.15-1 и образы rhbk/keycloak-rhel9 и rhbk/keycloak-rhel9-operator версии 26.4-23. Для ветки 26.6 исправление пришло в operator bundle 26.6.6-1 и контейнеры keycloak-rhel9 и operator версии 26.6-12. При этом в GitHub advisory затронутые и исправленные версии почему-то помечены как unknown, а запись CVE опирается в основном на продуктовые ссылки Red Hat. Не катастрофа, но для команд, которые любят автоматическую инвентаризацию и сверку по нескольким источникам, это лишний повод не доверять одному экрану в сканере уязвимостей.
Пока нет подтверждений, что CVE-2026-18963 уже использовали в реальных атаках, и по состоянию на 24 августа 2026 года не найден публично подтверждённый эксплойт. Это хорошая новость, но без повода расслабляться. Во-первых, сама механика бага выглядит достаточно конкретной, чтобы уязвимость быстро разобрали исследователи и offensive-команды. Во-вторых, Keycloak в последние недели и без того живёт в режиме плотного патч-менеджмента. Релиз 26.7.2 закрывает сразу восемь CVE, включая ещё одну проблему с захватом аккаунта через предсказуемый account-linking hash в OIDC-клиенте под номером CVE-2026-15571. А ещё двумя неделями раньше, 5 августа, версия 26.7.1 пришла с исправлениями для двенадцати CVE, среди них были обход ограничения link-only в SAML identity-provider-initiated broker login и возможность подделки ролей через user property mappers в политике динамической регистрации клиентов по умолчанию. Если коротко: уязвимость Keycloak здесь не выглядит случайной единичной осечкой.
Тем, кто не может обновиться немедленно, Red Hat предложила временную меру: отключить функцию Forgot password во всех realm'ах. Именно во всех, а не в том одном, который первым приходит в голову при слове production. В административной консоли настройка находится в Realm settings, затем Login, затем Forgot password. Такой обходной путь неудобен для поддержки пользователей и почти наверняка добавит ручной работы helpdesk-командам, но выбор тут довольно приземлённый: либо неудобный процесс восстановления доступа, либо окно для takeover без авторизации. Любопытная деталь: Univention 20 августа отдельно заявила, что её Nubus этой проблемой не затронут, потому что функция восстановления пароля в их развёртываниях Keycloak не включена. Неплохое напоминание о том, что secure-by-default иногда выглядит скучно ровно до первого CVE с баллом за девять.
Для российских и русскоязычных команд вывод тоже без особой магии. Если Keycloak у вас стоит как центральный шлюз в корпоративную идентификацию, B2B-портал, кабинет клиента или внутренние dev-платформы, проверять нужно не только номер версии, но и фактическую конфигурацию realm'ов, наличие включённого восстановления пароля и состояние контейнерных образов в кластере. Полезно также быстро перепроверить, где администраторские аккаунты защищены только паролем, а где поверх включены дополнительные факторы. Red Hat указала, что о баге сообщил James Paremain, но опубликованные материалы пока не отвечают на два неприятных вопроса: полностью ли патч закрывает проблему и эксплуатируется ли каждый realm с включённым Forgot password, либо только определённые конфигурации reset-credentials flow. Для платформенного ПО это как раз тот случай, когда формулировка «исправлено» не отменяет необходимости руками проверить, что именно у вас было включено и как это работало до патча.