SİSTEM YÖNETİMİ 25 Eylül 2026 · 4 dakikalık okuma

Sömürü kodu yayında, yama hâlâ yok

Konteynerden çıkıp sunucunun tamamını ele geçirmeye izin veren açık için çalışan kod yayımlandı

Ne oldu?

Linux çekirdeğinde CVE-2026-80521 numaralı bir güvenlik açığı bulundu. Açık, çekirdeğin AF_UNIX soket bileşenindeki bir bellek yönetimi hatasından kaynaklanıyor ve önem derecesi 10 üzerinden 7,8 olarak değerlendirildi.

Açığın yaptığı şey şu: bir konteynerin içinde kod çalıştırabilen biri, konteynerden çıkıp sunucunun tamamında root yetkisi elde edebiliyor.

Etkilenen sürümler arasında Ubuntu 22.04, 24.04 ve 26.04 LTS ile bu sürümlerin AWS, Azure ve Google Cloud için hazırlanmış çekirdek paketleri de var.

Açığı DepthFirst adlı güvenlik firması bir yapay zekâ modeli ve insan testiyle buldu; aynı açık bağımsız olarak bir başka araştırmacı tarafından da keşfedildi.

Konteyner kaçışı ne demek?

Konteyner teknolojisinin temel vaadi izolasyondur: aynı sunucu üzerinde birden fazla uygulama çalışır, her biri kendi kutusunda durur ve diğerlerini göremez. Bulut altyapılarının büyük bölümü bu ilke üzerine kuruludur.

Konteyner kaçışı, bu duvarın aşılması demek. Saldırgan kendi kutusundan çıkıp sunucuya, dolayısıyla o sunucudaki diğer tüm konteynerlere ulaşır.

Bu açığın kullanılabilmesi için saldırganın önce bir konteynerin içinde kod çalıştırabiliyor olması gerekiyor. Yani dışarıdan doğrudan sömürülen bir açık değil; ilk erişim sağlandıktan sonra kullanılan bir yetki yükseltme adımı. Ama etkisi buna rağmen büyük, çünkü kullanılan bileşen Docker ve Kubernetes'in varsayılan güvenlik profillerinde zaten açık.

Bu olayı farklı kılan ne?

Sıradan bir açık duyurusu değil. Takvim şöyle işledi:

  • 5 Ağustos — açık üreticiye bildirildi
  • 6 Ağustos — Linux çekirdeğinin ana sürümünde düzeltme yayımlandı
  • Eylül — DepthFirst, Ubuntu 26.04'ü hedefleyen çalışan sömürü kodunu kamuya açtı
  • 23 Eylül itibarıyla — Ubuntu'nun takip sisteminde durum hâlâ "üzerinde çalışılıyor"; yayımlanmış bir yama yok

Yani saldırganın elinde çalışan araç var, savunmanın elinde hazır yama yok. Bu iki durumun aynı anda bulunması nadirdir ve aciliyeti belirleyen şey tam olarak budur.

Bugüne kadar bu açığın gerçek bir saldırıda kullanıldığına dair bir bulgu paylaşılmadı. Ancak sömürü kodunun kamuya açık olması, bunun yalnızca zaman meselesi olabileceği anlamına geliyor.

Sizi neden ilgilendiriyor?

Kurumunuzda konteyner kullanılıyorsa bu doğrudan sizin meseleniz. Kullanılmıyorsa bile, hizmet aldığınız sağlayıcıların altyapısı büyük olasılıkla konteyner üzerinde çalışıyor.

Üç durum:

  • Kendi konteyner altyapınızı işletiyorsanız: çekirdek yaması sizin sorumluluğunuzda. Yama çıkana kadar hangi iş yüklerinin nerede çalıştığına bakmanız gerekiyor.
  • Bulut sağlayıcıdan konteyner hizmeti alıyorsanız: çekirdeği kimin ne zaman yamaladığı sağlayıcının işi. Sormanız gereken soru bu.
  • Yazılım geliştiriyorsanız: derleme ve test ortamlarınız da konteyner üzerinde çalışıyor olabilir. Bu ortamlar genellikle üretim kadar sıkı izlenmez ve dışarıdan gelen kod çalıştırırlar.

Üçüncüsü en çok gözden kaçanı. Bir derleme ortamı, tanımı gereği güvenilmeyen kod çalıştıran bir yerdir.

Bugün ne yapmalısınız?

  1. Ubuntu'nun yama durumunu kontrol edin. Yayımlandığında beklemeden uygulayın; bu açık için "sonraki bakım penceresine kalsın" kararı riskli.
  2. Aynı sunucuda çalışan iş yüklerini gözden geçirin. Güvenilmeyen veya dışarıdan gelen kod çalıştıran konteynerleri, kritik iş yükleriyle aynı makinede tutmayın.
  3. Yüksek riskli iş yüklerini daha güçlü izolasyona taşımayı değerlendirin. Konteyner yerine mikro sanal makine yaklaşımı (Firecracker, Kata Containers gibi) bu tür kaçışlara karşı ek bir duvar koyar.
  4. Bulut sağlayıcınıza sorun: "CVE-2026-80521 için çekirdek yamanız uygulandı mı, uygulanmadıysa ne zaman uygulanacak?"
  5. Derleme ve test ortamlarınızı da bu listeye dahil edin. Üretim dışı diye atlanan ortamlar, dışarıdan kod çalıştırdıkları için çoğu zaman en açık noktadır.

Asıl mesele

Bu olayda dikkat çeken üç şey var.

Birincisi, açığı bir yapay zekâ modelinin bulmuş olması. Güvenlik araştırması tarafında bu artık istisna değil; açık bulma hızı artıyor, dolayısıyla yama uygulama hızının da artması gerekiyor.

İkincisi, düzeltmenin çekirdek tarafında bir gün içinde çıkmış olmasına rağmen dağıtıma haftalarca yansımaması. Açık yönetiminde asıl gecikme çoğu zaman düzeltmenin yazılmasında değil, size ulaşmasında yaşanıyor.

Üçüncüsü ve en önemlisi: konteyner izolasyonu bir güvenlik duvarı değil, bir düzen aracıdır. Aynı makinede güvendiğiniz ve güvenmediğiniz iş yüklerini birlikte çalıştırıyorsanız, aradaki tek engel çekirdeğin hatasız olmasıdır. Bu varsayım her yıl birkaç kez bozuluyor.

Bunun karşılığı konteynerden vazgeçmek değil; hangi iş yükünün hangi komşuyla aynı makinede durduğuna bilinçli karar vermek.

Konteyner izolasyonunuzu birlikte gözden geçirelim.

Hangi iş yüklerinin aynı makinede durduğunu, yama takibinin nasıl yürüdüğünü ve derleme ortamlarınızın kapsamını değerlendirelim.

Teklif Alın