ثغرة LiteLLM CVE-2026-42271: سلسلة هجوم على بوابة الذكاء الاصطناعي تصل لدرجة خطورة قصوى 10.0

• POST /mcp-rest/test/connection

• POST /mcp-rest/test/tools/list

تقبل كلا النقطتين إعدادات كاملة لخادم MCP في متن طلب JSON، بما في ذلك حقول Cmd و args و env التي يستخدمها نقل stdio لتشغيل عمليات الخادم . عندما يستدعي مستخدم مُصادق عليه أيًا من نقطتي النهاية بهذه الإعدادات، يقوم LiteLLM بأخذ قيمة Cmd المُعطاة وتشغيلها كعملية فرعية (subprocess) على الجهاز المضيف، مع العمل بنفس صلاحيات نظام التشغيل التي تعمل بها عملية وسيط LiteLLM نفسه .

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

ثغرة تجاوز "BadHost" في Starlette التي تزيل شرط المصادقة

الثغرة الثانية هي CVE-2026-48710، والتي أطلق عليها الباحثون اسم "BadHost". هذه الثغرة هي خلل في التحقق من صحة رأس المُضيف (Host Header) في Starlette، وهو إطار ASGI خفيف الوزن يدعم أطر عمل مثل FastAPI و vLLM وآلاف تطبيقات الويب الأخرى بلغة بايثون - بما في ذلك LiteLLM . جميع إصدارات Starlette من 0.8.3 إلى 1.0.0 متأثرة .

يكمن السبب الجذري في اختلاف في تفسير المسار بين كيفية توجيه Starlette للطلبات الواردة وكيفية إعادة بناء عنوان URL لمنطق التطبيق . تستخدم طبقة توجيه ASGI مسار HTTP الخام (Raw HTTP Path) من الطلب لتحديد أي نقطة نهاية ستتعامل معه. لكن request.url - وهو عنوان URL الذي تراه برمجيات الوسيطة (middleware) والمزخرفات (decorators) في التطبيق - يتم إعادة بنائه عن طريق ربط قيمة رأس Host الخام مع مسار الطلب، دون أي تحقق مناسب من الصحة .

