Incus va Canonical LXD'da sertifikat tekshiruvidagi jiddiy zaifliklar aniqlangan bo'lib, ular autentifikatsiyasiz hujumchilarga ishonchli shaxslar sifatida o'zini ko'rsatish va boshqaruv infratuzilmasini buzish imkonini beradi.
Ushbu zaifliklardan foydalanish HTTPS tinglovchisiga tarmoq orqali kirishni talab qiladi, lekin haqiqiy ma'lumotlar yoki ishonchli sertifikatning shaxsiy kaliti talab qilinmaydi. Ushbu LXD zaifligi butun klasterlar va ular boshqaradigan virtual mashinalarni ochib qo'yishi mumkin.
GHSA-xg75-xf37-cph9 sifatida kuzatiladigan Incus muammosi maksimal CVSS balli 10.0 ga ega. U 7.6.0 versiyasidan oldingi barcha nashrlarga ta'sir qiladi va saqlovchilar bu asosiy xatti-harakat dastlabki nashrdan beri mavjudligini ta'kidlagan.
Maslahatda hech qanday tayinlangan CVE identifikatori ro'yxatga olinmagan va zaiflik noto'g'ri autentifikatsiya hamda noto'g'ri sertifikat tekshiruvi sifatida tasniflangan.
Sertifikat zanjiri tekshiruvi muvaffaqiyatsizligi
Ubuntu ma'lumotlariga ko'ra, zaiflik HTTPS tinglovchisi mijoz sertifikatlarini qanday ishlashida yuzaga keladi. U TLS muzokarasi davomida sertifikatlarni so'raydi, lekin taqdim etilgan zanjirni tekshirmaydi.
Qo'l siqish faqat birinchi sertifikatga mos keladigan shaxsiy kalitga egalikni tasdiqlaydi, ulanishni amalga oshirayotgan mijoz esa keyingi sertifikatlarni nazorat qiladi.
Shunga qaramay, autentifikatsiya tekshiruvlari ushbu zanjirdagi har bir sertifikatni ishonch do'koniga solishtirgan. Hujumchi hujumchi nazoratidagi zanjirga ishonchli shaxsning ochiq sertifikatini qo'shib, uning shaxsiy kalitisiz autentifikatsiyadan o'tishi mumkin edi.
Oldin e'lon qilingan Teleport autentifikatsiya chetlab o'tishi ham shaxsni tekshirish muvaffaqiyatsizligining oqibatlarini ko'rsatadi, garchi uning mexanizmi farq qilsa ham.
Server sertifikatlari ekspluatatsiyani ayniqsa osonlashtiradi, chunki TLS qo'l siqishlari ularni ochiq ravishda oshkor qiladi. Maqsadli server sertifikatini qo'shish ma'lumotlar bazasi shlyuzi kirishini ta'minlaydi, boshqa klaster a'zosining sertifikatini taqdim etish esa ichki klaster kirishini ta'minlaydi va avtorizatsiyani butunlay chetlab o'tadi. Ishonchli mijoz va metrika sertifikatlari ham ularning ochiq sertifikatlari mavjud bo'lganda taqlid qilish maqsadiga aylanadi.
Zaiflik faqat dastlabki autentifikatsiya bilan cheklanmaydi. Hujumchilar ishonch do'koni yozuvlarini yangilash yoki o'chirish uchun o'z-o'ziga xizmat yo'llaridan foydalanishi mumkin va xostdan VM agent autentifikatsiyasi ham ta'sirlanadi. Tekshirilmagan sertifikatlar avtorizatsiya skriptlariga ham yetib boradi, bu esa hujumchi tanlagan sertifikat ma'lumotlari hatto token yoki OpenID Connect mijozlari uchun ham qaror qabul qilishga ta'sir qilishiga imkon beradi.
Ushbu avtorizatsiya ochilishi alohida HashiCorp Consul avtorizatsiya chetlab o'tishi bilan bog'liq xavotirlarni eslatadi. Biroq, Incus maslahati mijoz nazoratidagi sertifikat zanjirlarini ishonchli shaxslar sifatida taqlid qilish va sertifikatga asoslangan avtorizatsiya qarorlariga ta'sir qilish yo'li sifatida aniq ko'rsatadi.
Canonical LXD muammosini CVE-2026-112816 sifatida kuzatadi, u 2026-yil 30-oktabrda e'lon qilingan. Uning xabarnomasida 4.0.14, 5.0.10, 5.21.8 va 6.9 versiyalari ta'sirlanganligi, mos ravishda 4.0.15, 5.0.11, 5.21.9 va 6.10.1 versiyalarida tuzatilganligi ko'rsatilgan. U hujumchilar tomonidan tayyorlangan sertifikat zanjirlari orqali klasterlar va boshqariladigan virtual mashinalarga autentifikatsiyasiz kirish mumkinligini tasvirlaydi.
Alohida Red Hat Kubernetes klaster-proksi zaifligi ham klaster boshqaruvi ochilishini ta'kidlaydi, garchi u sertifikat zanjiri taqlid qilish emas, balki server tomonidagi so'rov soxtalashtirish bilan bog'liq bo'lsa ham.
Ma'murlar Incusni 7.6.0 yoki undan yuqori versiyaga yangilashlari va tegishli tuzatilgan LXD nashrini o'rnatishlari kerak. Yangilanishlar o'rnatilmaguncha, HTTPS boshqaruv kirishini faqat ishonchli xostlar bilan cheklang. Incus saqlovchilari zaiflikni tuzatadigan hech qanday konfiguratsiya asosidagi yechim yo'qligini, tarmoq cheklovlari ochilishni kamaytirishi, lekin asosiy sertifikat tekshiruvi muvaffaqiyatsizligini tuzatmasligini ta'kidlaydi.
SOC'ingizga hodisalarni tez to'xtatish uchun ogohlantirish kontekstini bering. 16K SOC'dan tahdid razvedkasini integratsiya qiling.
Critical certificate-validation vulnerabilities have been identified in Incus and Canonical LXD, allowing unauthenticated attackers to impersonate trusted identities and compromise management infrastructure.
Exploitation of these vulnerabilities requires network access to the HTTPS listener but does not require valid credentials or the private key for a trusted certificate. This LXD vulnerability may expose entire clusters and their managed virtual machines.
The Incus issue, tracked as GHSA-xg75-xf37-cph9, has a maximum CVSS score of 10.0. It affects all releases prior to version 7.6.0, and maintainers have indicated that this underlying behavior has existed since the initial release.
The advisory does not listany assigned CVE identifier and classifies the weakness under improper authentication and improper certificate validation.
Certificate Chain Validation Failure
According to Ubuntu, the vulnerability originates in how the HTTPS listener handles client certificates. Although it requests certificates during TLS negotiation, it does not verify the supplied chain.
The handshake establishes possession of the private key corresponding only to the first certificate, while the connecting client controls the subsequent certificates.
Authentication checks nevertheless compared every certificate in that chain against the trust store. An attacker could append a trusted identity’s public certificate to an attacker-controlled chain and authenticate without its private key.
The previously disclosed Teleport authentication bypass likewise illustrates the consequences of failed identity verification, although its mechanism differs.
Server certificates make exploitation particularly accessible because TLS handshakes disclose them publicly. Appending the target server’s certificate grants database gateway access, while presenting another cluster member’s certificate enables internal cluster access and bypasses authorization entirely. Trusted client and metrics certificates also become impersonation targets when their public certificates are available.
The weakness extends beyond initial authentication. Attackers can abuse self-service paths to renew or delete trust-store entries, and host-to-VM agent authentication is affected. Unverified certificates also reach authorization scriptlets, allowing attacker-selected certificate data to influence decisions even for token or OpenID Connect clients.
This authorization exposure echoes concerns raised by the separate HashiCorp Consul authorization bypass. However, the Incus advisory specifically identifies client-controlled certificate chains as the route to impersonate trusted identities and influence certificate-based authorization decisions.
Canonical tracks the LXD issue as CVE-2026-112816, published October 30, 2026. Its notice identifies affected versions 4.0.14, 5.0.10, 5.21.8, and 6.9, with fixes in 4.0.15, 5.0.11, 5.21.9, and 6.10.1, respectively. It describes unauthenticated access to clusters and managed virtual machines through crafted certificate chains.
The separate Red Hat Kubernetes cluster-proxy vulnerability also highlights cluster-management exposure, although it involves server-side request forgery rather than certificate-chain impersonation.
Administrators should upgrade Incus to 7.6.0 or later and deploy the appropriate patched LXD release. Until updates are installed, restrict HTTPS management access to trusted hosts. Incus maintainers state that no configuration-based workaround fixes the vulnerability, network restrictions reduce exposure but do not correct the underlying certificate-validation failure.
Give your SOC the alert context to stops incidents quickly.Integrate Threat Intel from 16K SOCs.