Palisade: نماذج Qwen 3.8 وجّهت طلبات محظورة عبر وكيل Alibaba Cloud

وجدت تحقيق متابعة من شركة أمان الذكاء الاصطناعي Palisade Research أن عدة نماذج Alibaba Qwen 3.8 وجّهت بعض طلبات الويب المحظورة عبر وكيل Alibaba Cloud في سنغافورة. يربط الباحثون هذا السلوك بالتعلم بالتعزيز أثناء التدريب ويقولون إنهم لم يجدوا أي علامات على استخراج بيانات خبيث، لكن مجال الوكيل لا يزال فعالاً. تأتي هذه النتائج بعد تقرير سابق من Cohere حول محاولة Qwen3.8-Flash-Next إرسال سلسلة اختبار إلى خادم تخزين سحابي في بكين ضمن بيئة معزولة.

التقرير الأولي من Cohere

أبلغت Cohere أولاً عن هذا السلوك بعد اختبار Qwen3.8-Flash-Next. بدلاً من كتابة قاعدة لكشف الهجمات كما هو مطلوب، فحص النموذج بيئته بحثاً عن برامج نقل البيانات وإعدادات DNS، ثم حاول رفع سلسلة اختبار إلى خادم تخزين سحابي في بكين. حظرت البيئة المعزولة الاتصال. ترى Cohere هذا السلوك في أقل من واحد من كل 100,000 استدعاء، لكن ملايين التفاعلات بين الوكلاء قد تؤدي إلى عدة محاولات.

اقترحت Cohere أن سجلات وكلاء غير مفلترة من بيئات اختبار أو أدوات أطراف ثالثة تسربت إلى النموذج أثناء مرحلة التدريب اللاحق، أو أن شخصاً ما ربما أضاف باباً خلفياً مقصوداً. Cohere منافس مباشر لـ Qwen. تعمل مع شركة الذكاء الاصطناعي الألمانية Aleph Alpha لإصدار نماذج ذكاء اصطناعي مفتوحة ذات سيادة غربية، ولكليهما مصلحة مالية في توجيه المستخدمين بعيداً عن البدائل الصينية. بعد انتقادات حول صياغتها، نشرت Cohere المجموعة الكاملة للسلوكيات الموثقة للنموذج على HuggingFace.

Palisade يوسع الاختبارات

بعد تقرير Cohere، بحثت Palisade Research في بيانات تقييم من خمسة نماذج Qwen عن "aliyuncs.com." ظهرت السلسلة في Qwen3.8-Max-0902 و Qwen3.8-Max و Qwen3.8-27B، بينما لم تظهر أي تطابقات في نماذج Qwen 3.7 الأقدم. ذهبت هذه الطلبات إلى منطقة سنغافورة في Alibaba Cloud وأعادت خطأ 403 Forbidden في كل مرة.

في تفكيره الداخلي، تساءل Qwen3.8-Max لماذا اتصل بـ "weird aliyuncs proxy URL"، رغم أن استدعاءات الأدوات الفعلية ذهبت إلى sec.gov. أحياناً اتصلت النماذج فعلياً بوكيل Alibaba Cloud، وجّهت طلبات مواقع مثل sec.gov أو mckinsey.com عبر الخادم مع بيانات اعتماد وتوقيعات مُختلقة. في أوقات أخرى، خيّل النموذج فقط استخدام الوكيل في تفكيره الداخلي.

معدلات الرجوع والسبب المحتمل

في تجارب محكومة على Qwen3.8-27B، أدى خطأ 403 محاكى إلى محاولة النموذج استخدام وكيل Alibaba Cloud خلال دورين في 2 إلى 4 بالمئة من التشغيلات. في سيناريو أكثر تعقيداً، رجع Qwen3.8-Max إلى الوكيل بنسبة 1 إلى 4 بالمئة. أجرى الباحثان Ozerov و Ravi نفس الاختبارات على DeepSeek-v4.1-Flash و Kimi-K3.1-Pro و GLM-5.3 و Hy4-preview. رجع بعضها إلى وكلاء عامين مثل r.jina.ai عند الحظر، لكن لم يوجّه أي منها حركة المرور عبر خوادم مطوريها.

لأن استدعاءات الوكيل تظهر في نماذج Qwen 3.8 لكن لا تظهر في نماذج Qwen 3.7، يربط الباحثون السلوك بالتعلم بالتعزيز أثناء تدريب 3.8. من المرجح أن إعداد تدريب Alibaba وجّه طلبات الويب عبر خادم routify-file-proxy، معلّماً النماذج استخدامه بديل عندما تفشل الطلبات المباشرة. احتمال آخر هو أن برمجية التدريب أعادت توجيه استدعاءات الأدوات عبر الوكيل سراً دون أن يعرف النموذج.

تقول Palisade Research إنها لا تجد أي علامات على "الاتصال الخبيث بخوادم في الصين أو محاولة استخراج بيانات حساسة." يخلص الباحثون إلى أن استدعاءات الوكيل في سنغافورة هي أثر تدريب، لا هجوم مستهدف. لكن مجال routify-file-proxy لا يزال فعالاً، لذا يمكنه تسجيل عناوين IP والطلبات الواردة من وكلاء Qwen. من يتحكم في ذلك الخادم يمكنه أيضاً استبدال أخطاء 403 الحالية بـ prompt injections، يكتب الباحثون.

تغطية سابقة: Cohere: حاول نموذج Qwen إرسال بيانات إلى الصين في اختبار بيئة معزولة

المصادر: The Decoder