Критическая ошибка в аутентификации Canonical LXD и MicroCloud получила идентификатор CVE-2026-112816 и максимальную оценку CVSS 10.0. Злоумышленнику достаточно иметь сетевой доступ к HTTPS API и получить публичный сертификат клиента, которому сервер уже доверяет. Закрытый ключ этого клиента не нужен.
LXD и MicroCloud используют взаимную TLS-аутентификацию (mTLS): подключающийся клиент предъявляет сертификат, а сервер сверяет сертификаты с хранилищем доверенных идентификаторов. Проблема заключалась в том, что сервер проверял все сертификаты, переданные клиентом. При этом TLS подтверждает владение закрытым ключом только для первого сертификата в цепочке, так называемого конечного (leaf) сертификата. Остальные сертификаты клиент может приложить сам.
Этим можно было воспользоваться: атакующий создавал собственный сертификат, а за ним помещал публичный сертификат доверенного клиента. Сервер находил этот сертификат в хранилище и принимал соединение за подключение доверенной стороны. Публичный сертификат не является секретом, поэтому похищать закрытый ключ не требовалось.
Успешная подмена личности давала атакующему права соответствующего клиента в кластере и доступ к виртуальным машинам. Если клиент обладал привилегиями администратора, Canonical предупреждала о возможности получить «root-доступ к хост-машине».
Для атаки нужны одновременно доступ к HTTPS API и публичный сертификат уже доверенного клиента. У автономного сервера LXD API по умолчанию доступен только через локальный сокет, а не по сети. Сетевой интерфейс включается администратором через параметр
Проблему первой обнаружил проект Incus, общественный форк LXD. Canonical подтвердила, что уязвим также LXD. Incus устранил её в версии 7.6.0 вместе с 17 другими проблемами безопасности. Запись CVE перечисляет версии LXD 4.0.14, 5.0.10, 5.21.8 и затем обрывается на «6.»; полная версия в доступных данных не указана.
Исправления Canonical выпущены для snap-пакетов: LXD 6.10.1 в канале
Публичных свидетельств эксплуатации пока нет, работающий эксплойт не опубликован. В записи CVE приведена оценка CISA от 30 октября, год не указан: на тот момент ведомству не было известно об использовании уязвимости в атаках. В список CISA Known Exploited Vulnerabilities она не включена.
Пользователям следует обновить LXD и MicroCloud. Для snap-установок команды такие:
Изображение носит иллюстративный характер
LXD и MicroCloud используют взаимную TLS-аутентификацию (mTLS): подключающийся клиент предъявляет сертификат, а сервер сверяет сертификаты с хранилищем доверенных идентификаторов. Проблема заключалась в том, что сервер проверял все сертификаты, переданные клиентом. При этом TLS подтверждает владение закрытым ключом только для первого сертификата в цепочке, так называемого конечного (leaf) сертификата. Остальные сертификаты клиент может приложить сам.
Этим можно было воспользоваться: атакующий создавал собственный сертификат, а за ним помещал публичный сертификат доверенного клиента. Сервер находил этот сертификат в хранилище и принимал соединение за подключение доверенной стороны. Публичный сертификат не является секретом, поэтому похищать закрытый ключ не требовалось.
Успешная подмена личности давала атакующему права соответствующего клиента в кластере и доступ к виртуальным машинам. Если клиент обладал привилегиями администратора, Canonical предупреждала о возможности получить «root-доступ к хост-машине».
Для атаки нужны одновременно доступ к HTTPS API и публичный сертификат уже доверенного клиента. У автономного сервера LXD API по умолчанию доступен только через локальный сокет, а не по сети. Сетевой интерфейс включается администратором через параметр
core.https_address. В MicroCloud несколько машин с LXD объединяются в кластер; Canonical отдельно указала на риск перехвата публичного сертификата участника в момент его присоединения. Получив его, злоумышленник мог войти от имени этого участника. Проблему первой обнаружил проект Incus, общественный форк LXD. Canonical подтвердила, что уязвим также LXD. Incus устранил её в версии 7.6.0 вместе с 17 другими проблемами безопасности. Запись CVE перечисляет версии LXD 4.0.14, 5.0.10, 5.21.8 и затем обрывается на «6.»; полная версия в доступных данных не указана.
Исправления Canonical выпущены для snap-пакетов: LXD 6.10.1 в канале
6/stable, 5.21.9 в 5.21/stable, 5.0.11 в 5.0/stable и 4.0.15 в 4.0/stable. Для MicroCloud исправлены версии 3.4.1 в 3/stable и 2.1.5 в 2/stable. Пакеты LXD из архивов Ubuntu отмечены как не затронутые либо не поставлявшиеся; речь об исправлениях именно snap-версий. Публичных свидетельств эксплуатации пока нет, работающий эксплойт не опубликован. В записи CVE приведена оценка CISA от 30 октября, год не указан: на тот момент ведомству не было известно об использовании уязвимости в атаках. В список CISA Known Exploited Vulnerabilities она не включена.
Пользователям следует обновить LXD и MicroCloud. Для snap-установок команды такие:
sudo snap refresh lxd и sudo snap refresh microcloud. На момент выпуска уведомления Canonical исправленные версии LXD ещё переходили из канала candidate в stable, поэтому после обновления нужно проверить установленную версию. Временного обходного решения для LXD Canonical не предложила; до установки исправления стоит ограничить доступ к API по сети. Проект Incus также сообщил, что настройки, исправляющей проблему, нет: его рекомендация на переходный период — ограничить сетевой доступ к слушателю API и обновиться до версии 7.6.0.
