Veri merkezinde numaralı etiketli kablolarla bağlı sunucu rafı (temsili görsel)

Canonical, LXD ve MicroCloud ürünlerinde CVSS (açıkların 0–10 arası önem puanı) ölçeğinde 10 puan alan CVE-2026-112816 açığını giderdi. Açık, HTTPS API'ye ağdan erişebilen bir saldırganın, herkese açık sertifikasına sahip olduğu herhangi bir güvenilir istemci gibi kimlik doğrulamasına izin veriyordu. Düzeltilmiş sürümler yayımlandı ve Canonical tüm kullanıcılara hemen güncelleme çağrısı yaptı.

Açık nasıl çalışıyor

LXD (Canonical'ın sanal makine ve konteyner yönetim aracı) üzerinde karşılıklı TLS (mTLS: sunucunun yanında istemcinin de sertifikayla kimliğini kanıtladığı bağlantı) ile uzaktan API kimlik doğrulaması yapılırken sunucu, istemcinin ilettiği tüm sertifikaları güven deposu (trust store: sunucunun kabul ettiği istemci sertifikalarının listesi) kayıtlarıyla eşleştiriyordu. Ancak zincirde yalnızca ilk sıradaki yaprak sertifika, istemcinin ilgili imza anahtarına sahip olduğunu kanıtlar.

Saldırganlar, güvenilir bir istemciye ait ve gizli olmayan herkese açık sertifikayı kendi zincirine ara sertifika biçiminde ekleyerek o istemcinin kimliğiyle oturum açabiliyordu. Canonical'a göre saldırgan bu yöntemle LXD veya MicroCloud servisinin güvenini kazanabiliyor ve taklit edilen kullanıcının yetkisine bağlı olarak ana makinede kök (root) erişimi elde edebiliyor. CVE kaydına göre saldırgan kümeye ve yönetilen sanal makinelere tam erişim sağlayabiliyor.

Kimler etkileniyor

MicroCloud (birden fazla LXD sunucusunu tek küme olarak yöneten Canonical ürünü) tarafında saldırgan, kümeye yeni katılan bir üyenin herkese açık sertifikasını işlem anında ele geçirirse ilerleyen süreçte o üye gibi kimlik doğrulayabiliyor. The Hacker News'in aktardığına göre bağımsız çalışan bir LXD sunucusu ağ API'sini varsayılan ayarlarda açmıyor ve yönetici core.https_address yapılandırmasını devreye almadıkça yalnızca yerel soketi dinliyor. Yine The Hacker News'e göre Ubuntu'nun kendi arşivindeki LXD paketleri etkilenmiyor ya da dağıtılmıyor; düzeltmeler snap (Ubuntu'nun paket biçimi) sürümleri üzerinden sunuluyor. Açığı Canonical'a bildiren Incus projesi de aynı sorunu 7.6.0 sürümünde kapattı.

Saldırılarda kullanıldı mı

CISA tarafından 30 Ekim 2026 tarihinde yapılan değerlendirmeye göre açığın saldırılarda kullanıldığına dair bir bulgu bulunmuyor. Zafiyet CISA'nın Bilinen İstismar Edilen Açıklar (KEV) listesinde yer almıyor. The Hacker News'e göre çalışan bir istismar kodu da yayımlanmadı.

Ne yapmalısınız

Canonical'ın 28 Ekim 2026 tarihli danışmanlığı, LXD ya da MicroCloud kullanan tüm kurum ve sistem yöneticilerinin kendi kanallarındaki en son sürüme geçmesini istiyor. Incus projesi de yapılandırmayla bir çözüm olmadığını, güncellemeye kadar tek adımın dinleyiciye ağ erişimini kısıtlamak olduğunu bildirdi.

Açıktan etkilenen kurum veya toplam kurulum sayısı açıklanmadı. Türkiye genelinde etkilenen bir kuruluşun bulunup bulunmadığına ilişkin resmi bir veri açıklanmadı.

Kaynaklar

Kapak görseli (temsili): «Wikimedia Foundation Servers 2015-88» — VGrigas (WMF), CC BY-SA 3.0, Wikimedia Commons (16:9 kırpıldı, 1200×675 küçültüldü).

Sık sorulan sorular

Hangi LXD sürümleri etkileniyor?

LXD 4.0.14, 5.0.10, 5.21.8 ve 6.9 sürümleri etkilenmektedir. Sorun 4.0.15, 5.0.11, 5.21.9 ve 6.10.1 sürümlerinde giderilmiştir.

Açık saldırılarda kullanıldı mı?

CISA'nın 30 Ekim 2026 değerlendirmesine göre açığın istismar edildiği bilinmemektedir ve zafiyet CISA KEV listesinde değildir.

Güncelleme yapamıyorsam ne yapmalıyım?

Incus projesine göre yapılandırmayla bir çözüm yok; güncelleme tamamlanana kadar sunucunun HTTPS API dinleyicisine ağ erişimini sınırlandırmak riski azaltır.