Canonical'ning LXD va MicroCloud'dagi jiddiy zaiflik hujumchiga ishonchli mijozning shaxsiy kalitiga ega bo'lmasdan o'sha mijoz sifatida tizimga kirish imkonini beradi. Buning uchun hujumchi ularning HTTPS API'siga tarmoq orqali kirishi va ishonchli mijozning ochiq sertifikatiga ega bo'lishi kerak edi.
Tizimga kirgach, hujumchi o'sha mijoz sifatida harakat qiladi va klaster hamda uning virtual mashinalariga kirish huquqiga ega bo'ladi. Agar taqlid qilingan hisob imtiyozli bo'lsa, hujumchi "xost mashinasiga root kirish huquqiga" ega bo'lishi mumkin, deb aytdi Canonical.
CVE-2026-112816 sifatida kuzatilgan bu zaiflik maksimal CVSS bahosi 10.0 ga ega va Canonical har ikkala mahsulotning tuzatilgan versiyalarini chiqardi.
Zaiflik qanday ishlaydi
LXD va MicroCloud masofaviy mijozlarga o'zaro TLS (mutual TLS) orqali API'lariga kirish imkonini beradi — bu tizimda mijoz o'z shaxsini isbotlash uchun sertifikat taqdim etadi. Mijozning sertifikati serverning ishonch do'konida (trust store) bo'lsa, u ishonchli hisoblanadi.
Zaiflik serverning sertifikatni tekshirish usulida edi. Server mijoz yuborgan har bir sertifikatni ishonch do'koni bilan solishtirar edi, lekin TLS ulanishi faqat zanjirdagi birinchi sertifikat — barg (leaf) — uchun shaxsiy kalitga egalikni isbotlaydi. Qolgan zanjir esa mijoz tanlagan narsadir.
Shunday qilib, hujumchi ishonchli mijozning ochiq sertifikatini (bu maxfiy emas) o'z zanjirining orqasiga biriktirib yuborishi mumkin edi va server uni o'sha mijoz sifatida qabul qilar edi.
Kimlar ta'sirlanadi
Zaiflikdan foydalanish uchun ikkita narsa kerak: HTTPS API'ga tarmoq orqali kirish va server allaqachon ishonadigan mijozning ochiq sertifikati.
Alohida LXD serveri bu API'ni odatda ochmaydi. U faqat mahalliy soketda tinglaydi, agar administrator core.https_address sozlamasi bilan tarmoq API'sini yoqmasa.
Bir nechta LXD ishlaydigan mashinalarni bir klasterga birlashtiradigan MicroCloud'da esa aniq zaif nuqta bor. Canonical aytishicha, hujumchi klasterga qo'shilish jarayonida a'zoning ochiq sertifikatini ushlab qolsa, keyin o'sha a'zo sifatida tizimga kirishi mumkin.
CVE yozuvi LXD 4.0.14, 5.0.10, 5.21.8 va 6.9 versiyalarini ta'sirlangan deb ko'rsatadi — har biri tuzatilgan relizdan oldingi. Canonical quyidagi tuzatilgan snap versiyalarini ro'yxatga olgan:
| Mahsulot | Snap kanali | Tuzatilgan versiya |
|---|---|---|
| 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 |
Bu xato Canonical'dan boshlanmagan. LXD'dan jamoaviy fork sifatida boshlangan Incus loyihasi uni xabar qilgan va Canonical LXD ham ta'sirlanganini tasdiqlagan. Incus xuddi shu zaiflikni 7.6.0 versiyasida tuzatgan.
Ubuntu'ning o'z arxiv paketlari LXD uchun ta'sirlanmagan yoki yetkazilmagan deb ro'yxatga olingan, shuning uchun tuzatilgan relizlar snap'lardir.
Zaiflik hujumda ishlatilganiga oid ochiq belgi yo'q. CVE yozuvi AQSh CISA bahosini o'z ichiga oladi, 30-oktabr sanasi bilan, zaiflik ekspluatatsiya qilingani ma'lum emas; u CISA'ning Ma'lum Ekspluatatsiya Qilingan Zaifliklar ro'yxatida emas va ishlaydigan eksploit e'lon qilinmagan.
Nima qilish kerak
LXD va MicroCloud'ni tuzatilgan versiyalarga yangilang. Snap o'rnatishda sudo snap refresh lxd va sudo snap refresh microcloud buyrug'ini bajaring.
Canonical aytishicha, tuzatilgan LXD nuqta relizlari maslahat berish vaqti nomzod (candidate) kanalidan barqaror (stable) kanalga hali tarqatilayotgan edi, shuning uchun yangilashdan keyin haqiqatan ham tuzatilgan versiya o'rnatilganini tekshiring, faqat yangilangan deb o'ylamang.
Canonical'ning maslahatida LXD uchun vaqtinchalik yechim (workaround) berilmagan. Hujum tarmoq orqali API'ga kirishni talab qilgani uchun, yangilashgacha kim kirishi mumkinligini cheklash xavfni kamaytiradi. Xuddi shu zaiflikni xabar qilgan Incus loyihasi konfiguratsiya orqali tuzatish mumkin emasligini va yagona qadam tinglovchiga tarmoq kirishini cheklash ekanligini aytgan.
Incus foydalanuvchilari 7.6.0 versiyasiga o'tishlari kerak — bu zaiflik bilan birga yana 17 ta xavfsizlik muammosini ham tuzatgan.
A critical flaw in Canonical's LXD and MicroCloud let an attacker log in as a trusted client without holding that client's private key. To do it, the attacker had to reach their HTTPS API over the network and have the trusted client's public certificate.
Once in, the attacker would act as that client, with access to the cluster and its virtual machines. If the impersonated account is privileged, the attacker could gain "root access to the host machine," Canonical said.
The flaw, tracked as CVE-2026-112816, carries a maximum CVSS score of 10.0, and Canonical has released fixed versions of both products.
How the Flaw Works
LXD and MicroCloud let remote clients access their APIs over mutual TLS, a setup in which the client presents a certificate to prove who it is. A client is trusted when its certificate is in the server's trust store, the list of identities the server will accept.
The flaw was in how the server checked that certificate. It compared every certificate the client sent against the trust store, but a TLS connection only proves the client owns the private key for the first certificate in the chain, the leaf. The rest of the chain is whatever the client chose to attach.
So an attacker could take a trusted client's public certificate, which is not secret, attach it to the chain behind their own, and the server would accept them as that client.
Who Is Affected
Using the flaw takes two things: network access to the HTTPS API, and the public certificate of a client the server already trusts.
A standalone LXD server does not expose that API by default. It listens only on a local socket unless an administrator turns on the network API with the core.https_address setting.
MicroCloud, which ties several machines running LXD into one cluster, has a specific weak point. Canonical said an attacker who can capture a member's public certificate as it joins the cluster can then log in as that member.
The CVE record lists LXD 4.0.14, 5.0.10, 5.21.8 and 6.9 as affected, each before the fixed release that follows. Canonical lists these fixed snap versions:
| Product | Snap channel | Fixed version |
|---|---|---|
| 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 |
The bug did not start at Canonical. The Incus project, which began as a community fork of LXD, reported it, and Canonical confirmed it affected LXD as well. Incus fixed the same flaw in version 7.6.0.
Ubuntu's own archive packages of LXD are listed as not affected or not shipped, so the fixed releases are the snaps.
There is no public sign the flaw has been used in an attack. The CVE record carries a U.S. CISA assessment, dated October 30, that the flaw is not known to have been exploited; it is not on CISA's Known Exploited Vulnerabilities list, and no working exploit has been published.
What to Do
Update LXD and MicroCloud to the fixed versions. On a snap install, run sudo snap refresh lxd and sudo snap refresh microcloud.
Canonical said the fixed LXD point releases were still rolling out from the candidate channel to stable at the time of its advisory, so check the version you actually have after the refresh rather than assume the fix arrived.
Canonical's advisory gives no temporary workaround for LXD. Because the attack requires network access to the API, limiting who can reach it reduces risk until you update. The Incus project, reporting the same flaw, said there is no configuration fix and that the only step is to restrict network access to the listener.
Incus users should move to 7.6.0, which fixed this flaw along with 17 other security issues.
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.