vLLM وtrust-remote-code: تثبيت الإصدار ومفتاح API ومراجعة الكود لم تمنع طلبًا واحدًا

إذا كنت تشغّل vLLM على خادمك وتقدّم نموذجًا متعدد الوسائط مع تفعيل --trust-remote-code، فمن المرجح أنك تعتمد على ثلاث وسائل حماية. راجعت كود المعالج (processor) قبل تفعيل الخيار. وثبّتَّ إصدار النموذج (revision) حتى لا يتغير الكود دون علمك. وضبطت --api-key بحيث لا يرسل الطلبات إلا من سمحت لهم بذلك. يصف تنبيه أمني جديد من مشروع vLLM حالة يمكن فيها، ضمن إعداد معيّن مع تفعيل --trust-remote-code، لطلب واحد إلى المسار /tokenize أن يحدد كود Python الذي سيُنفَّذ على الخادم. هذا المسار غير محمي بمفتاح API.

ما نقوله هو أن كل وسيلة من هذه الوسائل تُطبَّق داخل التطبيق، بحسب حقل أو مسار، وقد استندت إلى افتراض لم يصمد أمام الاختبار. والخطوة العملية هي التحديث، مع تحديد من يمكنه الوصول إلى خادم الاستدلال والوجهات التي يمكن للخادم الاتصال بها، على مستوى المضيف. هذان القراران لا يعتمدان على طريقة تفسير vLLM للطلب.

ما الذي نُشر

في 6 أكتوبر 2026، نُشر التنبيه الأمني GHSA-h3rc-6mm3-gc2m. وفقًا للتنبيه، يمكن لطلب متعدد الوسائط تحديد قيمة code_revision داخل الحقل mm_processor_kwargs. عندما يكون معالج النموذج في Hugging Face معرّفًا بوصفه كودًا ديناميكيًا (auto_map)، ويكون المشغّل قد فعّل --trust-remote-code، تُمرَّر هذه القيمة إلى AutoProcessor.from_pretrained في Transformers. وهي تحدد إصدار المستودع الذي سيُستورد منه كود المعالج. واستيراد وحدة Python يعني تنفيذ كود عشوائي داخل عملية API/renderer في vLLM.

أبرز ما ورد في التنبيه:

• الإصدارات: من 0.7.3 إلى ما قبل 0.31.0. أُدرج الإصلاح في 0.31.0 ودُمج ضمن طلب السحب رقم 58830. يذكر التنبيه أن الثغرة جرى التحقق منها على commit معيّن مع Transformers 5.15.0 و5.16.1، وأن نطاق الإصدارات المتأثرة لم يُتحقق منه باستخدام البحث الثنائي (bisect).
• الشروط: معالج ديناميكي عبر auto_map؛ تفعيل trust_remote_code؛ قدرة الخادم على تنزيل الإصدار المحدد في الطلب، أو وجوده مسبقًا في ذاكرة التخزين المؤقت؛ قدرة المهاجم على إنشاء إصدار في مستودع النموذج المقدَّم أو التحكم فيه — ويذكر التنبيه مرجعًا (ref) لطلب سحب من المجتمع في Hugging Face مثالًا على ذلك، حين يسمح المستودع به؛ ووصول طلب متعدد الوسائط إلى مسار معالجة المعالج. في الإعداد الافتراضي، trust_remote_code=False، لا يتأثر الخادم.
• المصادقة: وفقًا للتنبيه، لا يحمي مكوّن المصادقة في vLLM إلا المسارات التي تبدأ بـ/v1 و/v2 و/inference و/cohere. ويُقبل الحقل أيضًا في طلب tokenize للمحادثة، لذا يبقى /tokenize مفتوحًا حتى مع ضبط --api-key، ما لم يحمِه وكيل خارجي.
• الخطورة: اقترح مُبلّغ الثغرة درجة 9.8، لكن التصنيف المنشور هو High، بدرجة CVSS تبلغ 8.1 وتعقيد هجوم مرتفع. لا يوجد معرّف CVE. والتصنيف هو CWE-94 وCWE-829.
• العرض التجريبي: وفقًا للتنبيه، أُجري العرض دون اتصال بالشبكة، ودون GPU، ودون أوزان نموذج، ودون تعديل مستودع حقيقي. لا يصف التنبيه استغلالًا فعليًا.

