Cloudflare ระบุว่าบั๊กใน GLM-5.3 ทำให้ข้อมูลคำตอบ 155 รายการรั่วไหลข้ามเซสชันของผู้เช่า

เมื่อวันที่ 26 ตุลาคม 2026 Cloudflare เผยแพร่รายงานเหตุการณ์ ซึ่งเปิดเผยว่ามีข้อมูลในแคช KV รั่วไหลข้ามคำขอในโมเดล GLM-5.3 บนแพลตฟอร์ม Workers AI โดยคำตอบ 155 รายการจากพรอมป์ต์ที่ยาวมากมีข้อมูลจากเซสชันของลูกค้ารายอื่นปะปนอยู่

Gadi Evron นักวิจัยด้านความปลอดภัยจาก Knostic รายงานปัญหาการแยกข้อมูลระหว่างผู้เช่าให้ Cloudflare ทราบเมื่อวันที่ 8 กันยายน 2026 ผ่านโปรแกรม HackerOne ของบริษัท การรั่วไหลส่งผลกระทบต่อโมเดลที่ให้บริการในชื่อ @cf/zai-org/glm-5.3 ตั้งแต่วันที่ 27 สิงหาคม 2026 ซึ่งเป็นวันที่ GLM 5.3 เปิดตัวบน Workers AI Cloudflare แก้ไขปัญหาและนำโมเดลกลับมาให้บริการเมื่อวันที่ 9 กันยายน 2026 พร้อมระบุว่าได้ยืนยันแล้วว่าโมเดลอื่นที่โฮสต์บน Workers AI ไม่ได้รับผลกระทบ

คำตอบที่ได้รับผลกระทบทั้ง 155 รายการมาจากพรอมป์ต์ที่มีความยาวเกิน 681,280 โทเค็น Cloudflare ระบุว่าเมื่อตัดการทดสอบของบริษัทเองและคำขอของนักวิจัยออกแล้ว คำขอที่ตรวจพบมีช่วงเวลาและปริมาณสอดคล้องกับการใช้งานบริบทขนาดยาวตามปกติ มากกว่าจะเป็นการใช้ประโยชน์จากบั๊กซ้ำ ๆ และไม่พบหลักฐานว่ามีการจงใจใช้ประโยชน์จากช่องโหว่

ปัญหาสองประการที่อยู่เบื้องหลังการรั่วไหล

GLM เป็นโมเดลสร้างข้อความจาก Z.ai ที่ออกแบบมาสำหรับเวิร์กโฟลว์การเขียนโค้ดโดยใช้เอเจนต์ และเป็นหนึ่งในโมเดลจำนวนมากที่ให้บริการผ่าน Workers AI Cloudflare ใช้ SGLang ซึ่งเป็นเอนจินอนุมานแบบโอเพนซอร์สกับ GLM 5.3 ในสถาปัตยกรรมแบบแยกส่วน โดย GPU สำหรับพรีฟิลล์จะประมวลผลพรอมป์ต์และสร้างแคช KV จากนั้นจึงส่งแคชผ่านการเข้าถึงหน่วยความจำโดยตรงระยะไกล (RDMA) ด้วย Mooncake ไปยัง GPU สำหรับดีโค้ด ซึ่งจะสร้างคำตอบ แคช KV เป็นพูลส่วนกลางของเพจขนาดคงที่ โดยจะไม่มีการล้างข้อมูลในเพจระหว่างคำขอ ดังนั้นเอนจินจึงต้องติดตามว่าเพจแต่ละเพจเป็นของใคร

