Canonical випустила виправлення для CVE-2026-112816 — критичної вразливості в продуктах LXD і MicroCloud, яка дозволяє зловмиснику пройти автентифікацію як будь-який довірений TLS-клієнт і отримати повний доступ до кластера та керованих віртуальних машин. Для експлуатації достатньо мережевого доступу до HTTPS API та публічного сертифіката довіреного клієнта — приватний ключ не потрібен. Якщо скомпрометований обліковий запис має привілеї, зловмисник може отримати root-доступ до хост-машини. Адміністраторам LXD і MicroCloud необхідно негайно оновити snap-пакети до виправлених версій.
Механізм вразливості
LXD і MicroCloud використовують mutual TLS для автентифікації віддалених клієнтів: клієнт пред’являє сертифікат, а сервер перевіряє його наявність у сховищі довірених ідентичностей (trust store). Проблема полягала в тому, як саме сервер виконував цю перевірку.
Згідно з бюлетенем безпеки Canonical, логіка автентифікації порівнювала усі сертифікати, передані клієнтом у ланцюжку, із записами в trust store. Однак TLS-рукостискання підтверджує володіння приватним ключем лише для першого сертифіката в ланцюжку — кінцевого (leaf). Решта сертифікатів у ланцюжку повністю контролюються клієнтом.
Це означає, що зловмисник міг сформувати ланцюжок сертифікатів, розмістивши власний кінцевий сертифікат першим, а публічний сертифікат довіреного клієнта — як проміжний. Сервер знаходив довірений сертифікат у ланцюжку та приймав з’єднання від імені цього клієнта, хоча зловмисник не володів його приватним ключем.
Уражені версії та виправлення
Згідно зі сторінкою CVE на Ubuntu, вразливості піддаються такі версії LXD:
- LXD 4.0.14 (виправлено у 4.0.15)
- LXD 5.0.10 (виправлено у 5.0.11)
- LXD 5.21.8 (виправлено у 5.21.9)
- LXD 6.9 (виправлено у 6.10.1)
Для MicroCloud Canonical випустила виправлені версії 2.1.5 і 3.4.1. Усі виправлення датовані 29 жовтня 2026 року та розповсюджуються через snap-канали.
Вразливість була виявлена не самою Canonical. Проєкт Incus — форк LXD, який розвивається спільнотою, — першим повідомив про проблему, після чого Canonical підтвердила, що та сама помилка зачіпає LXD. Incus виправив вразливість у версії 7.6.0 — це окремий продукт, і його версія не замінює оновлення LXD чи MicroCloud.
Уточнення щодо оцінки критичності
У низці публікацій цій вразливості приписується оцінка CVSS 10.0. Однак бюлетень Canonical для LXD і MicroCloud позначає проблему як критичну, не вказуючи числовий бал. Оцінка 10.0 явно присутня в бюлетені безпеки Incus для тієї ж вразливості в ланцюжку сертифікатів. Оскільки йдеться про той самий клас помилки, оцінка по суті застосовна, але формально її виставлено проєктом Incus, а не Canonical.
Відмінності у векторах атаки: LXD і MicroCloud
Практичні шляхи експлуатації відрізняються залежно від продукту. Для автономного сервера LXD атака потребує мережевої доступності HTTPS API, який за замовчуванням не відкритий — він прослуховує лише локальний сокет, якщо адміністратор не активував параметр core.https_address.
MicroCloud, який об’єднує кілька машин з LXD в єдиний кластер, створює додатковий вектор: за даними Canonical, зловмисник, здатний перехопити публічний TLS-сертифікат вузла в момент його приєднання до кластера, може згодом автентифікуватися від імені цього вузла. Це робить процедуру приєднання нових учасників до кластера особливо чутливою точкою.
Пріоритет під час усунення вразливості слід надати інсталяціям з відкритими API-слухачами та середовищам, де виконуються операції з розширення кластера.
Статус експлуатації
За наявними даними, ознак активної експлуатації вразливості не виявлено. CVE-2026-112816 не внесено до каталогу CISA Known Exploited Vulnerabilities, публічних експлойтів не опубліковано. Водночас відсутність у каталозі KEV саме по собі не є доказом того, що експлуатація не відбувалася.
Рекомендації
Для усунення вразливості:
- Оновіть snap-пакети:
sudo snap refresh lxdіsudo snap refresh microcloud - Після оновлення перевірте фактичну версію — на момент публікації бюлетеня Canonical виправлення для LXD перебували на етапі поступового переходу з каналу
candidateдоstable - Користувачам Incus необхідно оновитися до версії 7.6.0
Конфігураційного тимчасового рішення не існує — про це прямо заявляють і Canonical, і проєкт Incus. До встановлення оновлення єдиним заходом зниження ризику є обмеження мережевого доступу до HTTPS-слухача довіреними хостами.
Раніше ми вже висвітлювали критичні вразливості в екосистемі Ubuntu — наприклад, вразливість підвищення привілеїв pedit COW у ядрі Linux. CVE-2026-112816 відрізняється тим, що атака спрямована не на ядро, а на рівень оркестрації контейнерів і віртуальних машин, що у разі успішної експлуатації дає доступ одразу до всього кластера.
З огляду на відсутність тимчасових рішень і потенційний масштаб компрометації — від доступу до віртуальних машин до root на хості — оновлення snap-пакетів LXD і MicroCloud до виправлених версій є єдиним повноцінним заходом захисту, і його слід виконати без зволікань, особливо на інсталяціях з відкритим мережевим API.
