Incus и Canonical LXD принимают клиентские сертификаты, но не проверяют всю цепочку. Из-за этого любой, кто дотягивается до HTTPS-слушателя, выдает себя за доверенное удостоверение. Ни учетные данные, ни закрытый ключ от чужого сертификата не нужны. Под угрозой кластеры и управляемые ими виртуальные машины. Обе истории производители описывают как обход аутентификации и авторизации.
Как работает подмена
Слушатель HTTPS запрашивает клиентский сертификат при согласовании TLS. Проверка при этом ограничена первым звеном: рукопожатие подтверждает владение ключом только от него. Остальные сертификаты в цепочке присылает сам клиент, и они целиком в его власти. Проверка подлинности сверяла с хранилищем доверия каждое звено присланной цепочки. Поэтому достаточно дописать в нее открытую часть чужого доверенного сертификата.
Серверные сертификаты делают атаку особенно простой. Их отдает каждое рукопожатие TLS, так что добывать что-то заранее не требуется. Приписав сертификат целевого сервера, клиент попадает на шлюз базы данных. Сертификат другого участника кластера дает доступ внутрь кластера, и проверка авторизации обходится целиком.
Что задевает уязвимость
Последствия не заканчиваются на входе в систему. Через механизмы самообслуживания клиент продлевает или удаляет любую запись в хранилище доверия. Затронута и проверка подлинности агента между хостом и виртуальными машинами. Непроверенная цепочка доходит до сценариев авторизации, и клиент подсовывает им выбранные им сертификаты.
Решение сценария меняется даже у клиентов на токенах или OpenID Connect. Взаимная аутентификация по TLS их не касается, но произвольный сертификат при рукопожатии они все равно присылают. Условие атаки одно - сетевой доступ к HTTPS-слушателю. Учетная запись, токен и закрытый ключ не нужны.
Из этого следует практический вывод. Выставленный наружу слушатель превращает открытую часть любого доступного сертификата в пропуск к инфраструктуре. Клиентские сертификаты при этом читает любой доверенный клиент через API сертификатов.
Кластер LXD управляет виртуальными машинами и хранит их настройки. Вход от имени участника кластера дает контроль над этой плоскостью управления. Отсюда и масштаб: одна подделанная цепочка открывает не одну систему, а весь кластер вместе с его виртуальными машинами.
Версии и исправления
Incus описан в уведомлении GHSA-xg75-xf37-cph9. Максимальная оценка CVSS - 10,0 из 10. Уязвимы все выпуски до 7.6.0, исправление вышло в 7.6.0. Идентификатор CVE уведомлению не присвоен. Слабость отнесена к CWE-287 и CWE-295: неверная аутентификация и неверная проверка сертификатов. Сопровождающие Incus пишут, что поведение сохранялось с первого выпуска.
Canonical ведет историю с LXD как CVE-2026-112816, публикация от 30 октября 2026 года. Уязвимы версии 4.0.14, 5.0.10, 5.21.8 и 6.9. Исправления - 4.0.15, 5.0.11, 5.21.9 и 6.10.1 соответственно. В уведомлении описаны неаутентифицированный доступ к кластерам и управляемым виртуальным машинам через собранные вручную цепочки сертификатов.
Сведений об эксплуатации в реальных атаках ни одно из уведомлений не приводит. Похожие по последствиям обходы аутентификации ранее описывали в Teleport и HashiCorp Consul, но механизм там другой. Отдельная уязвимость в cluster-proxy Red Hat тоже касается управления кластером, однако опирается на подделку серверных запросов, а не на цепочку сертификатов.
Что делать до патча
Обновите Incus до 7.6.0 или более поздней версии. Для LXD поставьте исправленный выпуск из своей ветки. До установки ограничьте сетевой доступ к HTTPS-слушателю доверенными хостами. Настройки, которая закрыла бы уязвимость, нет - сопровождающие Incus говорят об этом прямо. Сетевое ограничение снижает риск, но проверку сертификатов не исправляет.
После обновления вход опирается на сертификат, ключом от которого клиент действительно владеет. Приписанное чужое звено больше не дает доступа. Для добросовестных клиентов с настоящими ключами порядок работы не меняется.
Ссылки