รายงานระบุว่าการรั่วไหลเกิดจากปัญหาสองประการ ประการแรกคือการกำหนดค่าผิดพลาด: Cloudflare นำ GLM 5.3 มาใช้โดยกำหนดหน้าต่างบริบทไว้ที่ 1,048,576 โทเค็น แต่พูลแคช KV บน GPU สำหรับพรีฟิลล์รองรับได้เพียง 681,280 โทเค็น Cloudflare ระบุว่าทราบถึงความไม่สอดคล้องนี้ก่อนเปิดตัว แต่คาดว่าเอนจินจะส่งข้อผิดพลาดกลับมาสำหรับพรอมป์ต์ที่ประมวลผลไม่ได้ และการทดสอบบริบทขนาดยาวของบริษัทก็ได้รับคำตอบที่สำเร็จ จึงไม่คิดว่าความไม่สอดคล้องดังกล่าวเป็นปัญหา บริษัทระบุว่าการทดสอบตรวจสอบรหัสตอบกลับ HTTP และประสิทธิภาพของเอนจินเมื่อใช้บริบทขนาดยาว แต่ไม่ได้ตรวจสอบผลลัพธ์และความสอดคล้องของโมเดล และขณะนี้บริษัทตรวจสอบขนาดพูล KV เทียบกับความยาวของบริบทโดยตรง ก่อนอนุมัติให้การเปลี่ยนแปลงใด ๆ ในการติดตั้งใช้งานแบบแยกส่วนเริ่มใช้งาน

ประการที่สองคือบั๊กใน SGLang ซึ่งเกี่ยวข้องกับการจัดการคำขอที่ยาวเกินขนาดในโหมดพรีฟิลล์และดีโค้ดแบบแยกส่วน พรอมป์ต์ที่มีขนาดเกินกว่าพูลจะรองรับได้ถูกทำเครื่องหมายภายในระบบว่าถูกปฏิเสธ และแทนที่ด้วยข้อความสำรองขนาดหนึ่งโทเค็น แต่ขั้นตอนพรีฟิลล์ยังคงสร้างแคช KV สำหรับข้อความสำรองนั้นและส่งสัญญาณว่าการถ่ายโอนเสร็จสิ้นแล้ว จากนั้นโหนดดีโค้ดก็สร้างคำตอบโดยอาศัยเพจแคชเก่าที่ยังคงมีข้อมูลจากคำขอก่อนหน้าอยู่ และไคลเอ็นต์ได้รับการตอบกลับ HTTP 200 แทน HTTP 400

ทีม SGLang ระบุในโพสต์ที่เผยแพร่ประสานกับ Cloudflareว่าเส้นทางการปฏิเสธคำขอบนโหนดเดี่ยวจะส่งข้อผิดพลาดกลับแทน ดังนั้นปัญหานี้จึงเกิดขึ้นเฉพาะกับการให้บริการแบบแยกส่วน ผู้ใช้รายอื่นรายงานบั๊กนี้ต่อ SGLang เป็นปัญหา #30233 เมื่อวันที่ 6 กรกฎาคม 2026 ซึ่ง Cloudflare ระบุว่าพบระหว่างการตรวจสอบเหตุการณ์

การรับมือและแก้ไขเหตุการณ์

Cloudflare เริ่มตรวจสอบรายงานเมื่อเวลา 08:00 UTC ของวันที่ 9 กันยายน 2026 และประกาศว่าเป็นเหตุการณ์ด้านความปลอดภัยเมื่อเวลา 13:22 หลังทีมความปลอดภัยผลิตภัณฑ์ของบริษัทจำลองการรั่วไหลได้โดยใช้บัญชีอิสระสองบัญชีภายใน 25 นาที บริษัทตั้งค่า GLM 5.3 ให้เป็นส่วนตัวเมื่อเวลา 14:00 ระบุต้นตอได้เมื่อเวลา 14:35 ปรับโหนดพรีฟิลล์ทั้งหมดให้ใช้การกำหนดค่าที่แก้ไขแล้วเสร็จภายในเวลา 14:52 สร้างการติดตั้งใช้งานทั้งหมดขึ้นใหม่พร้อมแพตช์เอนจินที่ Cloudflare เขียนเองเสร็จเมื่อเวลา 19:04 และเปิดให้เข้าถึงโมเดลได้อีกครั้งเมื่อเวลา 19:40 หน้าสถานะของ Cloudflareบันทึกเหตุการณ์ Workers AI ว่าเริ่มขึ้นเมื่อเวลา 10:25 น. EDT ของวันที่ 9 กันยายน 2026 ระบุเหตุการณ์ได้เมื่อเวลา 11:02 น. EDT และแก้ไขเสร็จเมื่อเวลา 16:09 น. EDT

