تقول Cloudflare إن خللًا في GLM-5.3 سرّب 155 استجابة عبر جلسات المستأجرين

نشرت Cloudflare في 26 أكتوبر 2026 تقريرًا عن الحادثة كشف عن انكشاف بيانات ذاكرة التخزين المؤقت 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 نموذج GLM 5.3 باستخدام SGLang، وهو محرك استدلال مفتوح المصدر، ضمن بنية مفككة: تعالج وحدات معالجة الرسومات الخاصة بالتهيئة المسبقة (prefill) الطلب وتنشئ ذاكرة التخزين المؤقت KV الخاصة به، ثم تنقلها عبر الوصول المباشر إلى الذاكرة عن بُعد (RDMA)، باستخدام Mooncake، إلى وحدات معالجة الرسومات الخاصة بفك الترميز، التي تولّد الاستجابة. وتتكون ذاكرة التخزين المؤقت KV من مجموعة مشتركة من صفحات ثابتة الحجم؛ ولا تُصفّر الصفحات بين الطلبات، لذا تقع على عاتق المحرك مسؤولية تتبّع ملكية كل صفحة.

يرجع التقرير الانكشاف إلى مشكلتين. تمثلت الأولى في إعداد خاطئ: إذ نشرت Cloudflare نموذج GLM 5.3 بنافذة سياق تتسع لـ1,048,576 رمزًا، بينما لم تتسع مجموعة ذاكرة التخزين المؤقت KV على وحدات معالجة الرسومات الخاصة بالتهيئة المسبقة إلا لـ681,280 رمزًا. وقالت Cloudflare إنها كانت على علم بهذا التفاوت قبل الإطلاق، لكنها توقعت أن يعيد المحرك خطأً لأي طلب لا يستطيع معالجته. ولأن اختبارات السياقات الطويلة أفضت إلى استجابات ناجحة، لم تعتقد الشركة أن هذا التفاوت يشكل مشكلة. وأضافت أن اختباراتها تحققت من رموز استجابة HTTP وأداء المحرك مع السياقات الطويلة، من دون التحقق من مخرجات النموذج واتساقها، وأنها باتت تتحقق مباشرةً من توافق حجم مجموعة KV مع طول السياق قبل شحن أي تغيير في عمليات النشر المفككة.

أما المشكلة الثانية فكانت خللًا في SGLang في التعامل مع الطلبات التي تتجاوز الحد الأقصى للطول في وضع التهيئة المسبقة وفك الترميز المفكك. كان النظام يضع داخليًا علامة رفض على الطلب الذي لا تتسع له المجموعة، ويستبدله بعنصر نائب من رمز واحد، لكن التهيئة المسبقة كانت لا تزال تنشئ ذاكرة تخزين مؤقت KV لهذا العنصر النائب وتشير إلى اكتمال النقل. بعد ذلك، كانت عقدة فك الترميز تولّد استجابة بالاعتماد على صفحات قديمة من ذاكرة التخزين المؤقت ما زالت تحتوي على بيانات من طلبات سابقة، فيما كان العميل يتلقى استجابة HTTP 200 بدلًا من HTTP 400.

يذكر فريق SGLang في منشوره المنسق الخاص به أن مسار الرفض على العقدة المنفردة كان يعيد خطأً بدلًا من ذلك، لذا لم تحدث المشكلة إلا عند تقديم الخدمة ببنية مفككة. وكان مستخدم آخر قد أبلغ SGLang عن الخلل في 6 يوليو 2026، ضمن المسألة رقم #30233، وقالت Cloudflare إنها لاحظت ذلك أثناء التحقيق.

الاستجابة للحادثة ومعالجة المشكلة

بدأت Cloudflare التحقق من البلاغ عند الساعة 08:00 بالتوقيت العالمي المنسق في 9 سبتمبر 2026، وأعلنت وقوع حادثة أمنية عند الساعة 13:22 بعدما أعاد فريق أمن المنتجات لديها إظهار التسريب باستخدام حسابين مستقلين في غضون 25 دقيقة. وجعلت GLM 5.3 خاصًا عند الساعة 14:00، وحددت السبب الجذري عند الساعة 14:35، وعمّمت الإعداد المصحح على جميع عُقد التهيئة المسبقة بحلول الساعة 14:52، وأعادت بناء عملية النشر كاملةً باستخدام تصحيح للمحرك وضعته Cloudflare بحلول الساعة 19:04، ثم أعادت إتاحة النموذج للعامة عند الساعة 19:40. وسجّلت صفحة حالة Cloudflare أن حادثة Workers AI بدأت عند الساعة 10:25 صباحًا بتوقيت شرق الولايات المتحدة الصيفي في 9 سبتمبر 2026، ورُصدت عند الساعة 11:02 صباحًا بالتوقيت نفسه، وحُلّت عند الساعة 4:09 مساءً.

