Критична уязвимост в продуктите LXD и MicroCloud на Canonical позволява на атакуващ да влезе в системата като доверен клиент, без да притежава неговия частен ключ. За да постигне това, атакуващият трябва да има мрежов достъп до техния HTTPS API интерфейс и да разполага с публичния сертификат на доверения клиент.
След като получи достъп, атакуващият може да действа от името на този клиент, получавайки достъп до клъстера и неговите виртуални машини. Ако компрометираният акаунт е с високи привилегии, атакуващият може да получи „root достъп до хост машината“, посочват от Canonical.
Уязвимостта, проследявана като CVE-2026-112816, е с максимална оценка по CVSS от 10.0, а Canonical вече пусна обновени версии и на двата продукта с отстранена уязвимост.
Как работи уязвимостта
LXD и MicroCloud позволяват на отдалечени клиенти да осъществяват достъп до техните API интерфейси чрез двупосочен TLS (mutual TLS) – конфигурация, при която клиентът представя сертификат, за да докаже своята идентичност. Даден клиент се счита за доверен, когато неговият сертификат присъства в хранилището за доверие на сървъра – списъка с идентичности, които сървърът приема.
Проблемът се крие в начина, по който сървърът проверява този сертификат. Той сравнява всеки сертификат, изпратен от клиента, с хранилището за доверие, но TLS връзката доказва само, че клиентът притежава частния ключ за първия сертификат във веригата (крайния сертификат). Останалата част от веригата е всичко онова, което клиентът е избрал да прикачи.
По този начин атакуващият може да вземе публичния сертификат на доверен клиент, който не е таен, да го прикачи към веригата след своя собствен сертификат и сървърът ще го приеме за този доверен клиент.
Кой е засегнат
Експлоатирането на уязвимостта изисква две неща: мрежов достъп до 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.
Собствените архивни пакети на Ubuntu за LXD са отбелязани като незасегнати или неразпространявани, така че изданията с корекции за сигурност са налични чрез пакетите snap.
Няма публични данни уязвимостта да е била използвана при реални атаки. Записът за CVE включва оценка на Агенцията за киберсигурност и сигурност на инфраструктурата на САЩ (CISA) от 30 октомври, според която не е известно уязвимостта да е била експлоатирана; тя не фигурира в списъка на CISA с известни експлоатирани уязвимости и не е публикуван работещ експлойт.
Какво трябва да се направи
Обновете LXD и MicroCloud до коригираните версии. При инсталация чрез snap изпълнете sudo snap refresh lxd и sudo snap refresh microcloud.
От Canonical посочиха, че по време на публикуването на бюлетина коригираните версии на LXD все още са били в процес на разпространение от канала с кандидати към стабилния канал, затова проверете коя версия реално имате след обновяването, вместо да приемате, че корекцията за сигурност вече е инсталирана.
Бюлетинът на Canonical не предлага временно заобиколно решение за LXD. Тъй като атаката изисква мрежов достъп до API интерфейса, ограничаването на това кой може да достигне до него намалява риска, докато инсталирате обновяването. Проектът Incus, докладвайки за същата уязвимост, заяви, че няма конфигурационна корекция и че единствената стъпка е да се ограничи мрежовият достъп до порта за слушане.
Потребителите на Incus трябва да преминат към версия 7.6.0, която отстранява тази уязвимост заедно със 17 други проблема със сигурността.