В LXD и MicroCloud исправили CVE-2026-112816: через ошибку проверки цепочки клиентских сертификатов атакующий может выдать себя за доверенного клиента HTTPS API. Canonical оценила уязвимость в CVSS 4.0 10.0. Как сообщает Rescana в материале на источник, исправленные версии snap опубликованы 29 октября 2026 года. Практический приоритет — найти узлы с сетевым API, закрыть к нему лишний доступ и проверить, что обновление действительно установилось.
Где сертификат перестаёт быть доказательством личности
LXD принимает удалённых клиентов по взаимной TLS-аутентификации: клиент предъявляет сертификат, сервер сверяет его со списком доверенных. Ошибка была в том, что проверка учитывала все сертификаты присланной цепочки. Но владение закрытым ключом доказывает только конечный, или листовой, сертификат. Атакующий мог предъявить собственный листовой сертификат, вложить публичный сертификат доверенного клиента дальше в цепочку и пройти проверку от его имени. Закрытый ключ доверенного клиента для этого не нужен.
У атаки есть два обязательных условия: возможность достучаться до HTTPS API и получить публичную часть сертификата клиента, которому сервер уже доверяет. В MicroCloud описан сценарий с перехватом публичного сертификата участника, присоединяющегося к кластеру. Результат зависит от скопированной учётной записи: для LXD речь идёт о доступе к кластеру и управляемым виртуальным машинам; Canonical также допускает получение root-доступа к хосту, если привилегии жертвы это позволяют.
Оценка 10.0 описывает тяжесть возможного результата, а не число доступных извне установок. У отдельного сервера LXD сетевой API по умолчанию выключен: пока администратор не настроил core.https_address, доступ идёт через локальный Unix-сокет. Для кластеров и MicroCloud картина другая — участникам требуется сетевое взаимодействие. Именно их стоит поставить в начало очереди проверки.
На момент проверки Rescana 2 ноября 2026 года сообщений об эксплуатации не было, а запись отсутствовала в каталоге CISA KEV. При этом 1 ноября появился публичный лабораторный прототип обхода. Это не свидетельство атаки на чью-либо инфраструктуру, но достаточная причина не откладывать работу до планового пересмотра безопасности.
План работ для своих узлов
- Составьте список установок и владельцев. Найдите хосты с LXD и MicroCloud, отдельно пометьте кластеры, стенды CI и площадки, где работают чужие или клиентские нагрузки. Проверьте способ установки: исправления Canonical относятся к snap. Пакеты lxd из архива Ubuntu, согласно приведённым данным Ubuntu, этой уязвимости не подвержены либо не поставляются для соответствующих выпусков. Зачем это делать первым: иначе легко обновить не тот пакет и оставить рабочий API без исправления.
- Проверьте, слушает ли API сеть. На каждом узле выполните lxc config get core.https_address. Пустое значение для отдельного хоста означает, что сетевой слушатель не включён. В кластере дополнительно проверьте cluster.https_address; не переносите вывод с одного сервера на весь кластер. Сопоставьте настроенные адреса с правилами межсетевого экрана: доступ из административной сети и доступ из интернета — разные уровни срочности.
- Сузьте доступ до установки исправления. Разрешите соединения с HTTPS API только известным управляющим хостам и необходимым участникам кластера. Проверяйте фактически настроенный порт; часто речь идёт о 8443, но полагаться на это без проверки нельзя. У Canonical нет описанного обходного решения для LXD через настройку самой службы. Сетевое ограничение уменьшает круг тех, кто сможет использовать ошибку, но обновление не заменяет.
- Обновите snap и проверьте результат. Для установленных компонентов выполните sudo snap refresh lxd и sudo snap refresh microcloud. Исправленные выпуски LXD — 6.10.1, 5.21.9, 5.0.11 и 4.0.15; MicroCloud — 3.4.1 и 2.1.5. Затем проверьте установленные версии через snap list lxd microcloud, если оба компонента присутствуют, либо по отдельности. Сверяйте результат с веткой, которую используете: Canonical выкатывала исправления поэтапно, поэтому успешная команда обновления сама по себе ещё не доказывает, что получена исправленная версия.
- Проверьте работу после обновления. Из разрешённой управляющей сети убедитесь, что штатные клиенты подключаются, а управление инстансами и взаимодействие участников кластера работают. Из сети, которой доступ не положен, проверьте отсутствие соединения. Зафиксируйте версии и результат в заявке на изменение: следующей смене важнее видеть проверенный итог, чем запись «snap обновлён».
Перед работами на загруженном кластере согласуйте окно с владельцами нагрузок и порядок проверки узлов. Не начинайте присоединять новых участников MicroCloud до завершения обновления: описанный для него сценарий связан именно с сертификатом вступающего участника. Если у вас Incus, учитывайте его отдельно — проект выпустил собственное исправление в версии 7.6.0. Не переносите дополнительные детали его бюллетеня автоматически на LXD: это родственные, но разные продукты.
После патча проверьте не только номер версии
Если API был доступен из широкой сети, одной установки исправления мало для разбора прошлого доступа. Снимите текущий список доверенных сертификатов командой lxc config trust list и сравните его с учётными записями администраторов и историей согласованных изменений. Проверьте неожиданные добавления, продления и удаления сертификатов, а также изменения инстансов, образов, томов и проектов. При наличии журналов API или внешнего аудита сопоставьте обращения с адресами штатных управляющих хостов.
Эти проверки не являются готовым детектором атаки: злоумышленник в таком сценарии представляется уже доверенным клиентом, поэтому запись может выглядеть как обычное действие администратора. Опубликованных индикаторов компрометации в описании Rescana нет. Если обнаружились необъяснимые операции, сохраняйте журналы и разбирайте инцидент по своей процедуре, а не удаляйте подозрительный сертификат без фиксации следов.
Что спросить у подрядчика и где обычно ошибаются
В Казахстане LXD может оказаться не только в собственной серверной, но и за услугой хостинга, управляемой платформой или сборочным контуром подрядчика. Ответ «у нас виртуальные машины» ничего не говорит о том, чем управляют хостами. Запросите у поставщика услуг конкретный ответ: используются ли LXD, MicroCloud или Incus для ваших нагрузок; доступен ли их HTTPS API по сети и кому; какая версия установлена после исправления; проверялись ли изменения доверенных сертификатов и действия с вашими инстансами. Для закупки или продления услуги полезно закрепить порядок уведомления об уязвимостях и предоставления подтверждения обновлений в документации, а не довольствоваться общей формулировкой о безопасности.
- Не путайте публичный и закрытый ключ. Отсутствие утечки закрытого ключа здесь не означает безопасности. Но и одного доступа к API недостаточно: атакующему нужен публичный сертификат уже доверенного клиента.
- Не объявляйте все старые версии безопасными по таблице. Запись CVE называет начальные версии затронутых веток LXD, но не признаёт более ранние выпуски безопасными. Ориентир для решения — исправленная версия вашей ветки и рекомендация Canonical обновиться.
- Не считайте закрытый от интернета кластер неуязвимым. Ограничение доступа снижает риск, но при наличии доступа к управляющей сети ошибка проверки сертификатов остаётся до обновления.
- Не переносите выводы об Incus на LXD. Например, сведения Incus о выдаче серверного сертификата при TLS-соединении относятся к его собственному бюллетеню. Для оценки условий атаки на LXD используйте описанные Canonical требования к доступу и доверенному сертификату.
CVE-2026-112816 требует срочного внимания там, где HTTPS API LXD или MicroCloud работает по сети: сначала ограничьте доступ, затем обновите snap и подтвердите версию и работу кластера. На отдельных узлах без сетевого API начните с проверки конфигурации, а не с предположения о внешней атаке. За практическими разборами для серверной инфраструктуры можно следить в блоге Даны.