
Cloudflare Containers açığı kapandı; müşterinin yapacağı bir ayar yok

Cloudflare, 24 Eylül 2026 tarihli olay açıklamasında Containers ve onun üzerine kurulu Sandboxes hizmetlerindeki kiracılar arası artık disk verisi açığını tamamen giderdiğini bildirdi. Müşterilerin düzeltme için yapılandırma değiştirmesi gerekmiyor. Açık, aynı fiziksel ana makinede daha önce başka bir müşterinin kullandığı disk bloklarında kalan verilerin okunmasına imkân verebiliyordu; çalışan bir iş yükünün diskine doğrudan erişim gösterilmedi.
Bu ayrım, alınacak önlemi belirliyor. Containers veya Sandboxes kullanmayan bir kuruluşun bu olay nedeniyle ayar değiştirmesi için gerekçe yok. Bu hizmetlerde iş yükü çalıştıranların ise teknik düzeltmeyi kendilerinin uygulaması gerekmiyor; geçmişte yazılabilir diskte hassas sır tutup tutmadıklarına göre ihtiyati bir yenileme kararı vermeleri mümkün. Yayımlanan incelemede kötü niyetli kullanıma ilişkin kanıt bulunmadığı belirtiliyor, ancak bu sonuç geçmişte hiçbir verinin okunmadığının mutlak kanıtı değil.
Eski disk verisi yeni bir kiracıya nasıl geçebiliyordu?
Containers, iş yüklerini birden fazla müşterinin paylaştığı fiziksel altyapıya yerleştiriyor. Her konteynerin yazılabilir kök diski için fiziksel alan gerektiğinde ayrılıyor; bir konteyner silindiğinde kullandığı bloklar ortak depolama havuzuna geri dönüyor. Soruna yol açan ayarda, yeniden tahsis edilen bloklar yeni konteynere verilmeden önce temizlenmiyordu. Yeni yazma bloğun yalnızca bir kısmını kapladığında, kalan bölümde önceki iş yükünün baytları durabiliyordu.
Yeni diskteki boş alanı doğrudan okumak bu baytları göstermiyordu: Henüz fiziksel blok atanmamış bölge sıfır dönüyordu. Araştırmacıların gösterdiği yöntem, boş bir bölgeye küçük bir yazma yaparak havuzdan blok ayrılmasını sağlıyor, ardından diskin ham düzeyinde yazılmamış kısmı okuyordu. Dolayısıyla açık, sıradan bir dosya okuma izninden değil, daha önce kullanılmış fiziksel alanın yeniden verilme biçiminden kaynaklanıyordu.
Yöntemle belirli bir müşteriyi, dosyayı veya ana makineyi seçmek mümkün değildi. Sonuç, iş yükünün nereye yerleştirildiğine ve o makinede hangi eski blokların yeniden tahsis edildiğine bağlıydı; her denemede artık veri bulunacağı da garanti değildi. Bu sınır, bulunan verinin önemsiz olduğu anlamına gelmiyor. Eski bir blok dosya sistemi bilgisi, veri tabanı sayfası veya uygulamanın diske yazdığı içerik taşıyabilirdi.
Hangi hizmetler ve veri türleri söz konusu?
Doğrulanan temel kapsam Cloudflare Containers ve onun üzerinde çalışan Cloudflare Sandboxes. Accomplish araştırma notu, aynı disk uygulamasını kullanan Browser Run'ın da etkilendiğini belirtiyor; bu ek kapsam araştırmacıların açıklamasına dayanıyor. Araştırmacılar karşılaştıkları içerik türleri arasında dizin listelerini, SQLite veri tabanlarını, Chromium profillerini, .env dosyalarını ve kimlik bilgisi dosyalarını sayıyor.
Bir Cloudflare hesabına sahip olmak, bu depolama havuzunda iş yükü çalıştırmış olmakla aynı şey değil. Yalnızca başka Cloudflare hizmetlerini kullanan bir kuruluş, kendi verilerinin söz konusu bloklarda bulunduğu sonucunu bu olaydan çıkaramaz. Containers, Sandboxes veya araştırmacıların işaret ettiği Browser Run kullanımı varsa, anlamlı soru uygulamanın yazılabilir diske hangi verileri bıraktığıdır.
Özellikle geçici dosyalar, yerel veri tabanları, uygulama günlükleri ve dosyaya kaydedilmiş kimlik bilgileri bu değerlendirmede önem taşır. Bir sırrın uygulamaya verilmiş olması tek başına diske yazıldığını göstermez; tersine, uygulama veya kullandığı araçlar bir sırrı dosyaya kaydetmişse yalnızca bellekte kaldığı varsayılamaz. Açığın konusu disk blokları olduğundan, bu iki durum aynı maruziyet değerlendirmesine girmez.
Düzeltme neden iki aşamada tamamlandı?
İlk düzeltme, yeniden ayrılan blokların konteynere gösterilmeden önce temizlenmesini sağladı. Böylece küçük bir yazmadan sonra bloğun geri kalanında eski içeriği okuma yöntemi kapandı. Fakat bu değişiklik, çalışan konteyner disklerinde veya önceden hazırlanmış görüntü katmanlarının önbelleğinde zaten eşlenmiş blokları geriye dönük olarak temizlemiyordu. Yeni başlayan bir konteyner, önbellekteki katmandan böyle bir eşlemeyi devralabilirdi.
The Hacker News'in 25 Eylül 2026 tarihli haberi, sağlayıcının çalışan diskleri yenileyip önbellekteki eski görüntü katmanlarını temizleme işlemini 19 Eylül'de tamamladığını aktarıyor. Bu ikinci aşama, yalnızca gelecekteki blok tahsislerini güvenli hâle getirmekle yetinmeyip eski eşlemelerin de kullanım dışına çıkarılmasını sağladı. Başlıktaki “kapandı” ifadesi, bu hizmet genelindeki işlemlerin tamamlanmasına dayanıyor.
Müşteri tarafında bir ayarın bulunmamasının nedeni de düzeltmenin uygulama kodunda veya müşteri hesabında değil, sağlayıcının disk tahsis katmanında yapılmış olması. Bir konteyneri yeniden başlatmak ya da yapılandırmasına yeni bir seçenek eklemek, geçmişte başka bir kiracıya tahsis edilmiş olabilecek bloklar hakkında ek bilgi sağlamaz. Teknik açığın kapatılması ile geçmişte diske yazılmış hassas verilerin riskini değerlendirmek bu yüzden ayrı konulardır.
Sır yenileme kararı neye dayanmalı?
Genel bir anahtar yenileme zorunluluğu açıklanmadı. İhtiyati yenileme, açığın devam ettiği varsayımıyla değil, geçmişte diskte bulunmuş olabilecek bir sırrın önemine göre değerlendirilebilir. Bunun için önce etkilenen hizmetlerde iş yükü çalışıp çalışmadığı, ardından uygulamanın hangi sırları yazılabilir diske kaydettiği ayrılmalı. Bu, sağlayıcının düzeltmesine ek bir yapılandırma adımı değil, kuruluşun kendi verisine ilişkin risk kararıdır.
- Etkilenen hizmetlerde iş yükü yoksa, bu olay tek başına bütün erişim anahtarlarını yenilemek için somut bir neden oluşturmaz.
- İş yükü varsa fakat ilgili sırrın yalnızca bellekte tutulduğu biliniyorsa, artık disk verisi açığı o sır için doğrudan bir disk maruziyeti göstermiyor.
- Yetkisi geniş bir anahtarın veya parolanın dosyaya yazıldığı biliniyor ya da makul biçimde olası görünüyorsa, onu yenilemek ihtiyati bir tercih olabilir. Böyle bir karar, o sırrın ele geçirildiğine dair kanıt bulunduğu anlamına gelmez.
Uygulama kayıtları ve dağıtım düzeni, hangi dosyaların oluşturulduğunu anlamaya yardımcı olabilir. Ancak müşterinin kendi kayıtları, fiziksel ana makinedeki eski blokların daha sonra kime verildiğini kesin biçimde göstermez. Yerel kayıtlarda şüpheli erişim görülmemesi de tek başına artık veri olasılığını dışlamaz. Değerlendirmede belirleyici olan, kullanılan hizmet, diskte bulunmuş olabilecek veri ve o verinin açığa çıkmasının etkisidir.
İncelemenin açık bıraktığı sınır
Kötüye kullanım bulunmadığı sonucu, elde tutulan geçmiş disk giriş çıkış kayıtlarında bildirilen yönteme uyan etkinlik aramasına dayanıyor. İncelemede araştırmacıların ve yetkili doğrulama yapan mühendislerin etkinliği ayırt edilmiş; başka bir kullanım saptanmamış. Kayıtların kapsamadığı dönemler için aynı kesinlik ileri sürülemez. Açığın ne kadar süre mevcut olduğu veya hangi müşterilere ait hangi blokların yeniden tahsis edildiği yayımlanan bilgilerden çıkarılamıyor.
Mevcut durum net: Containers ve Sandboxes için sağlayıcı tarafındaki düzeltme tamamlandı, müşterinin uygulayacağı bir ayar yok. Browser Run kapsamı araştırmacıların açıklamasında yer alıyor. Etkilenen hizmetlerde diske hassas veri yazmış kuruluşlar açısından açık kalan karar, kanıtlanmış bir ihlale tepki vermek değil, olası geçmiş maruziyete karşı belirli sırları ihtiyaten yenileyip yenilememek.
Ayrıca okuyun:
İlgili makaleler


Claude Fable 5.1 güçlü ama üç API davranışını kırıyor

OpenAI Agents API açık beta: Uzun görevlerin altyapısını servis yönetiyor

AI ajanında model testi yetmez: Üç çalışma anı kapısı gerekiyor

Cloudflare 100 TB RAM kazandı: Donanım değil, veri düzeni değişti

Gitea açığı aktif saldırıda: Açık kayıt, kimlik doğrulamayı anlamsızlaştırıyor
Bültenimize abone olun
En son Web3, yapay zekâ ve kripto haberleri doğrudan gelen kutunuza gelsin.