LXD управляет системными контейнерами и виртуальными машинами. MicroCloud собирает несколько таких хостов в общий кластер. Оба продукта принимают команды по HTTPS API и опознают клиента по сертификату. Ошибка в этой проверке позволяет выдать себя за другого клиента, зная только его публичный сертификат.
Ошибка в проверке цепочки сертификатов
LXD работает по схеме mutual TLS: клиент и сервер предъявляют сертификаты друг другу. Сервер сверяет присланное со списком доверенных. Раньше он проверял всю цепочку целиком, а не одно последнее звено. Владение закрытым ключом доказывает только конечный сертификат. Промежуточные звенья такого доказательства не дают.
На этом и строится атака. Свой сертификат, уже внесённый в список доверенных, злоумышленник ставит в цепочку промежуточным звеном. Сервер видит знакомую запись и пропускает соединение. Доступ открывается от чужого имени, хотя ключ жертвы остаётся у неё.
Публичный сертификат клиента секретом не считается. В кластере LXD сертификаты узлов и администраторов передаются по сети и хранятся в конфигурации. Собрать исходные данные для такой атаки проще, чем подобрать ключ.
API LXD обычно открыт по сети: иначе кластером неудобно управлять. Чем шире доступ к нему, тем больше машин, с которых проходит атака. Соединение при этом выглядит как обычный вход доверенного клиента. Поэтому журналы сами по себе картину не проясняют.
Что нужно для атаки
Нужны сетевой доступ к HTTPS API LXD и публичный сертификат доверенного клиента. Учётные данные не требуются, участие пользователя тоже. Сложность низкая, атака идёт по сети. Canonical оценила уязвимость по CVSS 4.0 в 10,0 из 10.
Дальше всё зависит от прав имитируемого клиента. Обычный клиент открывает доступ к кластеру и управляемым виртуальным машинам. Администратор - к root на хосте, где работает LXD. Вредоносный код для этого не нужен.
Ошибку обнаружили вне Canonical. Её передали в компанию из проекта Incus и подтвердили, что LXD затронут так же.
Перехват сертификата в MicroCloud
Отдельный сценарий Canonical описывает для MicroCloud. Когда новый узел вступает в кластер, его публичный TLS-сертификат уходит по сети. Перехватив его, атакующий позже входит в кластер как этот узел. Права снова равны правам того, чей сертификат он взял.
Обновлять нужно каждый хост, а не только точку входа. Проверку выполняет демон на конкретной машине, и старая версия продолжает принимать соединения. Заодно стоит пересмотреть, кому выдан доступ к API: лишние доверенные клиенты расширяют круг тех, чей сертификат годится для обхода.
Какие версии закрывают ошибку
Исправления вышли 29 октября 2026 года. Для LXD это 4.0.15, 5.0.11, 5.21.9 и 6.10.1 в соответствующих ветках. Для MicroCloud - 2.1.5 в канале 2/stable и 3.4.1 в канале 3/stable. Обновляют пакеты штатными средствами snap.
После установки доверие даёт только конечный сертификат, подкреплённый ключом. Промежуточные звенья перестают быть пропуском. Для добросовестных клиентов ничего не меняется: их сертификаты выпущены обычным порядком.
На момент публикации уведомления точечные релизы LXD ещё раскатывались из candidate в stable. Обновление может прийти не сразу. Проверить установленную версию стоит вручную и при необходимости переключиться на нужный канал. Обходных мер Canonical не приводит.
Уведомление вышло 28 октября, исправления - 29 октября, запись CVE - 30 октября. Сведений об эксплуатации в реальных атаках нет. CISA в разборе SSVC ставит эксплуатацию на уровень none, автоматизацию атаки считает возможной, техническое влияние - полным. Иначе говоря, атаку проводят без ручной подгонки под конкретную жертву.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-112816
- https://github.com/canonical/lxd/security/advisories/GHSA-99jp-jwmc-65p4
- https://discourse.ubuntu.com/t/security-advisory-critical-vulnerability-found-in-canonical-lxd-and-microcloud/90557