การแก้ไขการกำหนดค่าทำให้ระบบกลับมาใช้การตั้งค่าแบบเดียวกับ GLM 5.2 และเพิ่มหน่วยความจำ GPU ที่ว่างจนพูล KV สำหรับพรีฟิลล์รองรับได้ประมาณ 2.04 ล้านโทเค็น หรือราวสองเท่าของความยาวบริบท 1,048,576 โทเค็น ดังนั้นพรอมป์ต์ที่อยู่ภายในขนาดหน้าต่างบริบทจะอยู่ภายในขนาดพูลเสมอ แพตช์เอนจินจะนำคำขอที่มีสถานะรอการปฏิเสธออกจากคิวรับคำขอของระบบแยกส่วน พร้อมส่งข้อผิดพลาดเดิมกลับ ก่อนที่จะเริ่มขั้นตอนบูตสแตรป จัดสรรทรัพยากร หรือถ่ายโอน KV Cloudflare ตรวจสอบการแก้ไขทั้งสองรายการด้วยสคริปต์จำลองเหตุการณ์ของนักวิจัยและการทดสอบด้วยเครื่องหมายตรวจจับของบริษัทเอง ก่อนนำโมเดลกลับมาให้บริการ

การแก้ไขในโครงการต้นทางและงานที่กำลังดำเนินอยู่

Cloudflare เสนอการแก้ไขต่อโครงการต้นทางในรูปแบบคำขอดึง #38704 ของ SGLang และผู้ดูแลโครงการได้ผสาน #38935 ซึ่งปฏิเสธคำขอที่ได้รับผลกระทบตั้งแต่ขั้นตอนรับคำขอตามแนวทางของ Cloudflare ส่วนการแก้ไขที่เกี่ยวข้องอีกฉบับคือ #36988 ได้ผสานไปเมื่อวันที่ 6 กันยายน 2026 เพื่อแก้ไขเส้นทางความล้มเหลวที่เกี่ยวข้อง แพตช์ดังกล่าวรวมอยู่ใน SGLang v0.5.20 และมีการปรับปรุงเพิ่มเติมใน v0.5.21 ซึ่งเผยแพร่เมื่อวันที่ 2 ตุลาคม 2026 และ v0.5.22 ซึ่งเผยแพร่เมื่อวันที่ 19 ตุลาคม 2026 โดย Cloudflare แนะนำให้ผู้ดูแลระบบ SGLang ทุกคนอัปเดตเป็น v0.5.22 หรือใหม่กว่า ทีม SGLang ระบุว่า v0.5.21 ป้องกันการติดตั้งใช้งาน Mooncake และ NIXL ได้ตามค่าเริ่มต้นสำหรับความล้มเหลวทุกประเภท การติดตั้งใช้งาน MORI ต้องใช้บิลด์ใน v0.5.22 และชุดการแก้ไขนี้ไม่ได้ถูกนำไปใช้ย้อนหลังกับสาขารุ่นก่อนหน้า

ทีม SGLang รายงานว่า จากการทดสอบ 21 รอบบน GPU H100 จำนวน 2 ตัว ความแตกต่างของปริมาณงานเมื่อเปิดใช้มาตรการป้องกันอยู่ภายใน ±2% โดยช่วงความเชื่อมั่น 95% ของทุกค่าครอบคลุมศูนย์ และจากการทดสอบแยกอีก 16 รอบบน GPU H200 จำนวน 2 ตัว พบว่าการเปิดใช้การปล่อย KV แบบหน่วงเวลาเป็นค่าเริ่มต้นมีต้นทุนอยู่ที่ −0.38% โดยช่วงความเชื่อมั่นอยู่ที่ −2.12% ถึง +1.36% ซึ่งทีมระบุว่าไม่มีนัยสำคัญ Cloudflare พบกับผู้ดูแล SGLang ที่ RadixArk เมื่อวันที่ 10 กันยายน 2026 จากนั้นได้ทยอยเพิ่มมาตรการเสริมความปลอดภัยให้กับการติดตั้ง SGLang สำหรับใช้งานจริงทั้งหมดระหว่างวันที่ 11 ถึง 19 กันยายน 2026 ส่วนการผสานการแก้ไขเข้ากับโครงการต้นทาง ซึ่งครอบคลุมการแก้ไขขั้นตอนรับคำขอ การตรวจสอบ checksum สำหรับการถ่ายโอนแต่ละครั้ง การคงการยืนยันการยกเลิกไว้ และการเปิดใช้การปล่อย KV แบบหน่วงเวลาเป็นค่าเริ่มต้น ดำเนินการตั้งแต่วันที่ 16 กันยายนถึง 12 ตุลาคม 2026

