Cloudflare เปิดเผย GLM-5.3 บน Workers AI ส่งข้อมูลของผู้ใช้คนอื่นปนมาใน 155 response — prompt ยาวเกิน KV pool ของ prefill ทำให้ SGLang แบบ disaggregated อ่าน KV page ค้างเก่า แนะนำผู้รัน SGLang อัปเกรดเป็น v0.5.22

Cloudflare เผยแพร่ incident report เมื่อ 26 ต.ค. 2026 ซึ่งเป็นการเปิดเผยแบบประสานงานพร้อมกับบล็อกของทีม SGLang (LMSYS) ว่าโมเดล GLM-5.3 (@cf/zai-org/glm-5.3) บน Workers AI มีปัญหา tenant isolation ตั้งแต่วันเปิดตัว 27 ส.ค. จนถึง 9 ก.ย. ทำให้ลูกค้าบางรายได้ response ที่มี ข้อมูลจาก request ของลูกค้าคนอื่น ซึ่งส่งเข้าโมเดลเดียวกันไม่นานก่อนหน้าปนมาด้วย รวม 155 response และทุกกรณีเป็น prompt ที่ยาวเกิน 681,280 token Cloudflare ระบุว่าไม่พบหลักฐานว่ามีคนตั้งใจใช้ช่องโหว่นี้ และไม่มีโมเดลอื่นบน Workers AI ที่ได้รับผลกระทบ

ผู้ที่พบปัญหาคือ Gadi Evron จาก Knostic ซึ่งรายงานผ่าน HackerOne เมื่อ 8 ก.ย. Cloudflare ทำซ้ำได้ในเช้าวันรุ่งขึ้น ปิดโมเดลภายใน 40 นาทีหลังประกาศ incident และเปิดคืนในวันเดียวกันหลังแก้ทั้ง config และ engine ที่ต้องเขียนเรื่องนี้ไม่ใช่เพราะผู้ใช้ Workers AI ได้รับผลกระทบเท่านั้น แต่เพราะต้นเหตุครึ่งหนึ่งอยู่ใน SGLang ซึ่งเป็น inference engine โอเพนซอร์สที่ทีมจำนวนมากใช้ self-host โมเดลอยู่

เกิดอะไรขึ้น: สองปัญหาซ้อนกัน

1. Config ไม่ตรงกัน — Cloudflare ตั้ง context window ของ GLM-5.3 ไว้ 1,048,576 token แต่ KV cache pool บน prefill GPU จุได้แค่ 681,280 token ทีมรู้ตัวก่อนเปิดตัวว่าตัวเลขไม่ตรงกัน แต่เทสต์ long-context ก่อนเปิดตัวได้ HTTP 200 จึงคิดว่า engine จัดการได้ ข้อผิดพลาดคือ ตรวจแค่ status code กับ performance ไม่ได้ตรวจว่า output สมเหตุสมผลหรือไม่
2. บั๊กใน SGLang โหมด prefill/decode disaggregation — เมื่อ prompt ใหญ่เกิน pool, scheduler จะ reject และแทน prompt ด้วย placeholder 1 token (ผ่าน Req.set_finish_with_abort) ในโหมดเครื่องเดียวกลไกนี้ทำงานถูก client ได้ error แต่ในโหมดแยก prefill/decode คิว admission ทั้งสองฝั่งเช็กแค่ req.finished() ซึ่งยังเป็น False สำหรับ request ที่ถูก reject ผลคือ decode จองไว้ 8 page ตามความยาว prompt จริง แต่ prefill เขียนมาแค่ 1 page แล้วส่งสัญญาณว่า “transfer complete” decode จึงทำ attention บน page ที่เหลือซึ่ง ยังเก็บ prompt และคำตอบของผู้ใช้คนก่อน เพราะ KV page ไม่ได้ถูกล้างเป็นศูนย์ระหว่าง request (ซึ่งเป็นแนวปฏิบัติปกติเพื่อ performance)

สิ่งที่ทำให้บั๊กนี้น่ากลัวคือ client ได้ HTTP 200 พร้อม prompt_tokens ตรงกับ prompt ยาว และคำตอบอ่านรู้เรื่อง สัญญาณผิดปกติอย่างเดียวคือคำตอบมาเร็วเกินกว่าที่ prefill ยาวขนาดนั้นควรใช้ บั๊กนี้มีคนรายงานไว้แล้วตั้งแต่ 6 ก.ค. ใน issue #30233 ว่า prompt ยาวเกินทำให้ decode สร้างข้อความขยะ แต่ตอนนั้นยังไม่มีใครมองว่าเป็นปัญหาความปลอดภัย

ฝั่ง SGLang แก้อะไรไปแล้ว

