Cloudflare Containers'daki Kiracılar Arası Veri Sızıntısı Açığı Kapatıldı

Güvenlik açığının bildirilmesi ve kapsamı

4 Eylül 2026'da Accomplish'ten güvenlik araştırmacısı Oren Yomtov, Cloudflare Containers ve Containers üzerine inşa edilen Cloudflare Sandboxes'ı etkileyen bir güvenlik açığını sorumlu bir şekilde bildirdi. Bildirim, Cloudflare'in hata ödül programı aracılığıyla yapıldı. Bu yazı, Oren Yomtov ve Accomplish güvenlik araştırma ekibiyle işbirliği içinde hazırlandı; ekibin ayrıntılı raporu ve kontrollü testleri sorunun doğrulanmasına ve hızlı yanıt verilmesine yardımcı oldu.

Cloudflare Containers, iş yüklerini çok kiracılı altyapıda çalıştırır ve bunları otomatik olarak uygun sunuculara atar. Müşteriler temel ana bilgisayarı seçemez. Araştırmacılar, Workers Paid hesabına sahip bir müşterinin aynı ana bilgisayardaki Containers tarafından daha önce kullanılan artık disk bloklarını kurtarabileceğini gösterdi.

Konteyner depolama tahsisinin işleyişi

Cloudflare Containers, her konteynere yazılabilir bir kök disk sağlamak için Linux device mapper thin provisioning (dm-thin) kullanır. Her konteyner, Firecracker sanal makine monitörü tarafından desteklenen özel bir sanal makine içinde çalışır ve Firecracker bu diski sanal makineye /dev/vdc olarak sunar.

Thin provisioning, fiziksel depolamayı yalnızca bir sanal disk daha önce eşlenmemiş bir bölgeye yazdığında tahsis eder. Etkilenen depolama havuzları 64 KiB thin-block boyutu kullandı. Bir konteynerin kök diskini destekleyen thin birim silindiğinde, fiziksel blokları birden fazla müşteri hesabına ait iş yüklerine hizmet eden bir havuza geri döndürüldü.

Etkilenen havuz yapılandırması skip_block_zeroing seçeneğini içeriyordu. Bu seçenek yapılandırıldığında dm-thin, yeni tahsis edilen blokları erişilebilir kılmadan önce sıfırlamayı atlar. Daha önce kullanılmış 64 KiB'lik bir blok yeniden atandığında, tam blok yazma önceki içeriğini değiştirir, ancak daha küçük bir yazma yalnızca yazılan kısmı değiştirir. Kalan kısım, bloğun önceki sahibinden veri tutabilir.

Sömürü tekniğinin işleyişi

Yeni bir thin diskte eşlenmemiş bir bölgeyi okumak artık veri ortaya çıkarmadı; dm-thin fiziksel bir blok tahsis etmeden sıfır döndürdü. Kavram kanıtı, konuk ext4 dosya sistemindeki boş alana karşılık gelen 64 KiB hizalı bölgeleri belirledi ve her bölgeye hizalı bir 4 KiB blok yazdı.

Böyle bir yazma eşlenmemiş bir thin bloğa ulaştığında, dm-thin paylaşılan havuzdan fiziksel bir 64 KiB blok tahsis etti. 4 KiB yazma bloğun yalnızca o kısmını değiştirdi ve blok sıfırlama devre dışı olduğu için kalan 60 KiB önceki bir konteynerden veri tutabilir. Sonraki bir ham cihaz okuması, yeni konteynerin hiç yazmadığı baytları gözlemleyebilir.

Kavram kanıtı şu adımları izledi: Workers Paid hesabı kullanarak bir konteyner oluşturdu; yazılabilir kök diski /dev/vdc'de açtı; diski okudu ve bir başlangıç değeri kaydetti; ext4 boş alanına karşılık gelen her seçili 64 KiB bölgesine bir 4 KiB blok yazdı; ortaya çıkan blokları tekrar okudu ve yalnızca yeni konteyner tarafından üzerine yazılmayan kısımları inceledi.

Gönderim; sayılar, blok uzaklıkları, boyutlar, sağlama toplamı sonuçları ve kesilmiş hash öneklerini içeriyordu. Araştırmacılar ham blokları kurtarmış olsa da Cloudflare'e sağlanan materyaller hiçbir üçüncü taraf dosya adı, tanımlayıcı, kimlik bilgisi, ana bilgisayar adı, adres veya kurtarılan içerik değeri içermiyordu. Araştırmacılar, kurtarılan verileri güvenli bir şekilde sildiklerini doğruladı.

Güvenlik açığının doğrulanması

Araştırmacılar, kendi test dosya sistemlerine ait blokları diğer dosya sistemlerinden gelen bloklardan ayırt etmek için ext4 dizin blok sağlama toplamlarını kullandı. ext4 metadata_csum özelliğini kullandığında, dizin blok sağlama toplamları dosya sistemi ve inode ile ilişkili değerleri içerir.

Altı üretim yerleşiminde, araştırmacılar tüm 5.614 test edilebilir dizin bloğunu bildirdi. Bu blokların sıfırı araştırmacıların dosya sistemine atfedildi. Sağlama toplamı analizi yoluyla 2.700 farklı yabancı dizin inode'u tanımlandı.

Yöntemi doğrulamak için araştırmacılar, kavram kanıtı için kullanılan kontrollü test dosya sisteminde kasıtlı olarak oluşturup sildikleri bloklara karşı test etti. Yöntem, 162 bloğun tamamını o dosya sistemine doğru şekilde atfetti.

