Bir bulut hizmetinde uygulamanız başka müşterilerin kodlarıyla aynı fiziksel işlemciyi paylaşıyorsa, aradaki mantıksal duvar gerçekten yeterli midir? Cloudflare’ın 19 Ağustos 2026’da yayımladığı Workers araştırması, bu soruya rahatlatıcı fakat dikkat gerektiren bir yanıt veriyor: Araştırmacılar kendi yönettikleri saldırgan ve kurban Worker’lar arasında uzaktan Spectre saldırısını üretim koşullarında gösterebildi; kullanılan yol ise açıklamadan önce kapatıldı. Bu yazı, “bulut çöktü” paniği üretmeden sonucun geliştirici ve hizmet alan işletme için ne ifade ettiğini anlatıyor.

Araştırmada gerçekten ne gösterildi?

Spectre, işlemcinin hız kazanmak için yaptığı spekülatif yürütmenin yan etkilerini ölçerek normalde erişilememesi gereken belleğe ilişkin ipuçları toplamaya dayanan bir saldırı ailesi. Cloudflare Workers, farklı müşterilerin JavaScript kodlarını V8 “isolate” adı verilen hafif yalıtım alanlarında çalıştırıyor. Bu model, her küçük iş için ayrı sanal makine açmaktan çok daha hızlı ve verimli; fakat aynı süreçte çok sayıda kiracı çalıştığı için mikro mimari yan kanallar ayrıca ele alınmalı.

Cloudflare ekibi, 2024 ve 2025’in başında yaptığı kontrollü çalışmada saldırgan, kurban ve zamanlama bileşenlerinin tümünü kendisi yönetti. Durable Objects ve WebSocket trafiğiyle uzun ömürlü bir ölçüm kanalı kuruldu; kurban Worker’a bilerek yerleştirilen bir JWT, bit bit okunabildi. Bildirilen en yüksek hız saniyede 12 bit, doğruluk ise yüzde 99’un üzerindeydi. Bu sonuç gerçek müşteri anahtarlarının çalındığı anlamına gelmiyor: deney, saldırının uygulanabilirliğini ölçmek için oluşturulmuş kontrollü bir senaryoydu.

Neden uzaktan yapılabilmesi önemli?

Klasik yan kanal deneylerinde saldırganın yüksek çözünürlüklü bir zamanlayıcıya ve hedefle aynı makinede çalışmaya ihtiyacı vardır. Workers ortamı yerel zamanı CPU çalışırken donduruyor, ortak bellek ve çoklu iş parçacığı gibi kolaylaştırıcıları sunmuyor. Araştırmanın değeri, bu engellere rağmen uzaktaki WebSocket iletişiminin bir zamanlama sinyaline dönüştürülebilmesi. Üretim gürültüsü, kesmeler ve yük değişimleri saldırıyı zorlaştırsa da tamamen olanaksız kılmamış.

Buradan çıkarılacak daha geniş ders şu: “Aynı süreçte ayrı heap” güçlü bir güvenlik katmanı olsa da tek başına donanımsal sınır değildir. Konteyner, sanal makine veya isolate kullanılması riskin sıfırlandığını değil, farklı katmanlarda azaltıldığını gösterir. Bu nedenle bulut güvenliği yalnızca uygulama koduna değil; çalışma zamanı, işletim sistemi, işlemci ve davranış izleme katmanlarının birlikte tasarlanmasına dayanır.

Cloudflare neyi değiştirdi?

Şirket, araştırmada kullanılan yolu üretimde giderdiğini ve önceki üç yıl için aktif istismar göstergesi bulamadığını belirtiyor. Savunma tarafında üç alan öne çıkıyor. Birincisi, ham 64 bit işaretçilerin JavaScript heap’inde kullanılabilirliğini azaltan V8 Sandbox entegrasyonu. İkincisi, Eylül 2025’te devreye alınan Memory Protection Keys tabanlı süreç içi yalıtım. Üçüncüsü ise şüpheli Worker’ları ayrı sürece taşıyan Dynamic Process Isolation sisteminin uzun süre çalışan ve yoğun I/O kullanan iş yüklerini daha iyi değerlendirecek biçimde geliştirilmesi.

Bu katmanların hiçbiri “Spectre artık bitti” demiyor. Cloudflare da V8 Sandbox ile MPK’nın tek başına eksiksiz çözüm olmadığını açıkça yazıyor. Güçlü taraf, savunmanın tek bir mekanizmaya bağlanmaması: bir teknik başarısız olduğunda diğer katmanların sızıntı yüzeyini küçültmesi hedefleniyor.

Hizmet sağlayıcı seçerken bu açıklık da ölçülebilir bir güvenlik sinyalidir. Araştırmanın hangi tarihlerde yapıldığı, testin kime ait sistemlerde yürütüldüğü, müşteriden işlem beklenip beklenmediği ve düzeltmenin ne zaman devreye alındığı açıkça yazılmalı. “Kritik açık bulundu” başlığı tek başına karar verdirmez; istismar koşulu, etki alanı ve giderim durumu birlikte okunmalıdır. Aksi hâlde kontrollü bir güvenlik araştırması, gerçek müşteri ihlali gibi yanlış aktarılabilir.

Workers kullanan geliştirici ne yapmalı?

  • Sırları gereksiz yere bellekte tutmayın: API anahtarı veya oturum belirteci yalnızca ihtiyaç duyulan süre boyunca kullanılmalı.
  • Yetkileri daraltın: Bir Worker’ın ele geçirilmesi halinde erişebileceği kaynak ve işlemler en az yetki ilkesiyle sınırlandırılmalı.
  • Kısa ömürlü kimlik bilgileri kullanın: Döndürülebilir ve kapsamı dar belirteçler, olası sızıntının etkisini azaltır.
  • Logları anlamlı kurun: Olağan dışı WebSocket süresi, tekrar eden zamanlama davranışı ve beklenmeyen kaynak erişimleri izlenmeli.
  • Sağlayıcı açıklamalarını takip edin: Güvenlik modeli ve olay sonrası raporlar, yalnız fiyat ve performans kadar önemli bir seçim ölçütüdür.

Son kullanıcı açısından yapılacak iş, rastgele port taramak veya paniğe kapılmak değil. Bu araştırma için Cloudflare müşterilerine özel bir yama talimatı yayımlanmadı. Kendi cihazınızın daha doğrudan risklerini azaltmak için Mac’te Screen Sharing ve 5900 portu kontrol rehberine; bağlantı gizliliğiyle uygulama güvenliğini karıştırmamak için de VPN’in neyi yapıp neyi yapmadığına bakabilirsiniz.

Sonuç: sorun paylaşımlı bulut değil, tek katmana güvenmek

Cloudflare çalışması, çok kiracılı bulutun güvensiz olduğunu kanıtlamıyor; verimlilik sağlayan yalıtım modelinin sürekli sınanması gerektiğini gösteriyor. En olumlu veri, kontrollü araştırmanın üründe değişikliğe dönüşmesi ve aktif istismar belirtisi bulunmaması. En önemli uyarı ise daha genel: “sandbox var” cümlesi güvenlik incelemesinin sonu değil, başlangıcıdır.

Kaynaklar