CVE-2026-112816: Критична уразливість обходу автентифікації LXD і MicroCloud дозволяє захоплення кластера

Canonical випустила оновлення безпеки для усунення CVE-2026-112816, критичної уразливості обходу аутентифікації, що впливає на LXD та MicroCloud. Недолік має максимальний CVSS бал 10.0 і може дозволити неавтентифікованому віддаленому зловмиснику видавати себе за довіреного клієнта TLS без наявності приватного ключа цього клієнта.

Успішна експлуатація може забезпечити доступ до API LXD або MicroCloud з привілеями, призначеними для підставної особи. Коли довірена особа має достатні дозволи, зловмисник може отримати повний доступ до кластера, керованих віртуальних машин і потенційно до кореневого рівня доступу до хосту.

Уразливість походить від неправильної валідації ланцюжків сертифікатів клієнта, які використовуються для взаємної аутентифікації TLS. Замість аутентифікації лише кінцевого сертифіката, для якого клієнт доводить володіння відповідним приватним ключем, вразливі реалізації порівнюють кожен сертифікат, наданий у ланцюжку, керованому клієнтом, з довіреними сертифікатами.

Зловмисник, який може отримати доступ до HTTPS API і отримати загальнодоступний сертифікат вже довіреного клієнта, може прикріпити цей сертифікат позаду сертифіката, керованого зловмисником, і бути прийнятим як довірена особа.

Canonical повідомила про проблему наприкінці жовтня 2026 року після того, як уразливість була передана проектом Incus. Вже доступні виправлені версії LXD та MicroCloud, і адміністраторам настійно рекомендується оновити їх негайно.

Цей дефект особливо значний в інфраструктурних середовищах, оскільки LXD керує системними контейнерами та віртуальними машинами, а MicroCloud координує кластерну інфраструктуру. Компрометація адміністративної особи може тому поширитися за межі однієї служби і надати контроль над робочими навантаженнями чи самим хостом.

Для виявлення CVE-2026-112816 командам безпеки слід пріоритетно визначити LXD та MicroCloud HTTPS API, доступні з мережі чи інтернету, перевірити довірені сертифікати клієнтів і скорелювати аутентифікацію на основі сертифікатів з несподіваними системами джерел чи незвичними адміністративними операціями.

AI-Native Detection Intelligence Platform від SOC Prime дозволяє командам безпеки зміцнити покриття для експлуатації та поведінки після компрометації в мережі, Linux, хмарі, контейнера, та телеметрії ідентичності.

Зв’язатися з відділом продажів

Натисніть Explore Detections, щоб отримати доступ до відповідного змісту виявлення та логіки полювання. Для виявлення CVE-2026-112816 захисники повинні поєднувати інвентаризацію вразливих версій з моніторингом доступу до API, телеметрією аутентифікації сертифікатів та підозрілою адміністративною активністю, що впливає на контейнери, віртуальні машини або конфігурацію кластера.

Аналіз CVE-2026-112816

CVE-2026-112816 – це уразливість неправильної аутентифікації сертифікату в HTTPS слухачі, що використовується Canonical LXD і MicroCloud.

Обидва продукти можуть використовувати взаємну TLS для аутентифікації віддалених клієнтів. При нормальній поведінці mTLS підключений клієнт представляє сертифікат і доводить володіння приватним ключем, пов’язаним із сертифікатом, використаним як лист у ланцюжку TLS.

Проблема виникає, оскільки вразливі реалізації LXD та MicroCloud перевіряють більше, ніж автентифікований кінцевий сертифікат.

Згідно з Canonical, логіка аутентифікації віддаленого API порівнювала всі сертифікати, надані клієнтом, з записами в сховищі довірених сертифікатів. Однак TLS доводить володіння приватним ключем лише для кінцевого сертифіката. Додаткові сертифікати в наданому ланцюжку постачаються клієнтом і не доводять незалежно володіння їхніми відповідними приватними ключами.

Це створює зрив у аутентифікації.

