Salah konfigurasi bikin prompt pengguna Workers AI bocor ke sesama pengguna

Antara 27 Agustus dan 9 September, sebagian pengguna Workers AI yang memakai model GLM-5.3 menerima jawaban yang memuat potongan permintaan pengguna lain. Dalam laporannya yang terbit 26 Oktober, Cloudflare menelusuri penyebabnya ke dua kesalahan yang kebetulan bertemu. GLM-5.3 berjalan dengan context window satu juta token, tetapi kolam KV cache di GPU prefill-nya hanya menampung sekitar 681.000 token. Tim Cloudflare tahu angkanya tidak cocok, tapi uji pra-rilis mengembalikan respons HTTP 200 yang normal, jadi mereka mengira engine akan menolak prompt kebesaran secara bersih.

Ternyata tidak. Akar masalah yang lebih dalam ada di SGLang, engine inference-nya, yang berjalan dalam mode disaggregated dengan prefill dan decode di kolam GPU terpisah. Saat sebuah prompt melebihi kapasitas kolam, SGLang menandai permintaan sebagai ditolak dan menukarnya dengan placeholder satu token, tapi antrean admission-nya hanya memeriksa apakah permintaan sudah selesai, bukan apakah sudah ditolak. Permintaan yang ditolak itu pun lolos: prefill menulis satu KV page, decode sudah memesan delapan page dan membaca semuanya, dan tujuh di antaranya masih menyimpan sisa data dari permintaan sebelumnya. KV page tidak dinolkan antar-permintaan, pilihan yang lazim demi performa, sehingga model mengembalikan jawaban mulus yang sebagian dirangkai dari prompt orang lain, lengkap dengan status HTTP 200, bukan pesan error. Totalnya 155 respons terdampak, semuanya dari prompt lebih panjang dari 681.280 token. Seorang peneliti Knostic melaporkannya lewat HackerOne, dan Cloudflare mereproduksi kebocoran dalam 25 menit, menarik modelnya, lalu merilis konfigurasi yang diperbaiki pada hari yang sama. Bug SGLang-nya sendiri sudah dilaporkan sejak 6 Juli.

Bagian yang lebih menarik justru rencana jangka panjangnya. Cloudflare membuat prototipe tag kepemilikan per-page yang menandai setiap pembacaan page yang bukan milik sebuah permintaan, dengan overhead di bawah 1% pada throughput dan tail latency, dan berencana memverifikasi secara formal protokol transfer cache berbasis RDMA miliknya.

Kenapa ini penting

Kalau Anda melayani model di GPU bersama, inilah kegagalan multi-tenancy yang pantas ditakuti: bukan serangan canggih, melainkan salah konfigurasi diam-diam plus engine yang menjawab 200 untuk permintaan yang ditolak. Siapa pun yang memakai SGLang dalam mode disaggregated sebaiknya pindah ke v0.5.22 atau lebih baru dan memastikan kolam KV minimal sebesar context window.