من خلال حقن رموز فاصلة بين صلاحية URI والمسار (مثل ? أو #) في رأس Host، يمكن للمهاجم جعل request.url.path يظهر بشكل مختلف تماماً عن المسار المُوجه إليه فعلياً . ترى برمجية المصادقة الوسيطة مساراً آمناً مثل /، بينما يقوم الموجه بتوجيه الطلب إلى نقطة النهاية المستهدفة الحقيقية خلف الكواليس. أي برمجية وسيطة للمصادقة تعتمد على المسار وتثق في request.url.path يمكن تجاوزها بسهولة .

تجميع السلسلة معاً: من 8.7 إلى 10.0

يقوم مزخرف المصادقة في LiteLLM بالتحقق من request.url.path لتحديد ما إذا كان الطلب يحتاج إلى مفتاح API ساري. يتيح تجاوز BadHost للمهاجم التلاعب بعنوان URL هذا بحيث ترى برمجية المصادقة الوسيطة مساراً لا يتطلب مصادقة، بينما يقوم موجه ASGI في نفس الوقت بإرسال الطلب إلى إحدى نقطتي نهاية حقن الأوامر الضعيفتين .

هذا يزيل البوابة الوحيدة للتحكم في الوصول التي كانت تقف بين الإنترنت وتنفيذ الأوامر العشوائي. يمكن لمهاجم لا يمتلك أي بيانات اعتماد ولا أي وصول مسبق إلى الشبكة أن يرسل طلب HTTP واحد مُصمم خصيصًا يتجاوز المصادقة بالكامل ويقوم بتشغيل أوامر نظام التشغيل على الجهاز المضيف لوسيط LiteLLM . أكدت Horizon3.ai أن السلسلة الكاملة تعمل وأسندت لها درجة CVSS مجمعة تبلغ 10.0 - أقصى درجة خطورة - لأنها تحقق تنفيذ أوامر عن بُعد بدون مصادقة .

ما يمكن أن يفعله المهاجمون بهذا الوصول

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

• تنفيذ أوامر عشوائي: يمكن للمهاجمين تثبيت أبواب خلفية، برمجيات خبيثة، أدوات تعدين عملات رقمية، أو أي برنامج آخر تسمح به صلاحيات العملية المضيفة .
• سرقة بيانات الاعتماد على نطاق واسع: يعمل وسيط LiteLLM كوسيط بين التطبيقات والعشرات من مزودي نماذج اللغة الضخمة. إنه يخزن مفاتيح API لـ OpenAI و Anthropic و Azure و AWS Bedrock و Google وغيرها من الخدمات المتصلة في قاعدة بياناته أو متغيرات البيئة . استغلال هذه الثغرة يتيح للمهاجمين سرقة كل بيانات الاعتماد المخزنة في عملية واحدة.
• التحرك الجانبي عبر البنية التحتية للذكاء الاصطناعي: باستخدام مفاتيح API السحابية المسروقة ووصول الـ Shell إلى الجهاز المضيف للوسيط، يمكن للمهاجمين الانتقال إلى الخدمات المتصلة، خوادم MCP الداخلية، قواعد بيانات المتجهات، وأطر عمل الوكلاء (Agent Frameworks) .
• تأثيرات على منظومة أوسع: يؤثر خلل BadHost في Starlette على أكثر من 400,000 مشروع يعتمد عليه، بما في ذلك تطبيقات FastAPI، خوادم vLLM، توزيعات خوادم MCP، وأطر عمل وكلاء الذكاء الاصطناعي. أي من هذه المشاريع التي تستخدم برمجيات وسيطة للمصادقة تعتمد على المسار في إصدارات Starlette قبل 1.0.1 معرضة بشكل مماثل لتجاوز المصادقة .

لماذا تزيد خطوة وكالة CISA من الإلحاح

إضافة CISA للثغرة CVE-2026-42271 إلى كتالوج الثغرات المستغلة والمعروفة (KEV) في 8 يونيو 2026 تؤكد أن الثغرة ليست نظرية - المهاجمون يقومون بتسليحها بشكل نشط الآن . بموجب التوجيه التشغيلي الملزم BOD 22-01، يجب على جميع الوكالات الفيدرالية التنفيذية المدنية الأمريكية تصحيح الثغرات المدرجة في كتالوج KEV ضمن إطار زمني محدد. كما توصي CISA بشدة جميع المؤسسات، العامة والخاصة، بالتعامل مع إضافات كتالوج KEV كأولويات تصحيح طارئة .

خطوات المعالجة الفورية

يتطلب إصلاح الاستغلال المتسلسل تحديثات على جبهتين، بالإضافة إلى العديد من إجراءات الدفاع المتعمق لمعالجة تعرض بيانات الاعتماد:

1. ترقية LiteLLM إلى الإصدار 1.83.7 أو أحدث. يزيل هذا الإصدار قدرة نقاط نهاية اختبار MCP على تنفيذ الأوامر المقدمة من المستخدم مباشرة، مما يغلق باب حقن الأوامر بالكامل .
2. ترقية Starlette إلى الإصدار 1.0.1 أو أحدث. يتحقق التصحيح من صحة رؤوس Host الواردة مقابل مواصفات URL ويتجاهل الرؤوس التي تحتوي على رموز غير صالحة، مما يمنع خدعة إرباك المسار التي تدعم تجاوز المصادقة .
3. تدوير كل بيانات الاعتماد المخزنة فوراً. افترض أن أي مفتاح API، رمز وصول، أو بيانات اعتماد قاعدة بيانات قد خزنها وسيط LiteLLM قد تم اختراقها. قم بتدوير جميع مفاتيح OpenAI و Anthropic و Azure و AWS ومزودين آخرين، وتحقق من لوحات بيانات الفوترة بحثًا عن أي استخدام غير مصرح به .
4. حظر نقطتي النهاية على مستوى الوكيل العكسي أو جدار حماية تطبيقات الويب (WAF). كإجراء دفاع متعمق أثناء تطبيق التصحيحات، قم بضبط الوكيل العكسي أو جدار حماية تطبيقات الويب لديك لإسقاط أي طلب إلى

   POST /mcp-rest/test/connection

   و

   POST /mcp-rest/test/tools/list

   قبل أن يصل إلى التطبيق .
5. التدقيق في الوصول غير المصرح به بأثر رجعي. افحص سجلات وسيط LiteLLM بحثاً عن أي نشاط غير عادي على نقطتي نهاية اختبار MCP، خاصة الطلبات القادمة من عناوين IP غير متوقعة أو تلك التي تحتوي على رؤوس Host تم التلاعب بها .

تعني خطورة CVSS المجمعة البالغة 10.0، والاستغلال النشط على أرض الواقع، وتصنيف CISA في كتالوج KEV، أن المؤسسات التي تشغل خدمات LiteLLM أو خدمات مدعومة من Starlette يجب أن تتعامل مع هذا كحدث طارئ للتحديث والتدوير. نافذة الفرصة بين الاستغلال النشط وسرقة بيانات الاعتماد مفتوحة بالفعل.