الثغرة الأمنية CVE-2025-62164 هي ثغرة أمنية شديدة الخطورة في vLLMوهو أحد أكثر محركات الاستدلال LLM مفتوحة المصدر مفتوحة المصدر انتشارًا. يعيش الإصدار داخل واجهة برمجة تطبيقات الإكمال ويتم تشغيله عندما يقوم الخادم بمعالجة عمليات التضمين الفوري التي يوفرها المستخدم. في الإصدارات المتأثرة (0.10.2 حتى 0.10.2 حتى 0.11.1 ولكن لا يشمل 0.11.1)، تقوم vLLM بإلغاء تسلسل الموتر باستخدام الشعلة.تحميل() بدون تحقق قوي. يمكن أن ينزلق موتر متناثر مصنوع بحرفية ويسبب الكتابة خارج الحدود أثناء التكثيفالذي يعطل العامل بشكل موثوق ويمكن تصعيده إلى تنفيذ التعليمات البرمجية عن بُعد في الظروف المناسبة. قام المشروع بشحن إصلاح في vLLM 0.11.1. (NVD)

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

أين يقع vLLM في المكدس - ولماذا يضاعف هذا الموضع من المخاطر

vLLM هي طبقة استدلال محسنة للإنتاجية بشكل فعال. تقوم الفرق بنشرها كواجهة برمجة تطبيقات SaaS عامة، أو خلف بوابة مؤسسة، أو كواجهة خلفية لخدمة أنظمة الوكلاء متعددي المستأجرين. في جميع هذه التخطيطات، تكون vLLM قريبة من الإنترنت وقريبة من موارد وحدة معالجة الرسومات. يبدو ذلك مثل هندسة الأداء؛ وهذا يعني أيضًا قد يصل مستدعو واجهة برمجة التطبيقات منخفضة الامتيازات إلى مسارات التعليمات البرمجية المميزة. (ويز.io)

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

الضعف في فقرة واحدة

تتيح نقطة نهاية الإكمال في إصدارات vLLM الضعيفة للعملاء تمرير التضمينات الفورية بدلًا من النص الخام. يعيد vLLM بناء هذه الموتر عبر الشعلة.تحميل() دون إجراء فحوصات سلامة أو نوع أو هيكلية كافية. ومنذ ذلك الحين يقوم PyTorch 2.8.0 بتعطيل عمليات التحقق من تكامل الموتر المتناثر افتراضيًا، يمكن لموتر متناثر خبيث أن يتجاوز حماية الحدود الداخلية ويؤدي إلى حدوث كتابة الذاكرة خارج الحدود عند to_dense() يسمى. النتيجة الفورية القابلة للتكرار هي هجمات الاختراق عن بُعد (تعطل العامل). مع التخطيط والتحكم المناسبين للذاكرة، يمكن تحويل نفس البدائية بشكل معقول إلى RCE على المضيف. (NVD)

تشريح السبب الجذري: كيف تحول "التضمين المريح للتمرير" إلى فساد في الذاكرة

مغسلة إلغاء التحويل على نقطة نهاية عامة

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

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

كان تغيير السلوك PyTorch 2.8.0 PyTorch 2.8.0 الشرارة

يعلق كل من إرشادات vLLM و NVD التصعيد على تغيير PyTorch: يتم الآن إيقاف عمليات التحقق من سلامة الموتر المتناثر افتراضيًا. في السابق، كان من المرجح أن يتم رفض الموتر المتناثر المشوه قبل أن يصل مسار التعليمات البرمجية إلى التكثيف. مع تعطيل عمليات التحقق، أصبح افتقار vLLM للتحقق المسبق من الصحة قابلًا للاستغلال بطريقة متسقة. (NVD)

هذا نموذج ذهني مفيد لأمن الذكاء الاصطناعي المعلوماتي: يمكن للافتراضات في المنبع أن تحول بصمت "غير آمن ولكن خامل" إلى "غير آمن وقابل للتسلح".

التحقق من الواقع المؤثر: DoS مضمون، و RCE هو السقف المضمون

تتفق جميع الكتابات العامة على أن يمكن الاعتماد على DoS عن بُعد. يمكن أن يؤدي طلب واحد خاطئ إلى قتل عامل؛ ويمكن أن تؤدي الطلبات المتكررة إلى إبقاء الأسطول غير مستقر. (المسار صفر)

