Cloudflare'ın GLM-5.3 modeli, KV cache üzerinden 155 Workers AI yanıtında müşteri verisi sızdırdı

Cloudflare, Workers AI modellerinden birinde, modelin context window'u ile KV cache havuzu arasındaki boyut uyumsuzluğunun ve açık kaynak SGLang inference motorundaki bir hatanın birleşiminden kaynaklanan kiracılar arası bir veri ifşasını açıkladı. Cloudflare blog'unda yayımlanan bir yazıya göre, 27 Ağustos - 9 Eylül 2026 tarihleri arasında GLM-5.3 modeli tarafından verilen 155 yanıt, başka müşterilerin isteklerine ait veriler içeriyordu.

Sorun, 8 Eylül 2026'da Knostic'ten Gadi Evron tarafından Cloudflare'in HackerOne programı aracılığıyla bildirildi: modele gönderilen çok uzun prompt'lar bazen diğer kullanıcıların oturumlarına ait metinler döndürüyordu. Cloudflare sorunu ertesi sabah yeniden üreterek, olay ilan edildikten sonraki 40 dakika içinde modeli çevrimdışı aldı ve aynı gün içinde düzeltilmiş bir yapılandırma ve yamalanmış bir motorla geri yükledi. Şirket başka hiçbir Workers AI modelinin etkilenmediğini doğruladı ve kendi test trafiği ile araştırmacının trafiğini hariç tuttukten sonra, etkilenen isteklerin hatanın bilinçli istismarından ziyade sıradan uzun-context kullanımı gibi göründüğünü belirtti.

İç içe geçmiş iki hata

İlk sorun bir yanlış yapılandırmaydı. Cloudflare, GLM-5.3'ü — agentic kodlama iş akışlarına yönelik bir Z.ai metin üretim modeli — 1.048.576 token'lık bir context window ile dağıttı, ancak prefill GPU'larındaki KV cache havuzu yalnızca 681.280 token için yer sağlıyordu. Cloudflare bu uyumsuzluğu lansmandan önce biliyordu, ancak motorun karşılayamadığı herhangi bir prompt için hata döndürmesini bekliyordu ve uzun-context kıyaslamaları başarılı yanıtlar döndürmüştü.

İkincisi, SGLang'in ayrık (disaggregated) prefill/decode modunda aşırı uzun istekleri ele alma biçimindeki bir hataydı. Havuza sığmayan bir prompt reddedildi olarak işaretleniyor ve tek token'lık bir yer tutucuyla değiştiriliyordu; ancak prefill, işlemi iptal edip istemciye hata döndürmek yerine o yer tutucunun KV cache'ini hesaplayıp decode düğümüne gönderiyordu. Decode düğümü bir tamamlama sinyali aldı ve tam prompt'un cache'inin orada daha önce ne varsa üzerine yazdığını varsaydı; oysa önceki durumun büyük kısmı yerinde kalmıştı ve model, yanıtı önceki isteklerden veri taşıyan eski cache sayfalarına dikkat ederek üretti.

Hata neden mümkündü

Workers AI, GLM-5.3'ü SGLang ile ayrık bir yapılandırmada çalıştırıyor: prefill GPU'ları prompt'u işleyip KV cache'ini üretiyor, ardından bunu Mooncake üzerinden RDMA ile decode GPU'larına aktarıyor. KV cache, istek kabul edildiğinde atanıp tamamlandığında serbest bırakılan, sabit boyutlu GPU bellek sayfalarından oluşan paylaşımlı bir havuzdur. Sayfalar istekler arasında sıfırlanmaz — bir sonraki istek sadece üzerine yazar — bu yaklaşımı Cloudflare yaygın ve performans için gerekli olarak tanımlıyor, ancak bu durum sayfa sahipliğini düğümler arasında izleme sorumluluğunu motora yüklüyor. Özellikle, havuz boyutu doğrudan bir ayar değil: SGLang bunu başlangıçta model ağırlıkları yüklendikten sonra kalan GPU belleğinden türetiyor ve yapılandırılan context uzunluğuyla eşleşmesini zorlayan hiçbir şey yok. Cloudflare buradaki test boşluğuna işaret ediyor — uzun context'lerde HTTP durum kodlarını ve veri hacmini doğruladı, ancak model çıktısının tutarlılığını doğrulamadı. Artık herhangi bir ayrık dağıtım değişikliği gönderilmeden önce, KV havuz boyutu context uzunluğuyla doğrudan çalışan motor üzerinde kontrol ediliyor.

Giderim ve upstream düzeltmeler

Cloudflare iki düzeltme uyguladı. İlk olarak, GLM-5.3 yapılandırmasını GLM-5.2 kurulumuna uyacak şekilde ayarladı ve prefill KV havuzunun artık yaklaşık 2,04 milyon token — context uzunluğunun kabaca iki katı — tutacak kadar GPU belleği serbest bıraktı; böylece geçerli bir prompt her zaman sığıyor ve rejection path hiç çalıştırılmıyor. İkinci olarak, motoru bekleyen bir reddi taşıyan isteğin, herhangi bir tahsis veya KV aktarımı gerçekleşmeden önce, özgün hatasıyla birlikte ayrıştırma kabul kuyruğunda emekliye ayrılması için yamaladı; decode düğümü ayrıca aktarılan token sayısının rezerve ettiği sayıyla eşleştiğini doğruluyor.

Cloudflare bu değişiklikleri upstream'de SGLang pull request #38704 olarak önerdi. İlgili bir hata yolu için 6 Eylül'de birleştirilmiş ancak henüz yayınlanmamış #36988 ile bir düzeltme zaten SGLang'in main dalına girmişti; ayrıca bakımcılar bu tür istekleri daha reddeden #38935'i de birleştirdi. Hata SGLang v0.5.21'de giderildi. Cloudflare, modeli geri yüklemeden önce düzeltmelerini araştırmacının yeniden üretim betiği ve kendi canary-marker testleriyle doğruladı ve raporu SGLang'in eşgüdümlü açıklamasıyla birlikte yayımladı.

Neden önemli

Bu olay, paylaşımlı LLM serving'e özgü bir hata modunu gözler önüne seriyor: sıfırlanmamış KV cache sayfalarını yeniden kullanmak gibi standart bir performans optimizasyonu, bir yapılandırma uyumsuzluğu ile bir rejection-path hatasını kiracılar arası bir gizlilik ihlaline dönüştürdü. Çok kiracılı inference platformları işletmelerin modellere erişimin varsayılan yolu haline geldikçe, çıkarılacak dersler somut. Havuz boyutu ile context uzunluğu gibi içsel kapasite değişmezleri, HTTP yanıt kodlarından çıkarımla değil, çalışan motor üzerinde runtime doğrulaması gerektiriyor. Testler yalnızca veri hacmini değil, sınır koşullarında çıktı doğruluğunu da kontrol etmeli. Ve SGLang yaygın olarak kullanıldığı için, upstream düzeltmeleri Cloudflare'in kendi altyapısının çok ötesinde önem taşıyor.