نشرت GitHub GHSA-48jh-3gj7-fg8v عند 21:37:00 بالتوقيت العالمي المنسق في 4 سبتمبر — CVE-2026-73556، بدرجة CVSS تبلغ 5.3، ضد vLLM، أكثر خوادم الاستدلال مفتوحة المصدر انتشارًا. ويُقرأ في الإشعارات على أنه خلل جديد يسبب حجب الخدمة. لكنه الخلل نفسه الذي أصلحه المشروع في يوليو، والذي بقي قائمًا في مسار الشفرة الذي لم يمسه الإصلاح.
المسار الشقيق
التنبيه واضح: "الإصلاح لـ GHSA-rwxx-mrjm-wc2m … لفّ ترجمة regex في واجهتي xgrammar وoutlines باستخدام compile_regex_with_timeout (و، في outlines، validate_regex_is_buildable). أما واجهة lm-format-enforcer فتركت دون حماية: إذ تُترجم regex التي يزوّدها المهاجم من دون مهلة زمنية ومن دون فحص قابلية البناء." وتصل الواجهات الثلاث جميعها إلى بناء DFA نفسه عبر interegular؛ اثنتان منهما مقيدتان وواحدة ليست كذلك.
القياس
ينشر التنبيه توقيتاته الخاصة: الأساس '[0-9]{3}' يُترجم في 0.0002 ثانية؛ بينما '(a{1,300}){300}' الخاصة بالمهاجم لم تكتمل خلال 20 ثانية، مع "ثبات نواة واحدة عند 100% في بناء FSM ضمن interegular". وبما أن ترجمة القواعد تعمل داخل مسار المخرجات المهيكلة في المحرك، فإن الطلب لا يعود أبدًا وتتوقف الطلبات المتزامنة خلفه — وهو حجب خدمة على مستوى العامل. ويذكر التنبيه أن الطلب نفسه ضد واجهة outlines يعود بخطأ سليم.
ما يخطئ فيه التأطير المتداول
أمران. هذا فشل في اكتمال التصحيح، وليس فئة هجوم جديدة — فالمثير هنا أن إصلاحًا أمنيًا وصل إلى مساري استدعاء من ثلاثة ولم يلاحظ ذلك أحد لمدة ستة أسابيع. وعبارة "الإصدارات المتأثرة < 0.26.0" تبدو كأنها تعرض حالي: فقد شُحن 0.26.0 في 27 يوليو، والإصدار الحالي هو 0.28.0، لذا يأتي الإفصاح بعد الإصلاح بـ 39 يومًا. من كان يتابع إصدار vLLM لديه لم يكن معرضًا بعد يوليو؛ أما من ثبّته دون ذلك فقد ظل، من دون علمه، معرضًا منذ ذلك الحين.
الشرط المسبق الذي لا يعدو أن يكون شرطًا كبيرًا
يسجل التنبيه أن "vLLM يُشحن من دون مصادقة افتراضيًا". ويكفي لتنفيذ الهجوم طلب POST واحد إلى /v1/completions مع regex للمخرجات المهيكلة — من دون بيانات اعتماد، ومن دون وصول إلى النموذج يتجاوز نقطة النهاية، ومن دون إعداد خاص سوى اختيار واجهة lm-format-enforcer. والمخرجات المهيكلة هي الميزة التي تفعّلها غالبية النشرات الإنتاجية، لأنها الطريقة التي تجعل استجابات JSON موثوقة.