يصف ملخص التغطية في LinuxSecurity التحديث بأنه يتضمن إصلاحات حرجة. لكن التصنيف المنشور في التنبيه نفسه هو High.

تثبيت الإصدار يثبّت البيانات، لا الكود

من يثبّت revision يفترض أنه يثبّت كل ما يأتي مع النموذج. وفقًا للتنبيه، ثبّت vLLM بالفعل revision وtrust_remote_code، لكنه مرّر بقية الإعدادات الواردة في الطلب دون حماية code_revision. تستخدم Transformers هذه القيمة لاختيار الكود، ثم تزيلها قبل تحميل بيانات المعالج. والنتيجة، كما يصفها التنبيه: يأتي الكود من الإصدار الذي يتحكم فيه المهاجم، بينما تبقى الإعدادات والبيانات على الإصدار الذي ثبّته المشغّل. إذا راجعت الكود قبل تفعيل الخيار، فقد راجعت إصدارًا واحدًا. في هذه الثغرة، نُفّذ إصدار آخر.

لذلك، ليس --trust-remote-code مجرد إعداد تقني تفعّله لكي يعمل النموذج. تفعيله قرار بتشغيل كود من مصدر خارجي. والسؤال الحاسم هو: من يختار الكود؟ في الإصدار المتأثر بالثغرة، كان الطلب هو الذي يحدده.

مفتاح API يحمي بادئات المسارات، لا الخادم

من السهل افتراض أن ضبط --api-key يمنع من لا يملك مفتاحًا من الوصول إلى الخادم. وفقًا للتنبيه، تُحدَّد الحماية بحسب بادئات المسارات، و/tokenize ليس ضمنها. ويذكره دليل أمان vLLM أيضًا بوصفه مسارًا غير محمي. لذلك، إذا كان خادم vLLM متاحًا عبر الشبكة، فلا يكفي السؤال عما إذا كنت قد ضبطت مفتاحًا. يجب فحص المسارات المتاحة دون مفتاح، وما الذي يعالجه كل منها.

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

القدرة على التنزيل جزء من الهجوم

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

ينبغي أيضًا فحص الشرط المتعلق بالمستودع. وفقًا للتنبيه، يُعد مرجع (ref) لطلب سحب من المجتمع مثالًا على إصدار يمكن للمهاجم التحكم فيه، داخل مستودع يسمح بذلك. بهذا المعنى، فإن المستودع العام المفتوح للمساهمات مصدر كود لا يخضع لسيطرتك الكاملة.

القاسم المشترك

في الحالات الثلاث، طُبّقت الحماية عند النقطة التي يفسر فيها التطبيق المدخلات: حقل واحد لم يُحمَ، ومسار واحد لم يُشمل. تعتمد هذه الحماية على أن يكون المطوّر قد أخذ كل حقل وكل مسار في الحسبان. في المقابل، يظل سؤالان على مستوى المضيف كما هما، حتى عند اكتشاف حقل جديد: من يمكنه الوصول إلى منفذ خادم الاستدلال، وإلى أي وجهات يمكن لعمليته الاتصال؟ وفقًا للتنبيه، يُنفَّذ الكود داخل عملية API/renderer ويؤثر في السرية والسلامة والتوافر.

ما الذي تفعله على الخادم

1. حدّث إلى 0.31.0. تحقّق من الإصدار في العملية التي تستقبل الطلبات فعليًا، لا من وسم صورة الحاوية التي نزّلتها فقط. الحاوية التي تعمل بالفعل لا تتحدث من تلقاء نفسها.
2. تحقّق من حاجتك إلى --trust-remote-code. إذا كان النموذج لا يتطلبه، فعطّله. وإذا كان يتطلبه، فتحقّق مما إذا كان معالجه معرّفًا بوصفه كودًا ديناميكيًا عبر auto_map.
3. افحص مستودع النموذج المقدَّم. هل يسمح بطلبات سحب من المجتمع؟ ومن يستطيع إنشاء إصدارات فيه؟
4. قيّد الوصول إلى خادم الاستدلال عبر الشبكة. لا تجعل vLLM متاحًا مباشرة على الإنترنت. اسمح بالوصول فقط للخدمات التي تحتاج إليه. إذا كان أمامه وكيل، فتأكد من أنه يطلب المصادقة على /tokenize أيضًا. تحقّق من ذلك بإرسال طلب منفصل إلى هذا المسار.
5. احصر حركة الاتصالات الصادرة من خادم الاستدلال. افحص الوجهات التي يتصل بها أثناء التشغيل، واقصر الوصول على الوجهات التي يحتاج إليها فعلًا.
6. تحقّق مما يعمل أيضًا. من السهل إغفال خادم نماذج أُنشئ للاختبار ثم تُرك يعمل بإصدار قديم، مع بقاء الخيار مفعّلًا.