Зловмисник може згенерувати сертифікат і приватний ключ, якими він керує, використовувати цей сертифікат як лист і додати загальнодоступний сертифікат довіреного клієнта в іншому місці в наданому ланцюжку. Вразливий сервер може знайти довірений сертифікат і співвіднести з’єднання з цією довіреною особою, навіть якщо зловмисник не володіє її приватним ключем.

Таким чином, деталі для CVE-2026-112816 показують, що експлуатація в основному залежить від двох попередніх умов:

• Зловмисник може дістатися до LXD або MicroCloud HTTPS API.
• Зловмисник володіє загальнодоступним сертифікатом особи, якій вже довірено ціль.

Приватний ключ довіреного клієнта не потрібен.

Це розрізнення пояснює критичну серйозність уразливості. Аутентифікація на основі сертифікатів повинна демонструвати володіння секретним приватним ключем, але уражена логіка фактично дозволяє задати володіння лише загальнодоступним сертифікатом, щоб задовольнити частину рішення про довіру.

Самостійна установка LXD не відкриває свій віддалений HTTPS API за замовчуванням. Hacker News відзначає, що LXD зазвичай слухає лише на своєму локальному сокеті UNIX, поки адміністратор не включить мережевий доступ, наприклад, через конфігурацію core.https_address.

Це означає, що не кожна вразлива установка LXD може бути експлуатована віддалено з іншого хоста.

Експозиція значно збільшується, коли адміністратори дозволяють доступ до API через керуючу мережу або відкривають її для інтернету.

MicroCloud представляє ще один важливий сценарій атаки. Canonical стверджує, що зловмисник, який може перехопити загальнодоступний TLS сертифікат машини, що приєднується до кластеру MicroCloud, може потім автентифікуватися як цей приєднаний учасник.

CVE-2026-112816 впливає на вразливі випуски Canonical LXD, включаючи 4.0.14, 5.0.10, 5.21.8 та 6.9 до їх відповідних виправлених випусків.

Canonical надає ці виправлені версії LXD:

• LXD 6.10.1 для каналу 6/stable
• LXD 5.21.9 для 5.21/stable
• LXD 5.0.11 для 5.0/stable
• LXD 4.0.15 для 4.0/stable

Для MicroCloud виправлені версії такі:

• MicroCloud 3.4.1 для 3/stable
• MicroCloud 2.1.5 для 2/stable

Реєстр CVE для Ubuntu описує успішну експлуатацію як таку, що дозволяє неавтентифікованому зловмиснику автентифікуватися як довірений клієнт і отримати повний доступ до кластера та керованих віртуальних машин через складений ланцюжок сертифікатів.

Максимальний CVSS бал 10.0 відображає мережеву доступність, низьку складність атаки, відсутність необхідних привілеїв та відсутність взаємодії з користувачем, а також потенційно високий вплив на конфіденційність, цілісність та доступність.

Вплив у кінцевому підсумку залежить від привілеїв обміненого обличчя.

Обмежена ідентичність може надати лише обмежені можливості API. Високопривілейований клієнт або кластерна ідентичність можуть надати суттєво більший доступ.

Canonical чітко попереджає, що обман довіреного користувача з привілеями може призвести до отримання root-доступу до машини-хоста.

Це може потенційно дозволити зловмиснику:

• Керувати або змінювати контейнери і віртуальні машини.
• Доступ до робочих навантажень, керованих через скомпрометоване середовище LXD.
• Змінити конфігурацію інфраструктури.
• Створити нові або змінити існуючі робочі навантаження.
• Перешкоджати доступності.
• Отримати доступ до даних, доступних обманеній ідентичності.
• Потенційно досягти хосту з привілеями кореневого рівня, коли доступні достатні дозволи.

Цей недолік був спочатку виявлений в пов’язаному проекті Incus, а потім переданий Canonical, яка підтвердила, що та сама проблема аутентифікації ланцюжка сертифікатів вплинула на LXD.