• #36988 (v0.5.20) ปลด prefill request ที่ถูก abort ออกก่อนผลจะไปถึง decode ซึ่งปิดช่องโหว่ใน incident นี้ ส่วน #38935 (v0.5.21) reject ตั้งแต่ admission ก่อนจะมี bootstrap, allocation หรือ KV transfer ใด ๆ ตามแนวทาง patch ของ Cloudflare (#38704)
• --disaggregation-enable-kv-checksum (#39500, v0.5.21) ให้ decode ตรวจ checksum ของ KV ที่รับมาก่อนเริ่ม generate และแก้ --kv-canary ที่ใช้ตรวจจับ page เสียหาย แต่ Cloudflare บอกว่าทั้งสองตัวยัง ไม่รองรับทุก architecture รวมถึง GLM-5.3, GLM-5.3 Flash และ DeepSeek V4
• deferred KV release เปิดเป็นค่าเริ่มต้นแล้ว (#41023) เพื่อปิด race อีกกลุ่มหนึ่ง: ถ้า request ถูก abort ระหว่างที่ prefill กำลังเขียน KV ข้ามเครื่องผ่าน RDMA (Mooncake) แล้ว decode คืน page ทันที การเขียนที่ส่งไปแล้วจะไปทับ KV ของ request ถัดไป
• ทั้งหมดอยู่ใน v0.5.22 (ออก 19 ต.ค.) ยกเว้นงาน cleanup ของ checksum ที่ merge แล้วแต่ยังไม่ออก release ส่วน draft ให้ล้าง KV page เป็นศูนย์ตอนคืน (#46435) ยังอยู่ระหว่างพิจารณา

คำแนะนำจาก Cloudflare สำหรับคนที่รัน SGLang แบบ disaggregated: (1) อ่านขนาด KV pool จาก startup log ของ ทุก node เทียบกับ context length หลังเปลี่ยน weights, quantization, parallelism หรือ memory fraction ทุกครั้ง ถ้า pool เล็กกว่าให้ลด context length ลง (2) อัปเกรดเป็น v0.5.22 ขึ้นไป (3) เปิด deferred release ทั้งสองฝั่งและจำกัดขนาด Mooncake transfer batch (4) เปิด checksum/canary ในโมเดลที่รองรับ (5) ตั้ง load balancer ไม่ให้ abort request ก่อน token แรก

มุมมอง AI Curator

เรื่องนี้เป็นบทเรียนที่ใช้ได้กับทีมไทยที่ self-host LLM ให้ลูกค้าหลายราย ไม่ว่าจะเป็นผู้ให้บริการ cloud ในประเทศ, ทีม platform ในธนาคาร หรือ startup ที่ขาย API ภาษาไทยบน vLLM/SGLang เพราะทุกเจ้ากำลังแข่งกันโฆษณา context window ยาว ๆ แบบ 1M token ในขณะที่ KV pool จริงถูกกำหนดจาก GPU memory ที่เหลือหลังโหลด weights และ ไม่มีอะไรบังคับให้สองตัวเลขนี้ตรงกัน การ quantize ใหม่หรือเปลี่ยน tensor parallel แค่ครั้งเดียวก็ทำให้ pool หดลงได้โดยไม่มีใครสังเกต สิ่งที่ควรเพิ่มใน CI ทันทีคือ canary test แบบ Cloudflare: ส่ง prompt ที่ฝัง marker ไว้จาก account A แล้วยิง prompt ยาวเกือบเต็ม context จาก account B และตรวจว่า marker ของ A ไม่โผล่มาในคำตอบของ B ไม่ใช่แค่ตรวจว่าได้ 200

ประเด็นที่ใหญ่กว่านั้นคือ KV cache กำลังเป็นพื้นที่โจมตีแบบเดียวกับที่ CPU cache เคยเป็นในยุค Spectre: เพื่อความเร็ว page ไม่ถูกล้าง, ถูกแชร์ข้ามเครื่องผ่าน RDMA และถูก reuse ด้วย prefix caching ความปลอดภัยจึงขึ้นกับว่า engine ติดตามความเป็นเจ้าของ page ได้ถูกต้องทุก path หรือไม่ ซึ่ง Cloudflare เองยอมรับว่า “บั๊กตัวต่อไปจะมีรูปแบบที่เรายังไม่เคยเห็น” และกำลังผลักดันให้มี page tag ตรวจทุกครั้งที่อ่าน (prototype เสีย throughput ไม่ถึง 1%) สิ่งที่ควรชมคือการเปิดเผยอย่างละเอียด ทั้งตัวเลข timeline และ PR ทุกตัว ถ้าคุณเป็นลูกค้า inference API ข้อมูลที่ควรถามผู้ให้บริการตอนนี้คือ ใช้ engine เวอร์ชันไหน รัน prefill/decode แยกเครื่องหรือไม่ และ context window ที่ขายนั้นเทสต์ความถูกต้องของ output จริงจนสุดความยาวหรือเปล่า

แหล่งข่าว

• Cloudflare — Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang (26 ต.ค. 2026)
• LMSYS / SGLang Team — SGLang security update: improving request isolation (26 ต.ค. 2026)
• SGLang issue #30233 — aborted prefill requests (input too long) cause decode to generate garbage
• SGLang v0.5.22 release