Обход авторизации между пространствами имён в consul-k8s даёт возможность получить в Consul права компонента, к которому доступа быть не должно. Ошибка кроется в правилах привязки списков контроля доступа (ACL, механизм выдачи прав в Consul): они связывают учётную запись Kubernetes с ролью внутри Consul. Затронуты установки с включённым автоматическим управлением системными ACL, поскольку там consul-k8s создаёт такие правила сам.
Правила привязки ACL и CVE-2026-110720 в consul-k8s
Уязвимость получила идентификатор CVE-2026-110720, уведомление HCSEC-2026-50 опубликовано 26 октября 2026 года. Уязвимыми вендор называет версии consul-k8s с 0.42.0 по 2.0.4, исправления вышли в 2.1.0 и 1.8.18. Оценку CVSS HashiCorp не приводит и уровень не указывает; данных об эксплуатации в реальных атаках в уведомлении тоже нет. Публичное раскрытие технических деталей означает лишь то, что они доступны, а не то, что уязвимость уже применяют.
При включённом управлении системными ACL consul-k8s настраивает аутентификацию Kubernetes и правила привязки Consul ACL. По этим правилам компоненты Consul входят в Consul через сервисные учётные записи Kubernetes (ServiceAccount, учётная запись для подов и процессов) и получают токены своих ролей. Правила должны были допускать вход только учётным записям из того пространства имён, где развёрнут Consul. Ограничение срабатывало не всегда.
В результате учётная запись из другого пространства имён может пройти проверку как компонент Consul и получить его права. Речь об обходе авторизации на границе пространств имён, а не о входе без всяких условий. Сначала атакующему нужны права Kubernetes на создание сервисной учётной записи и получение её токена в другом пространстве имён, а также сетевой доступ к API Consul. Учётные данные Consul при этом не требуются, а участие пользователя в уведомлении не описано.
Права в отдельном пространстве имён входят в условия атаки и не означают, что атакующий уже управляет пространством имён с Consul. Ошибка позволяет перейти эту границу, если правила привязки принимают подставленную учётную запись. Какие именно роли компонентов задеты и какие права можно получить, вендор не перечисляет. Полный административный захват для всех установок HashiCorp не подтверждает: описанный результат - доступ к правам того компонента, чью учётную запись удалось подставить.
Обходных мер HashiCorp не называет. В уведомлении есть только рекомендация оценить риск и обновиться до consul-k8s 2.1.0 или 1.8.18. Диапазон указан от 0.42.0 до 2.0.4, при этом исправление для ветки 1.8 вышло под номером 1.8.18; ориентиром служит номер исправления, а не граница диапазона.
Проверить подверженность можно по параметру global.acls.manageSystemACLs: значение true означает, что автоматическое управление системными ACL включено. Установки с отключённым управлением системными ACL вендор считает не подверженными уязвимости. Дополнительно проверяют, кто в кластере может создавать сервисные учётные записи в чужих пространствах имён и есть ли сетевой доступ к API Consul. Уязвимость обнаружил исследователь Elias Hasas (на GitHub - zer0d4y5).
Для администраторов кластеров с Consul значимость уязвимости определяется тем, что она снимает границу между пространствами имён при включённом управлении системными ACL. Без предварительных прав в Kubernetes она не работает, поэтому приоритет обновления зависит от того, насколько широко в кластере выдают права на создание сервисных учётных записей.
Ссылки