Incus описує основну проблему подібно: сервер запитував клієнтські сертифікати без перевірки всього наданого ланцюжка, в той час як перевірки довіри ітеративно перевіряли кожен наданий партнерський сертифікат замість обмеження аутентифікації до фактичного кінцевого сертифіката. Incus вирішив цю проблему у версії 7.6.0.

Здається, що уразливість існувала протягом довгого часу. Incus стверджує, що еквівалентна логіка аутентифікації була присутня з моменту його першого випуску. Публічне оголошення Canonical не надає точної дати, коли вразлива поведінка LXD була вперше впроваджена.

Станом на 2 листопада 2026 року, було опубліковано незалежну CVE-2026-112816 PoC та відтворення у лабораторії. Це представляє зміну від звіту Hacker News, опублікованого 1 листопада, який стверджував, що робочий експлойт ще не був випущений. Публічне відтворення з’явилося після розголошення і не є оригінальним дослідженням уразливості.

Canonical та згадана звітність не вказують на те, що уразливість була експлуатована в реальних атаках.

Hacker News повідомляє, що на момент оцінки CISA США, датованої 30 жовтня, питання не було відоме як таке, що використовується експлуатаційно, і не було включено в каталог відомих експлуатованих уразливостей CISA на той час.

Тому не існує специфічних для кампанії IOC для CVE-2026-112816, таких як підтверджені зловмисні IP-адреси, домени, геші шкідливого ПЗ або відома інфраструктура атакуючих, пов’язана з експлуатацією.

Захисникам слід зосередитися натомість на виявленні вразливості та поведінки.

Потенційні можливості для полювання включають:

• Віддалені підключення до LXD або MicroCloud HTTPS API з несподіваних систем.
• Успішна аутентифікація API, що походить з мереж, які зазвичай не використовуються довіреними адміністраторами.
• Ідентифікація довіреного сертифіката, що походить з декількох не пов’язаних між собою систем-джерел.
• Активність адміністративного API, яка не відповідає очікуваному власнику сертифіката.
• Несподіване створення, видалення або змінення контейнерів і віртуальних машин.
• Зміни в записах довірених сертифікатів.
• Нові або змінені учасники кластера.
• Неочікувані зміни зберігання, мереж, профілів, проектів або конфігурації екземпляра.
• Привілейовані операції, що відбуваються невдовзі після незвичної аутентифікації на основі сертифікатів.
• Підключення API до інтерфейсів управління, які не призначалися для віддаленого доступу.

Організації також повинні інвентаризувати довірені сертифікати, пов’язані з колишніми адміністраторами, списаними хостами, системами автоматизації та членами кластеру.

Оскільки експлуатація вимагає загальнодоступного сертифіката, а не приватного ключа, захисникам не слід вважати конфіденційність приватних ключів достатнім захистом від цієї конкретної уразливості.

Моніторинг також повинен враховувати спільні мережі управління.

API, яке не відкрито безпосередньо для інтернету, все ще може бути експлуатоване зловмисником, який вже отримав опору на іншій системі, здатній дістатися до інтерфейсу управління.

Це робить особливо актуальним горизонтальний рух всередині мережі. Компрометована робоча станція, сервер, CI/CD платформа, хост управління або хмарне навантаження з мережевим доступом до LXD API може забезпечити позицію, необхідну для експлуатації системи, що в іншому разі піддається внутрішньому впливу.

КНО-2026-112816: Зменшення ризиків

Canonical рекомендує негайно оновити вразливі установки LXD та MicroCloud до останніх виправлених версій.

Для пакетів на основі Snap, адміністратори можуть оновити за допомогою:

sudo snap refresh lxd

і:

sudo snap refresh microcloud

Після оновлення, перевірте фактичну встановлену версію, а не припускайте, що оновлення було успішно застосовано.

Canonical зауважила під час оприлюднення, що деякі точки випуску LXD переходили з кандидатських до стабільних каналів. Тому адміністраторам слід чітко підтвердити, що їхня система працює на одному з виправлених версій.

Основним заходом зменшення ризику CVE-2026-112816 є оновлення до:

