Обход авторизации в API листовых сертификатов Consul и Consul Enterprise позволяет получить сертификат сервиса вместе с закрытым ключом, не имея действующего токена управления доступом (ACL). Листовой сертификат - удостоверение отдельного сервиса в сервисной сетке, его используют для взаимной аутентификации TLS (mTLS). С такой парой можно выдавать себя за сервис и обращаться к сервисам, которые разрешены для этого удостоверения правилами намерений (intentions), то есть списками того, каким сервисам позволено соединяться. Затронуты ветки 1.17 и 2.0 обоих продуктов, причём проблема проявляется только при включённом управлении доступом.
CVE-2026-105765 в API листовых сертификатов Consul
Уязвимость получила идентификатор CVE-2026-105765. Причина - порядок проверки прав в агенте Consul, то есть в процессе на каждом узле, через который локальные сервисы получают сертификаты и настройки. Агент требовал право на запись для сервиса (service:write) только тогда, когда сертификат нужно было выпустить заново; это право разрешает выпуск сертификата от имени сервиса. Если подходящий сертификат уже лежал в кэше агента, тот отдавал его вместе с закрытым ключом, не сверяя токен вызывающей стороны.
Кэш появился, чтобы снизить нагрузку на серверы Consul, поэтому в нём обычно лежат сертификаты сервисов, чьими прокси-сайдкарами управляет этот агент. Для атаки достаточно сетевого доступа к HTTP API агента: аутентификация не нужна, участие пользователя не требуется. Объём раскрытия ограничен теми сертификатами, что уже находятся в кэше доступного агента. Серверы Consul, управляющие прокси в развёртываниях Consul Dataplane, могут держать в кэше сертификаты множества сервисов, и там размах шире.
По умолчанию HTTP API агента слушает только интерфейс обратной петли (loopback). В такой конфигурации добраться до него могут лишь процессы на том же хосте, что заметно сужает круг возможных злоумышленников. Оценка риска поэтому начинается с конфигурации агента: включены ли ACL, слушает ли API только обратную петлю, какие сервисы к этому агенту привязаны.
Оценку CVSS вендор не приводит, уровень серьёзности тоже не указывает. Условия атаки он описывает прямо: сетевой доступ к агенту, отсутствие токена и отсутствие участия пользователя.
Сведений о применении уязвимости в реальных атаках в уведомлении нет, о случаях компрометации вендор не сообщает. Публикация бюллетеня означает, что технические детали стали доступны, а не то, что проблему уже используют. Уведомление HCSEC-2026-46 вышло 26 октября 2026 года; об уязвимости вендору сообщил Tomas Castillo.
Исправление вышло в Consul Community Edition 2.1.0, а также в Consul Enterprise 2.1.0 и 1.21.19. Если обновиться сразу не получается, вендор предлагает ограничить сетевой доступ к HTTP API агента. Второй вариант - заблокировать конечную точку выдачи листовых сертификатов параметром http_config.block_endpoints. Он подходит только тогда, когда от этой конечной точки не зависят приложения с нативной поддержкой Connect и конфигурации consul-template на этом агенте. Других обходных мер вендор не называет.
Значимость зависит от конфигурации. Когда API агента доступен только с того же хоста, риск невелик. Если же доступ открыт по сети, а в кэше лежат сертификаты многих сервисов, чужой закрытый ключ позволяет действовать от имени сервиса внутри сетки. Обновление до Consul 2.1.0 или до Consul Enterprise 2.1.0 и 1.21.19 закрывает уязвимость.
Ссылки
