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