Canonical, LXD ve MicroCloud’da saldırganın özel anahtara sahip olmadan güvenilir bir istemci gibi görünmesine izin veren kritik açığı kapattı. CVE-2026-112816 olarak izlenen kusur 10.0 CVSS puanı aldı; Canonical her iki ürün için de düzeltilmiş sürümler yayımladığını açıkladı.
Açık, LXD ve MicroCloud’un uzak istemcilere mutual TLS üzerinden API erişimi vermesini sağlayan yapıda ortaya çıktı. Bu kurulumda istemci, kimliğini kanıtlamak için bir sertifika sunuyor ve sunucu, kabul edeceği kimlikleri trust store içinde tutuyor. Bir istemci, sertifikası sunucunun trust store’unda yer alıyorsa güvenilir sayılıyor.
Canonical’a göre sorun, sunucunun sertifikayı kontrol etme biçimindeydi. Sunucu, istemcinin gönderdiği zincirdeki her sertifikayı trust store ile karşılaştırıyordu. Ancak bir TLS bağlantısı yalnızca zincirin ilk sertifikası olan leaf için istemcinin özel anahtara sahip olduğunu doğruluyor; zincirdeki diğer sertifikalar istemcinin eklediği içerikten ibaret kalıyor.
Bu nedenle saldırgan, güvenilen bir istemcinin genel sertifikasını alıp kendi sertifika zincirine ekleyebiliyordu. Sunucu bu zinciri kabul ettiğinde saldırgan o istemci gibi davranabiliyordu. İçeri girdikten sonra küme ve sanal makineler üzerinde o hesaba tanınan erişimi elde ediyordu. İmha edilen hesap ayrıcalıklıysa Canonical, saldırganın ana makine üzerinde root erişimi kazanabileceğini belirtti.
Açık ağ erişimi ve güvenilen sertifika istiyor
Açığın kullanılabilmesi için iki koşul gerekiyor: HTTPS API’ye ağ erişimi ve sunucunun zaten güvendiği bir istemciye ait genel sertifika. LXD’nin tek başına çalışan kurulumunda bu API varsayılan olarak dışarı açılmıyor; sistem yalnızca yönetici core.https_address ayarını etkinleştirirse ağ üzerinden dinliyor.
MicroCloud tarafında risk, birden fazla LXD makinesini tek bir kümede birleştiren yapıda öne çıkıyor. Canonical, bir küme üyesinin genel sertifikasının, o üye kümeye katılırken ele geçirilmesi halinde saldırganın daha sonra bu üye gibi giriş yapabileceğini söyledi. Böylece saldırgan, elinde özel anahtar olmadan doğrulama sürecini aşabiliyor.
Hata Canonical içinde ortaya çıkmadı. LXD’nin topluluk çatallanması olarak başlayan Incus projesi sorunu ilk bildiren taraf oldu. Canonical, aynı kusurun LXD’yi de etkilediğini doğruladı; Incus cephesinde ise düzeltme 7.6.0 sürümünde yayımlandı.
Hangi sürümler etkilendi, hangi yamalar yayımlandı
CVE kaydı, LXD 4.0.14, 5.0.10, 5.21.8 ve 6.9 sürümlerini etkilenmiş olarak listeliyor. Canonical’ın yayımladığı düzeltilmiş snap sürümleri LXD için 6/stable kanalında 6.10.1, 5.21/stable kanalında 5.21.9, 5.0/stable kanalında 5.0.11 ve 4.0/stable kanalında 4.0.15 olarak yer aldı. MicroCloud için 3/stable kanalında 3.4.1, 2/stable kanalında 2.1.5 yayımlandı.
Canonical, advisory yayımlandığında LXD nokta sürümlerinin candidate kanalından stable kanala geçiş sürecinde olduğunu da not düştü. Bu nedenle güncelleme sonrası kurulu sürümün gerçekten düzeldiğinin kontrol edilmesi gerektiğini vurguladı. Ubuntu’nun kendi arşiv paketlerinde LXD için “etkilenmiyor” ya da “dağıtılmıyor” ibaresi bulunduğu için düzeltmeler snap sürümleri üzerinden takip ediliyor.
Açığın kamuya açık şekilde saldırıda kullanıldığına dair bir işaret yok. CVE kaydında, 30 Ekim tarihli ABD CISA değerlendirmesinde kusurun istismar edildiğine dair bulgu bulunmadığı yazıyor. Açık, CISA’nın Known Exploited Vulnerabilities listesinde yer almıyor ve şu ana kadar çalışan bir exploit yayımlanmadı.
Canonical geçici çözüm yayımlamadı
Canonical, LXD için geçici bir çözüm sunmadı. Şirket, snap kurulumlarında sudo snap refresh lxd ve sudo snap refresh microcloud komutlarıyla güncelleme yapılmasını önerdi. Incus kullananlar için hedef sürüm 7.6.0 olarak verildi; bu sürüm aynı açığı ve 17 başka güvenlik sorununu kapatıyor.
Hem Canonical hem de Incus, saldırının API’ye ağ üzerinden erişim gerektirdiğini belirtti. Bu yüzden dinleyiciye kimlerin ulaşabildiğini sınırlandırmak, yama uygulanana kadar riski azaltan tek pratik adım olarak kaldı. Incus cephesinde de yapılandırma düzeltmesi olmadığı, yalnızca ağ erişiminin kısıtlanabildiği ifade edildi.
Açığın kökeninde, güvenilen sertifika zincirinin yanlış yorumlanması yer alıyor. Sistem, istemcinin elindeki herkese açık sertifikayı doğrulama akışında özel anahtar kanıtı gibi ele alıyordu. NVD kaydı da CVE-2026-112816 için şu adresi gösteriyor: https://nvd.nist.gov/vuln/detail/CVE-2026-112816