สำหรับผู้ให้บริการรายอื่นที่ใช้งาน SGLang ในโหมดแยกส่วน รายงานของ Cloudflare แนะนำให้วัดขนาดพูล KV เทียบกับความยาวบริบทบนทุกโหนด prefill และ decode หลังมีการเปลี่ยนแปลงน้ำหนักโมเดล การควอนไทซ์ การประมวลผลแบบขนาน หรือสัดส่วนหน่วยความจำ ให้อัปเกรดเป็นบิลด์ที่มีการแก้ไขขั้นตอนรับคำขอทั้งสองรายการ ใช้การปล่อย KV แบบหน่วงเวลาทั้งในบทบาท prefill และ decode เปิดใช้การตรวจจับข้อมูลเสียหายในกรณีที่โมเดลรองรับ และกำหนดค่า load balancer เพื่อไม่ให้การตัดการเชื่อมต่อของไคลเอนต์ยกเลิกคำขอระหว่างการถ่ายโอน

Cloudflare ระบุว่า ก่อนหน้านี้บริษัทได้สร้างต้นแบบการออกแบบที่ติดแท็กให้กับหน้า KV จริงแต่ละหน้า และตรวจสอบการจับคู่ก่อนที่ decode จะอ่านแคช โดยการทดสอบพบว่าต้นแบบดังกล่าวมีต้นทุนด้านปริมาณงานและความหน่วงช่วงท้ายต่ำกว่า 1% บริษัททดสอบต้นแบบนี้กับ GLM 5.2 ในช่วงกลางเดือนสิงหาคม 2026 แต่ปิดใช้งานหลังจากนั้นไม่นานเนื่องจากปัญหาด้านความน่าเชื่อถือ Cloudflare กำลังร่วมมือกับทีม SGLang เพื่อพัฒนาเวอร์ชันสำหรับใช้งานจริงที่ผนวกรวมอยู่ในเอนจิน โดย checksum สำหรับการถ่ายโอนแต่ละครั้งใน pull request #39500 ถือเป็นก้าวแรก นอกจากนี้ บริษัทยังระบุว่ากำลังนำประสบการณ์ด้านวิธีการพิสูจน์เชิงรูปแบบมาใช้สร้างแบบจำลองและพิสูจน์ความปลอดภัยของโปรโตคอลถ่ายโอนแคช KV ที่ใช้ RDMA โดยอาศัย Mooncake ในการติดตั้ง SGLang สำหรับใช้งานจริงของบริษัท

โพสต์ของทีม SGLang กล่าวขอบคุณวิศวกร Cloudflare อย่าง Kevin Flansburg และ Kastan Day สำหรับการทำงานแก้ไขปัญหา พร้อมระบุว่าการเปิดเผยข้อมูลที่ประสานงานร่วมกันระหว่าง SGLang กับ Cloudflare เมื่อวันที่ 26 ตุลาคม 2026 เป็นรายการสุดท้ายในลำดับเหตุการณ์การเปิดเผยข้อมูล รายงานของนักวิจัยเอง ซึ่งทีม SGLang ระบุว่าจะอธิบายการค้นพบและการตรวจสอบยืนยันจากภายนอกนั้น กำลังจะเผยแพร่