يوصف RCE بأنه الإمكانات لسبب وجيه. يوفر تلف الذاكرة مسارًا، لكن التسليح يعتمد على سلوك المخصص، وعلامات التقوية، وحدود الحاوية، ومدى سيطرة المهاجم على المنطقة التالفة. هناك لا توجد قائمة CISA KEV ولا توجد سلسلة من الثغرات المؤكدة على نطاق واسع في سلسلة الثغرات حتى 25 نوفمبر 2025، ولكن التعامل مع تلف ذاكرة مستوى البيانات على أنه "DoS فقط" سيكون خطأً. (ويز.io)

الإصدارات المتأثرة وحالة الإصلاح

(NVD)

من يجب أن يفزع أولاً: نماذج التهديد المهمة

إذا كنت تريد عدسة عملية لتحديد الأولويات، ففكر في المكان الذي يمكن أن تدخل فيه التضمينات إلى نظامك.

نقاط نهاية vLLM العامة هي الحالة الواضحة عالية الخطورة. حتى لو احتاج المتصلون إلى مفتاح واجهة برمجة التطبيقات، فإن الشريط منخفض: قد يكون المستخدم العادي الذي لديه وصول أساسي كافٍ لتعطيل عمالك. (ويز.io)

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

أخيرًا، لا تستبعد العروض التوضيحية المجتمعية وعمليات النشر التعليمية. فهي غالباً ما تكون غير مصادق عليها وغير خاضعة للمراقبة بشكل كافٍ ومكشوفة بعد فترة طويلة من نسيان مالكها لوجودها.

الطرق الآمنة لتأكيد التعرض (بدون استقصاء محفوف بالمخاطر)

أسرع فرز يعتمد على الإصدار.

python -c "استيراد vllm؛ طباعة (vllm.__version____)"
يتأثر # إذا كان 0.10.2 <= الإصدار <0.11.1

(NVD)

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

يعد فحص الكناري غير الضار - عمليات الإكمال القياسية، وعدم تضمين التمرير - مفيدًا للاستقرار الأساسي حول الترقيع:

استيراد الطلبات، json، الوقت

المضيف = "https://<y00/v1/completions"
الرؤوس = {"تخويل": "Bearer "}

الحمولة = {{
    "النموذج": "اسم النموذج الخاص بك",
    "موجه": "فحص الصحة",
    "max_tokens": 4
}

بالنسبة إلى i في النطاق (5):
    r = طلبات.post(HOST, headers=headers, data=json.dumps(payload), timeout=10, verify=False)
    طباعة(i, r.status_code, r.text[:160])
    الوقت.sleep(1)

التصحيح السريع، ثم تقوية مستوى البيانات

الإصلاح الحقيقي هو ببساطة الترقية إلى vLLM 0.11.1 أو أحدث. كل شيء آخر هو بديل مؤقت. (NVD)

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

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

ما أهمية CVE-2025-62164 بالنسبة لأمن الذكاء الاصطناعي باعتباره تخصصًا

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

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

إنه أيضًا تذكير بأن سطح المخاطر في مجموعة LLM التركيبvLLLM لم "يخترع" انعدام أمن الموتر المتناثر؛ فقد تغيرت افتراضية PyTorch، وحوّلت طبقة التحقق المفقودة في اتجاه مجرى النهر هذا التغيير إلى مكافحة التطرف العنيف. تحتاج هندسة الاستدلال الآن إلى نفس المستوى من التدقيق في التبعية الذي تتخذه فرق النواة كأمر مسلم به.

التحقق من الصحة المنضبط عندما تكون برامج العمل فوضوية أو متأخرة

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

في تدفقات العمل الوكيلة على غرار بنليجنت، يمكنك أن تجعل الوكلاء يستوعبون سجل استشارات vLLM وسجل NVD، واستخلاص شروط التعرض الدقيقة (الإصدارات، ومسار التضمينات، وافتراضات PyTorch)، وإنشاء خطة التحقق من الحد الأدنى من المخاطر التي تقوم بتشغيلها فقط في نسخة متماثلة معزولة. وهذا يمنحك دليلاً حقيقياً - بصمات الإصدار، وتوقيعات الأعطال، ودلتا ما قبل/بعد التصحيح - دون أن تقامر بوحدات معالجة الرسومات الخاصة بك. (NVD)

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