Cloudflare mengungkap kebocoran isolasi antar-pelanggan pada model GLM-5.3 di Workers AI. Bug ini memungkinkan sebagian respons memuat data dari sesi pengguna lain ketika prompt melewati batas tertentu. Perusahaan mengatakan masalah sudah diperbaiki, model dipulihkan pada 9 September, dan tidak ada model Workers AI lain yang terdampak.

Dalam laporan yang diterbitkan pada 26 Oktober, Cloudflare mengatakan paparan berlangsung sejak GLM-5.3 diluncurkan pada 27 Agustus hingga model dinonaktifkan sementara pada 9 September. Sebanyak 155 respons teridentifikasi terdampak. Semuanya berasal dari prompt dengan panjang lebih dari 681.280 token—jauh di atas ukuran prompt yang lazim dipakai kebanyakan pengguna.

Cloudflare tidak menemukan bukti bahwa celah itu sengaja dieksploitasi. Setelah mengeluarkan pengujian internal dan aktivitas peneliti keamanan, pola permintaan yang tersisa dinilai konsisten dengan penggunaan long-context biasa. Temuan awal datang dari peneliti keamanan Gadi Evron melalui program HackerOne pada 8 September. Cloudflare mereproduksinya keesokan hari dan menonaktifkan model sekitar 40 menit setelah insiden dinyatakan.

Dua masalah yang bertemu

Akar persoalannya bukan hanya satu bug. Cloudflare menjalankan GLM-5.3 dengan konteks maksimum 1.048.576 token, tetapi kumpulan memori KV cache pada GPU prefill hanya sanggup menampung 681.280 token. KV cache menyimpan representasi token yang sudah diproses agar model tidak perlu menghitung ulang seluruh prompt ketika menghasilkan jawaban.

Cloudflare sebenarnya mengetahui ketidakcocokan ukuran itu sebelum peluncuran. Pengujian panjang hanya memeriksa status HTTP dan aliran respons, lalu menganggap mesin inferensi akan menolak permintaan yang tidak muat. Pengujian tersebut tidak memeriksa apakah isi respons tetap koheren dan tidak berasal dari sesi lain. Di sinilah asumsi yang tampak kecil berubah menjadi masalah isolasi data.

Masalah kedua berada di SGLang, mesin inferensi open source yang dipakai Cloudflare. Dalam mode prefill/decode terdisagregasi, permintaan yang terlalu panjang ditandai untuk ditolak dan diganti placeholder satu token agar dapat keluar dari alur pemrosesan. Namun antrean pada node prefill dan decode hanya memeriksa apakah permintaan sudah selesai, bukan apakah permintaan itu sudah ditolak.

Akibatnya, placeholder tetap diproses. Node prefill mengirim satu halaman KV cache ke node decode dan menandai transfer selesai. Node decode mengira seluruh halaman untuk prompt tersebut sudah ditulis, lalu membaca halaman lain yang masih menyimpan sisa data dari permintaan sebelumnya. Klien menerima HTTP 200, bukan error, sehingga respons dapat memuat teks dari sesi pelanggan lain.

Perbaikan tidak berhenti pada konfigurasi

Cloudflare memperbesar pool KV cache pada node prefill menjadi sekitar 2,04 juta token—hampir dua kali ukuran konteks GLM-5.3. Langkah ini memastikan prompt yang masih valid dalam konteks model juga muat di pool. Tetapi perusahaan mengakui bahwa mengandalkan ukuran pool saja terlalu rapuh karena quantization, parallelism, ukuran CUDA graph, atau versi model dapat mengubah kapasitas yang tersedia.

Karena itu, jalur penolakan di SGLang juga diubah. Permintaan yang sudah ditolak kini dihentikan di antrean admission sebelum bootstrap, alokasi memori, atau transfer KV cache terjadi. Perbaikan terkait masuk ke SGLang v0.5.20, v0.5.21, dan v0.5.22. Cloudflare merekomendasikan operator yang menjalankan prefill/decode terdisagregasi memakai v0.5.22 atau versi lebih baru.

Cloudflare juga menambahkan pemeriksaan ukuran pool terhadap panjang konteks pada setiap perubahan deployment. Untuk perlombaan yang berkaitan dengan pelepasan halaman memori dan transfer antarnode, perusahaan mengaktifkan deferred KV release, membatasi batch transfer Mooncake, serta menambahkan checksum dan KV canary pada arsitektur yang mendukungnya.

Pelajaran untuk operator model

Insiden ini memperlihatkan mengapa kode status HTTP tidak cukup untuk menguji layanan inferensi multi-tenant. Respons 200 hanya mengatakan permintaan selesai menurut protokol; ia tidak membuktikan bahwa model membaca memori yang benar. Cloudflare kini memeriksa ukuran pool langsung dari engine yang sedang berjalan dan memvalidasi output dengan penanda canary sebelum perubahan disebarkan.

Perusahaan sedang mengembangkan perlindungan yang lebih kuat: setiap halaman KV cache diberi tag yang berubah ketika halaman dialokasikan ulang, lalu tag yang diharapkan permintaan dibandingkan sebelum decode membaca cache. Prototipe internalnya menambah kurang dari satu persen throughput dan tail latency dalam pengujian Cloudflare, meski belum cukup umum untuk dipakai pada semua arsitektur model.

Arah jangka panjangnya adalah membuat engine gagal secara aman ketika sebuah permintaan mencoba membaca halaman yang bukan miliknya. Bagi pengguna, dampak praktisnya sederhana: kebocoran tersebut sudah ditutup pada layanan Cloudflare, tetapi operator yang menjalankan SGLang sendiri perlu memeriksa konfigurasi KV pool, memperbarui dependensi, dan mengaktifkan mekanisme verifikasi yang tersedia. Dalam sistem inferensi yang berbagi GPU, batas antara “permintaan terlalu besar” dan “data pelanggan lain terbaca” ternyata bisa ditentukan oleh satu jalur error yang tidak pernah benar-benar berhenti.

Sumber https://blog.cloudflare.com/kv-cache-exposure-remediation/ Sumber tambahan: https://github.com/sgl-project/sglang/releases