Cloudflare'e göre açık, Workers Paid planına sahip herhangi bir hesap tarafından kullanılabilecek durumdaydı. Şirket, açığın araştırmacılar dışında kimse tarafından istismar edildiğine dair bir kanıt bulmadığını ve müşterilerin herhangi bir işlem yapmasının gerekmediğini belirtti.
Sorunun kaynağı: sıfırlanmayan disk blokları
Cloudflare'in blog yazısına göre sorun, konteyner disklerinin altında kullanılan Linux device mapper thin provisioning (dm-thin) katmanının yapılandırmasından kaynaklanıyordu. Depolama havuzları 64 KiB'lık bloklarla çalışıyor ve skip_block_zeroing seçeneği açık bulunuyordu. Bu seçenek açıkken dm-thin, yeni ayrılan blokları kullanıma vermeden önce sıfırlamayı atlar.
Bir konteyner silindiğinde fiziksel bloklar birden fazla müşterinin paylaştığı havuza geri dönüyor, ancak güvenli biçimde silinmiyordu. Araştırmacının yöntemi şöyle işliyordu: ext4 dosya sisteminin boş alanına denk gelen 64 KiB hizalı bölgelere küçük, 4 KiB'lık yazmalar yapılıyordu. Böyle bir yazma henüz eşlenmemiş bir blok alanına ulaştığında dm-thin, paylaşılan havuzdan 64 KiB'lık fiziksel bir blok ayırıyordu. Yazılan 4 KiB dışında kalan 60 KiB, o bloğu daha önce kullanan başka bir müşterinin eski verisini taşımaya devam ediyor ve ham aygıt erişimiyle okunabiliyordu.
Açık kapaklı bir Seagate Barracuda Green sabit diskinin plakası ve okuma kafası. Fotoğraf: Raimond Spekking, Wikimedia Commons, CC BY-SA 4.0. Olayın kendisine ait bir kare değildir.
Kalıntı verilerde neler vardı?
BleepingComputer'ın aktardığına göre araştırmacı, incelenen 24 konteyner yerleşiminin 18'inde ve test edilen 22 düğümün 20'sinde başka müşterilere ait kalıntı veri tespit etti. Bulunan veri türleri arasında şunlar yer alıyordu:
- Dizin listeleri ve dosya sistemi meta verileri
- SQLite veritabanları ve veritabanı sayfaları
- Chromium tarayıcı profilleri
- .env dosyaları
- Kimlik bilgisi dosyaları
Cloudflare'in açıklamasına göre araştırmacılar kontrollü testler sırasında 2.700 farklı yabancı dizin düğümü (inode) kurtardı; HackerOne politikası gereği kurtarılan tüm verilerin güvenli biçimde silindiği doğrulandı. BleepingComputer'a göre araştırmacı, müşteri verisini dışarı çıkarmadan yalnızca toplam sayı döndüren kontrol betikleri kullandı.
.env ve kimlik bilgisi dosyalarının listede yer alması, açığın ciddiyetini artırıyor: bu dosyalar genellikle API anahtarları, veritabanı parolaları ve üçüncü taraf servis tokenları gibi sırlar içerir.
Zaman çizelgesi
Cloudflare'in blogunda paylaştığı zaman çizelgesi:
| Tarih (UTC) | Gelişme |
|---|---|
| 4 Eylül 2026, 15.26 | Açık HackerOne üzerinden bildirildi |
| 4 Eylül 2026, 18.45 | Cloudflare olayı doğruladı |
| 7 Eylül 2026, 06.13 | Düzeltmenin dağıtımı tamamlandı, temizlik başladı |
| 14 Eylül 2026, 12.52 | Hata ödülü verildi |
| 19 Eylül 2026, 15.03 | Düzeltme öncesine ait tüm önbellek görüntüleri temizlendi |
| 24 Eylül 2026 | Cloudflare ve Accomplish olayı kamuoyuna açıkladı |
Ödül miktarı açıklanmadı; olay için bir CVE numarası da duyurulmadı.
Cloudflare ne yaptı?
Şirketin açıkladığı önlemler:
- dm-thin havuz yapılandırmasından skip_block_zeroing seçeneği tüm filoda kaldırıldı.
- Düzeltmeden önce oluşturulmuş tüm çalışan konteyner diskleri kullanımdan çıkarıldı.
- Düzeltme öncesinde oluşturulmuş önbelleğe alınmış OCI imaj görüntüleri silindi.
- Sunucular yoğunluğun düşük olduğu saatlerde boşaltılarak diskler sıfırlanmış bloklarla yeniden oluşturuldu.
Cloudflare, konteyner altyapısına ait geçmiş disk G/Ç telemetrisini incelediğini ve yalnızca araştırmacılar ile doğrulama testi yapan yetkili mühendislerin etkinliğini gördüğünü belirtti. Şirket, bu saldırı yolunun başka biri tarafından kullanıldığına dair kanıt bulmadığını vurguladı.
Yapay zekâ sandbox'ları hedefte
Accomplish, bunun ekibinin Temmuz 2026'dan bu yana belgelediği altıncı sandbox kaçışı olduğunu belirtiyor; önceki bulgular arasında Claude Cowork, Cursor CLI, Docker'ın hipervizörü ve OpenAI Codex'teki izolasyon sorunları yer alıyor. Yomtov'a göre son bulgu, izolasyonun pek çok farklı biçimde başarısız olabileceğine dair daha geniş bir örüntüye işaret ediyor. Accomplish'in yazısına göre açık, Cloudflare Sandboxes'ın yanı sıra Browser Run hizmetini de etkiliyordu.
Cloudflare Sandboxes, yapay zekâ ajanlarının ürettiği kodu çalıştırmak gibi güvenilmeyen iş yükleri için tasarlanmış bir hizmet. Bu tür platformlarda bir müşterinin, diğer müşterilerin konteynerleriyle aynı fiziksel diski paylaşması, depolama katmanındaki küçük bir performans ayarının bile kiracılar arası izolasyonu delebileceğini gösteriyor.
Müşteriler için öneriler
Cloudflare müşterilerin bir işlem yapmasının gerekmediğini açıklasa da, paylaşılan altyapıda çalışan iş yükleri için şu önlemler genel iyi uygulama olarak öne çıkıyor:
- Kalıcı sırları konteyner diskinde .env dosyalarında tutmak yerine platformun gizli değişken (secret) yönetimini kullanın.
- Konteyner imajlarına ve disklerine uzun ömürlü kimlik bilgisi yazmaktan kaçının; kısa ömürlü tokenları tercih edin.
- Hassas iş yüklerinde uygulama düzeyinde şifreleme uygulayın.
- Sağlayıcıların güvenlik bültenlerini ve olay açıklamalarını takip edin.
Kapak fotoğrafı: Cloudflare'in San Francisco'daki 101 Townsend Street ofisinin girişindeki lav lambası duvarı. Fotoğraf: HaeB, Wikimedia Commons, CC BY-SA 4.0. Olayın kendisine ait bir kare değildir.
Kaynaklar
- Cloudflare Blog: https://blog.cloudflare.com/containers-cross-tenant-vulnerability/
- Accomplish: https://accomplish.ai/blog/escaping-the-cloudflare-sandbox/
- BleepingComputer: https://www.bleepingcomputer.com/news/security/cloudflare-fixes-containers-cross-tenant-flaw-exposing-customer-data/
TR Siber Ekibi