نشرت Cloudflare تقريرًا مفصلاً عن الحادث يصف كيف تسبب خطأ في التعامل مع ذاكرة التخزين المؤقت في منصة الذكاء الاصطناعي بدون خادم الخاصة بها في قيام 155 مستخدمًا على الأقل لنشر نموذج GLM-5.3 بتلقي استجابات تحتوي على أجزاء من مطالبات ومخرجات العملاء الآخرين. يقدم التقرير، الذي نُشر في 26 أكتوبر ككشف منسق جنبًا إلى جنب مع مشروع محرك الاستدلال مفتوح المصدر SGLang، نظرة عامة نادرة داخل السباكة التي تخدم LLM متعددة المستأجرين - وتحذيرًا حول الافتراضات الأمنية لذاكرة GPU.

كيف تم العثور على التسرب لمزيد من السياق حول هذه القصة، راجع أحدث تطورات الذكاء الاصطناعي.

وفقًا لـ Cloudflare، قام الباحث الأمني Gadi Evron من Knostic بتنبيه الشركة في 8 سبتمبر 2026، من خلال برنامج مكافآت الأخطاء HackerOne. أفاد إيفرون أن المطالبات الطويلة جدًا التي تم إرسالها إلى نموذج GLM-5.3 على منصة Cloudflare's Workers AI كانت أحيانًا تُرجع نصًا ينتمي إلى جلسات مستخدمين آخرين. أعادت Cloudflare إنتاج المشكلة في صباح اليوم التالي وعطلت النموذج في نفس اليوم، واستعادته في 9 سبتمبر بعد نشر الإصلاحات.

النموذج المتأثر هو @cf/zai-org/glm-5.3 — نموذج الترميز الوكيل من Z.ai الذي تخدمه Cloudflare من خلال Workers AI، منصة الاستدلال بدون خادم الخاصة بالشركة. وأكدت Cloudflare أنه لم يتأثر أي نموذج آخر مستضاف على المنصة.

ماذا حدث بالفعل

يعود الحادث إلى مشكلتين متداخلتين، واحدة تشغيلية والأخرى في المحرك نفسه.

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

ثانيا، خلل المحرك. في وضع التعبئة المسبقة/فك التشفير المُصنف - وهي البنية التي يستخدمها Workers AI، حيث تقوم مجموعة واحدة من وحدات معالجة الرسومات بمعالجة الموجه وتسليم ذاكرة التخزين المؤقت KV الناتجة إلى مجموعة منفصلة من وحدات معالجة الرسومات التي تولد الاستجابة - تعاملت SGLang مع الطلب الزائد بشكل غير صحيح. تم وضع علامة داخليًا على المطالبة التي لا تتناسب مع المجموعة على أنها مرفوضة واستبدالها بعنصر نائب ذو رمز مميز واحد. ولكن بدلاً من إجهاض الطلب وإرجاع خطأ العميل، قامت مرحلة التعبئة المسبقة بإنشاء ذاكرة تخزين مؤقت KV لموجه العنصر النائب ونقلها إلى عقدة فك التشفير، والتي أنتجت بعد ذلك استجابة اختلطت بالبيانات المتبقية من الطلبات السابقة التي تتقاسم نفس صفحات الذاكرة.

النتيجة: في الفترة ما بين 27 أغسطس و9 سبتمبر، تلقى عدد صغير من العملاء الذين يستخدمون النموذج ردودًا تحتوي على بيانات من طلبات عملاء آخرين تم تقديمها قبل وقت قصير من طلباتهم. في المجمل، تأثرت 155 استجابة، جميعها، كما وجدت Cloudflare، لمطالبات أطول من 681,280 رمزًا مميزًا.

لا يوجد دليل على الاستغلال المتعمد

وذكرت Cloudflare أنه بعد استبعاد الاختبارات الخاصة بها وطلبات التحقق من صحة الباحث، كانت الطلبات المتأثرة متسقة من حيث التوقيت والحجم مع الاستخدام العادي طويل السياق، ولم تجد الشركة أي دليل على أن أي شخص استغل الخطأ عمدًا. ونظرًا لأن كل طلب متأثر تجاوز سعة المجمع الأصغر حجمًا، فقد كانت نافذة التعرض مقيدة بإحكام - وهي بطانة فضية تنبع من التكوين الخاطئ الذي تسبب في المشكلة.

الحل: مجموعات أكبر ومسار فشل أكثر أمانًا

نجح العلاج في كلا طبقتي الفشل. أعادت Cloudflare تكوين نشر GLM-5.3 الخاص بها ليتوافق مع تكوين GLM-5.2، مما أدى إلى تحرير ما يكفي من ذاكرة وحدة معالجة الرسومات (GPU) التي تحتوي الآن مجموعة KV المليئة مسبقًا على حوالي 2.04 مليون رمز مميز - تقريبًا ضعف طول سياق النموذج المكون من 1,048,576 رمزًا مميزًا. إن المطالبة التي تناسب نافذة السياق تناسب المجموعة دائمًا.

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

لماذا تعد ذاكرة GPU المشتركة سؤالًا أمنيًا

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

وصل الكشف إلى مجتمع المطورين: وصلت القصة إلى 123 نقطة على Hacker News في غضون ساعات، مع تركيز المناقشة على كيف أن وضع الفشل - وهو الطلب الذي كان يجب أن يفشل بصوت عالٍ بدلاً من الاستمرار بصمت في حالة فاسدة - يعكس الدروس الكلاسيكية من هندسة الأنظمة الموزعة.

درس أوسع للبنية التحتية للذكاء الاصطناعي

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

بالنسبة للمؤسسات التي تعتمد على منصات الذكاء الاصطناعي بدون خادم، فإن الاستنتاج المستفاد من تقرير Cloudflare ذو شقين: أخطاء عزل المستأجر في خدمة LLM حقيقية وحدثت بالفعل في الإنتاج، ووقت استجابة البائعين - أقل من 24 ساعة من الإبلاغ إلى التعطيل، ويوم واحد للإصلاح والاستعادة - هو معيار الاجتهاد في الطلب من أي مزود يتعامل مع المطالبات الحساسة.

---

ابق على اطلاع بأخبار الذكاء الاصطناعي

آخر أخبار وتحليلات وإنجازات الذكاء الاصطناعي — في مكان واحد.

اقرأ المزيد من أخبار الذكاء الاصطناعي →