Araştırmacılar sonuçta 24 yerleşimden 18'inde ve dört kıtada 22 ana düğümden 20'sinde artık materyal gözlemledi. Kurtarılan blok türleri dizin yapıları, veritabanı sayfaları ve yapısal olarak tam SQLite veritabanlarını içeriyordu. Araştırmacılar, yalnızca toplu sayılar ve biçim kontrolleri çıkaran, kurtarılan dosya içeriklerini değil, komut dosyaları kullandıklarını bildirdi. Cloudflare'e gönderilen materyaller hiçbir kurtarılan içerik değeri veya üçüncü taraf tanımlayıcısı içermiyordu. Araştırmacılar daha sonra kontrolleri altındaki kurtarılan verilerin gizli kaldığını ve gönderim sonrasında güvenli bir şekilde silindiğini doğruladı.

Etki ve azaltma önlemleri

Güvenlik açığı, Workers Paid hesabına sahip bir müşterinin aynı temel ana bilgisayardaki diğer müşterilerin Containers'ı tarafından daha önce kullanılan depolama bloklarından artık veri kurtarmasına potansiyel olarak olanak tanıyabilirdi. Başarılı bir sömürü, kiracı izolasyon sınırını aşabilir ve dosya sistemi meta verilerini, dizin yapılarını, veritabanı sayfalarını ve uygulama verilerini açığa çıkarabilirdi.

Ancak bir saldırgan belirli bir kurbanı seçemedi veya aktif olarak bağlı bir diske erişemedi. Maruz kalma, Cloudflare'in iş yükü yerleşimine ve dm-thin'in hangi önceden serbest bırakılmış blokları yeniden atadığına bağlıydı. Araştırmacılar başka bir müşterinin aktif verilerinin değiştirildiğini veya iş yükü kullanılabilirliğinin etkilendiğini göstermedi.

Cloudflare, Containers filosu genelinde bir düzeltme uyguladı ve müşteri tarafında yapılandırma değişikliği gerekmedi. İlk azaltma önlemi, filo genelinde dm-thin havuz yapılandırmasından skip_block_zeroing'i kaldırmaktı. Bu, dm-thin'in yeni tahsis edilen blokları bir konteynere açığa çıkarmadan önce temizleme varsayılan davranışını geri getirdi. Bu değişiklik, küçük bir yazmanın tahsisi tetiklediği ve daha büyük bir okumanın bloğun geri kalanından artık veri kurtardığı bildirilen tekniği durdurdu. Araştırmacılar, bu değişiklikten sonra kavram kanıtlarının artık çalışmadığını bağımsız olarak doğruladı.

Yeni tahsisleri sıfırlamak, zaten mevcut thin cihazlara eşlenmiş blokları temizlemedi. Bu eşlemeler çalışan konteyner disklerinde ve her ana bilgisayarın OCI imaj katmanları için hazırlanmış dm-thin anlık görüntü önbelleğinde mevcuttu. Yeni bir konteyner, bu blokları yeniden tahsis etmeden önbelleğe alınmış bir katmandan eşlemeleri devralabilir. Bu nedenle Cloudflare ayrıca tüm çalışan konteyner disklerini devre dışı bıraktı ve azaltma öncesi oluşturulan önbelleğe alınmış imaj anlık görüntülerini kaldırdı. Ana bilgisayarları yoğun olmayan saatlerde boşalttılar, her ana bilgisayardaki VM'leri yeniden başlattılar ve her ana bilgisayarın imaj önbelleğini temizlediler, böylece diskler ve önbelleğe alınmış katmanlar sıfırlanmış tahsisler kullanılarak yeniden oluşturuldu. Cloudflare, bu temizliği Containers filosu genelinde tamamladı.

Sömürü kanıtı araştırması

Cloudflare, bildirilen sömürü tekniğiyle tutarlı aktivite gösterip göstermediğini araştırmak için konteyner altyapısından saklanan tarihsel disk G/Ç telemetrisini inceledi. Bu özellikleri kullanarak tespit imzaları geliştirdi ve bunları mevcut tarihsel telemetriye uyguladı.

Bildirilen tekniğe atfedilebilen aktivite, yetkili doğrulama yapan araştırmacılardan ve Cloudflare mühendislerinden geldi. Cloudflare, bu belirli saldırı vektörünün başka biri tarafından sömürüldüğüne dair hiçbir kanıt görmedi.

Cloudflare, güvenlik açığını tamamen giderdiğini ve müşteri verilerinin ihlal edildiğine dair hiçbir kanıt bulunmadığını belirtti.

Olay zaman çizelgesi

• 4 Eylül 15:26 UTC: Accomplish'ten Oren Yomtov sorunu HackerOne aracılığıyla bildirdi.
• 4 Eylül 18:45 UTC: Cloudflare bir güvenlik olayı başlattı ve kusura neden olan üretim kurulumunu doğruladı.
• 4 Eylül 21:27 UTC: Cloudflare çalışma zamanı düzeltmesini ve yeniden kullanım testini birleştirdi.
• 4 Eylül 22:03 UTC: Cloudflare yeni ve canlı havuzlar için değişiklikleri birleştirdi.
• 4 Eylül 23:15 UTC: Cloudflare değişiklikleri kullanıma sunmaya başladı.
• 7 Eylül 06:13 UTC: Cloudflare değişikliklerin kullanıma sunulmasını tamamladı ve eski havuz verilerini temizlemeye başladı.
• 14 Eylül 10:50 UTC: Araştırmacılar kavram kanıtlarının çalışmayı durdurduğunu bildirdi.
• 14 Eylül 12:52 UTC: Cloudflare araştırmacıya bir ödül verdi.
• 19 Eylül 15:03 UTC: Cloudflare etkilenen filo genelindeki tüm azaltma öncesi önbelleğe alınmış anlık görüntülerin temizliğini tamamladı.