كيف يساعد nuDefend

معرفة ما يعمل. يعرض الأمر nudefend workloads أدوات الذكاء الاصطناعي التي تعمل على الخادم، بما فيها خوادم النماذج، سواء كانت تعمل مباشرة على المضيف أم داخل حاوية. وتظهر بجانب كل أداة المعلومات التي استند إليها التعرف عليها، مثل وحدة systemd أو اسم صورة الحاوية أو نمط في سطر الأوامر. وبذلك يمكن أيضًا العثور على خادم نماذج أُنشئ للاختبار ثم نُسي.

معرفة من يستطيع الوصول إليه. يعرض الأمر nudefend expose كل خدمة تستمع على الخادم ومن يستطيع الوصول إليها، من منظور الخادم نفسه. ويشمل العرض الخدمات المنشورة من داخل حاوية. إذا أصبحت خدمة كانت داخلية فقط متاحة من الخارج، يرصد nuDefend التغيير وينبّه إليه. وإذا كان خادم الاستدلال متاحًا على خلاف ما قصدت، فيمكن حظر منفذه من لوحة التحكم أو سطر الأوامر. قبل الحظر، تظهر معاينة توضّح بدقة ما سيُحظر. يُسجَّل كل حظر، ويمكن التراجع عنه بنقرة. التفاصيل في صفحة إتاحة الخدمات.

التحكم في الوجهات التي يتصل بها. يسجّل nuDefend الوجهات التي تتصل بها كل أداة ذكاء اصطناعي على الخادم، وحجم حركة البيانات إلى كل وجهة، ووقت رصد الوجهة لأول مرة. عندما يُتعرَّف على الوجهة، يظهر اسمها ونوع نشاطها، مثل مصدر لتنزيل البرامج والنماذج. بناءً على هذه المعلومات، يمكنك قصر اتصالات أداة تختارها على الوجهات التي وافقت عليها. تُحظر كل محاولة للاتصال بوجهة أخرى قبل خروج حركة البيانات من الخادم، ويستمر باقي الخادم في العمل كالمعتاد. يقيّد nuDefend أيضًا العناوين التي يُسمح للأداة بالاستعلام عنها، ويُعرض كل استعلام جرى إيقافه بجانب اسم الأداة. التفاصيل في صفحة حركة الاتصالات الصادرة.

طبقة أساسية. تُحظر حركة البيانات المتجهة إلى عناوين IP ونطاقات معروفة بأنها خبيثة، وكذلك حركة البيانات الواردة منها، في جدار الحماية داخل النواة. يستند الحظر إلى قوائم تهديدات موقّعة تُحدَّث كل 30 دقيقة. تعرض لوحة التحكم عدّادًا لحركة البيانات الصادرة التي حُظرت. وقد تكون أي قيمة أعلى من الصفر إنذارًا مبكرًا بأن شيئًا على الخادم حاول الاتصال بمصدر خبيث.

الخلاصة

تُظهر ثغرة vLLM أن ثلاث وسائل حماية معقولة — تثبيت الإصدار ومفتاح API ومراجعة الكود — طُبّقت جميعها داخل التطبيق، وجرت مجاوزتها بحقل واحد ومسار واحد. حدّث إلى 0.31.0 وعطّل --trust-remote-code إذا لم تكن تحتاج إليه. وإلى جانب التحديث، حدّد على مستوى المضيف من يستطيع الوصول إلى خادم الاستدلال، والوجهات التي يمكن للخادم الاتصال بها. تظل هذه القرارات نافذة حتى عند اكتشاف الحقل التالي.