Продукт	Виправлена версія
LXD 6.x	6.10.1
LXD 5.21	5.21.9
LXD 5.0	5.0.11
LXD 4.0	4.0.15
MicroCloud 3.x	3.4.1
MicroCloud 2.x	2.1.5

Canonical не опублікувала робочий обхід на основі конфігурації, який повністю виключає основний дефект аутентифікації.

Якщо негайне оновлення неможливе, обмежте мережевий доступ до HTTPS API настільки, наскільки це дозволяють операційні вимоги.

Тільки авторизовані керуючі хости та довірена інфраструктура повинні мати можливість встановлювати з’єднання з слухачем.

Для установок LXD, які не потребують віддаленого управління, адміністратори повинні оцінити, чи потрібно взагалі залишати мережевий API увімкненим.

Для середовищ, які вимагають віддаленого доступу:

• Обмежте API за допомогою фаєрволів хоста чи мережі.
• Дозволяйте з’єднання лише з виділених мереж управління.
• Уникайте безпосереднього відкриття API для інтернету.
• Використовуйте VPN чи адміністративний доступ на основі бастіону там, де це доречно.
• Розмежовуйте інфраструктуру управління контейнерами та віртуалізацією від користувацьких мереж.
• Моніторьте всі успішні адміністративні запити API.
• Перевірте довірені сертифікати та видаліть записи, які більше не потрібні.

Ці засоби керування зменшують експозицію, але не виправляють вразливу логіку перевірки сертифіката.

Організації, що використовують MicroCloud, повинні пріоритетно оновити всіх відповідних членів кластеру та переглянути останню активність приєднання для несподіваних систем або ідентичностей сертифікатів.

Адміністратори також повинні переглянути свої сховища довірених сертифікатів.

Видаляйте сертифікати, що належать списаним хостам, колишнім адміністраторам, невикористовуваним системам автоматизації або ідентичностям, які більше не потребують доступу.

У випадку виявлення підозрілої активності, дослідіть уражений хост та кластер перед обертанням облікових даних або зміною доказів.

Важливі джерела телеметрії можуть включати:

• Логи сервісів LXD та MicroCloud
• Логи системи Linux
• Фаєрволи та записи мережевих потоків
• Телеметрія зворотного проксі, якщо застосовано
• Дані EDR на хості
• Логи мережі хмари
• Конфігурація кластера та історія членства
• Записи адміністративних змін

Шукайте несподіване створення, змінення, видалення екземплярів, активність знімків, операції зберігання, зміни в мережах та оновлення конфігурації.

Якщо підозрюється експлуатація та ідентичність привілейованого сертифіката була підроблена, захисники повинні серйозно ставитися до можливості компрометації на рівні хоста, оскільки Canonical підтверджує, що доступ до root може бути можливим, залежно від дозволів постраждалої ідентичності.

Відповідачі на інциденти повинні зберегти відповідні свідчення та перевірити систему на предмет присутності шкідливого забезпечення, несанкціонованих облікових записів чи сертифікатів, змінених послуг, нових робочих навантажень, підозрілих процесів та ненормальних вихідних мережевих комунікацій.

Організації, які використовують Incus, а не Canonical LXD, повинні окремо оновитися до Incus 7.6.0 або до відповідної підтриманої виправленої випуску, оскільки пов’язаний проект був схильний тій же основній проблемі довіри ланцюжка сертифікатів.

Ubuntu також зазначає, що його архівні версії LXD для поточних випусків Ubuntu або не постачаються через шлях аффектованого пакету, або не піддаються впливу, тоді як безпекові рекомендації Canonical фокусуються на випусках Snap. Адміністратори повинні все ще перевірити дійсно встановлену дистрибуцію та версію LXD у своїх середовищах, а не припускати експозицію тільки на основі випуску Ubuntu.

Попередження: Контент для виявлення може бути недоступним для кожного CVE. Перевірте платформу SOC Prime для поточного покриття. Якщо відповідні виявлення ще недоступні, перевіряйте знову, оскільки нова загроза розвідки та контент для виявлення постійно додаються.