طابق إصلاح الإعدادات تهيئة GLM 5.2، ما أتاح تحرير قدر كافٍ من ذاكرة وحدة معالجة الرسومات حتى أصبحت مجموعة 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 بأن فروق معدل النقل، مع وسائل الحماية، ظلت ضمن ±2% في 21 تشغيلًا على وحدتي GPU من طراز H100، وأن كل فاصل ثقة بنسبة 95% شمل الصفر. كما قاس الفريق في اختبار منفصل شمل 16 تشغيلًا على وحدتي GPU من طراز H200 كلفة تفعيل التحرير المؤجل لـKV افتراضيًا، فبلغت −0.38%، مع فاصل ثقة يتراوح بين −2.12% و+1.36%، ووصفها بأنها غير ذات دلالة إحصائية. واجتمع فريق Cloudflare مع القائمين على صيانة SGLang في RadixArk يوم 10 سبتمبر 2026، وعمّم إجراءات تعزيز إضافية على جميع عمليات نشر SGLang الإنتاجية لديه بين 11 و19 سبتمبر 2026، فيما جرت عمليات الدمج في المستودع الرئيسي، التي شملت إصلاحات قبول الطلبات، والمجاميع الاختبارية لكل عملية نقل، والحفاظ على إقرارات الإجهاض، والتحرير المؤجل لـKV المفعّل افتراضيًا، بين 16 سبتمبر و12 أكتوبر 2026.

بالنسبة إلى المشغّلين الآخرين الذين يستخدمون SGLang في وضع مفكك، يوصي تقرير Cloudflare بقياس حجم مجمّع KV مقارنةً بطول السياق على كل عقدة للتهيئة المسبقة وفك الترميز بعد أي تغيير في الأوزان أو التكميم أو التوازي أو نسبة الذاكرة؛ والترقية إلى إصدار يتضمن كلا إصلاحي قبول الطلبات؛ وتشغيل التحرير المؤجل لـKV في كلا الدورين؛ وتفعيل اكتشاف تلف البيانات حيثما كان النموذج يدعمه؛ وضبط موازنات الحمل بحيث لا يؤدي انقطاع اتصال العميل إلى إجهاض الطلب أثناء النقل.

قالت Cloudflare إنها وضعت سابقًا تصميمًا أوليًا يضع علامة على كل صفحة KV فعلية ويتحقق من التعيين قبل أن يقرأ فك الترميز ذاكرة التخزين المؤقت، وإن كلفته في الاختبارات كانت أقل من 1% من معدل النقل وزمن الاستجابة عند الذيل. واختبرت الشركة التصميم الأولي على GLM 5.2 في منتصف أغسطس 2026، لكنها عطّلته بعد ذلك بوقت قصير بسبب مشكلات في الموثوقية. وتعمل Cloudflare مع فريق SGLang على إصدار إنتاجي مدمج في المحرك، وتُعدّ المجموعات الاختبارية لكل عملية نقل الواردة في طلب السحب #39500 الخطوة الأولى في هذا المسار. وقالت الشركة إنها توظف خبرتها في الأساليب الصورية لنمذجة بروتوكول نقل ذاكرة التخزين المؤقت لـKV القائم على RDMA باستخدام Mooncake ضمن عملية نشر SGLang الإنتاجية لديها، ولإثبات سلامته.

يشيد منشور فريق SGLang بمهندسي Cloudflare Kevin Flansburg وKastan Day تقديرًا لعملهما على الإصلاحات، ويورد الإفصاح المنسق بين SGLang وCloudflare في 26 أكتوبر 2026 بوصفه المحطة الأخيرة في التسلسل الزمني للإفصاح. ومن المرتقب صدور تقرير الباحث نفسه، الذي قال فريق SGLang إنه سيوضح الاكتشاف والتحقق الخارجي.