Teknologi

Celah Keamanan Model GLM-5.3 Workers AI Cloudflare

Celah Keamanan Model GLM-5.3 Workers AI Cloudflare
Daftar Isi
  1. Kronologi dan Dampak
  2. Penyebab Masalah
  3. Tindakan Remediasi dan Pengerasan

Cloudflare mengatasi masalah isolasi penyewa (tenant isolation) yang mempengaruhi model AI GLM-5.3 Workers AI (@cf/zai-org/glm-5.3) setelah menerima laporan dari peneliti keamanan Gadi Evron dari Knostic pada 8 September 2026. Masalah tersebut telah diperbaiki dan model dipulihkan pada 9 September, dengan konfirmasi bahwa tidak ada model lain di Workers AI yang terdampak.

Kronologi dan Dampak

Antara 27 Agustus dan 9 September 2026, sejumlah kecil pelanggan yang menggunakan model GLM 5.3 Workers AI menerima tanggapan yang berisi data dari permintaan pelanggan lain yang dikirimkan ke model yang sama sesaat sebelumnya. Sebanyak 155 tanggapan terpengaruh, dan semuanya merupakan prompt yang melebihi 681.280 token. Berdasarkan waktu dan volume, permintaan tersebut konsisten dengan penggunaan konteks panjang yang normal tanpa indikasi eksploitasi yang disengaja.

Gadi Evron mengirimkan laporan melalui program HackerOne Cloudflare, menyatakan bahwa prompt sangat panjang yang dikirim ke model terkadang mengembalikan teks dari sesi pengguna lain. Cloudflare mereproduksi masalah tersebut keesokan paginya dan menonaktifkan model dalam waktu 40 menit setelah menyatakan insiden. Layanan dipulihkan pada hari yang sama setelah konfigurasi yang dikoreksi dan mesin inferensi yang ditambal diterapkan.

Penyebab Masalah

Insiden eksposur KV cache lintas permintaan ini diakibatkan oleh dua masalah yang saling tumpang tindih. Masalah pertama adalah salah konfigurasi pada mesin inferensi sumber terbuka, SGLang, yang digunakan oleh Cloudflare. Model GLM 5.3 diterapkan dengan jendela konteks 1.048.576 token, tetapi kolam KV cache pada GPU prefill hanya memiliki kapasitas 681.280 token. Ketidakcocokan ini diketahui sebelum peluncuran, namun diharapkan mesin akan mengembalikan kesalahan untuk prompt yang tidak dapat diproses.

Masalah kedua adalah bug pada cara SGLang menangani permintaan yang melebihi batas dalam mode prefill/decode terdisagregasi. Prompt yang tidak sesuai ditandai secara internal sebagai ditolak dan diganti dengan placeholder satu token, tetapi prefill menghasilkan KV cache untuk placeholder tersebut dan mentransfernya ke node decode tanpa menghentikan permintaan. Node decode berasumsi bahwa prefill menimpa KV cache dari permintaan sebelumnya, padahal sebagian besar status sebelumnya dibiarkan utuh. Akibatnya, respons terhadap prompt yang lebih panjang dari 681.280 token dapat memuat data dari sesi GLM 5.3 pengguna lain.

Tindakan Remediasi dan Pengerasan

Cloudflare mengambil sejumlah langkah untuk memperbaiki kerentanan tersebut sebelum memulihkan akses publik. Konfigurasi disesuaikan agar kolam menampung kapasitas penuh dengan menyamakannya dengan konfigurasi GLM 5.2, sehingga kolam prefill KV kini menampung sekitar 2,04 juta token. Selain itu, mesin ditambal agar permintaan yang membawa penolakan tertunda ditarik di antrean penerimaan disagregasi sebelum alokasi atau transfer KV terjadi.

Cloudflare memperluas rilis tertunda untuk menampung halaman sumber prefill dan mencakup setiap jenis kegagalan, menerapkan batch transfer Mooncake yang dibatasi agar panggilan tidak melampaui batas waktu, serta mengubah penyeimbang beban agar pemutusan sambungan klien tidak lagi membatalkan permintaan di tengah transfer. Perubahan ini divalidasi menggunakan skrip reproduksi peneliti dan pengujian penanda kenari sebelum model dipulihkan.

Cloudflare mempublikasikan laporan ini bersama dengan SGLang sebagai pengungkapan terkoordinasi dan menyarankan operator lain yang menjalankan SGLang dalam mode prefill/decode terdisagregasi untuk memperbarui dependensi SGLang ke versi v0.5.22 atau yang lebih baru serta mengukur kolam KV dibandingkan dengan panjang konteks.

Mungkin Anda Suka

Tinggalkan Komentar

Alamat email tidak akan dipublikasikan. Kolom wajib ditandai *