ثغرة LiteLLM الحرجة: سيطرة كاملة على خوادم بوابات الذكاء الاصطناعي

مقدمة تحليلية

كشف باحثون من Obsidian Security عن سلسلة من ثلاث ثغرات حرجة (CVSS 9.9) في بوابة الذكاء الاصطناعي مفتوحة المصدر LiteLLM، تسمح لمستخدمين بصلاحيات منخفضة جداً بالارتقاء إلى مستوى المسؤول الكامل وتنفيذ تعليمات برمجية عن بعد (RCE) على خوادم بوابات الذكاء الاصطناعي. تُعد LiteLLM حلًا واسع الانتشار، حيث تعمل كوسيط للمكالمات إلى أكثر من 100 مزود نموذج خلف واجهة متوافقة مع OpenAI. تعني السيطرة الكاملة على الخادم الكشف عن جميع مفاتيح المزود، والأسرار التي تُستخدم لفك تشفير بيانات الاعتماد المخزنة، وكل المطالبات والاستجابات التي تمر عبر البوابة.

تكمن الخطورة الفورية في أن أي اختراق لهذه البوابة لا يهدد فقط ببيانات اعتماد حساسة لمزودي الذكاء الاصطناعي مثل OpenAI وAnthropic وGemini وAzure، بل يهدد أيضاً بمسح كل البيانات الحساسة – بما في ذلك معلومات التعريف الشخصية (PII) والتعليمات البرمجية المصدر وتذاكر العمل الداخلية والأسرار المُلصقة – التي تمر عبرها. تم تضمين مجموعة الإصلاحات الكاملة لهذه الثغرات في الإصدار LiteLLM v1.83.14-stable الذي صدر بتاريخ 2 مايو، مما يجعل الترقية الفورية ضرورية لجميع المستخدمين.

التحليل التقني

تتكون سلسلة الهجوم من ثلاث ثغرات رئيسية تُمكن المهاجم من الانتقال من مستخدم داخلي (internal_user) إلى مسؤول خادم كامل (proxy_admin) وصولًا إلى تنفيذ التعليمات البرمجية عن بعد:

• CVE-2026-47101: تجاوز تفويض (Authorization Bypass)

  عندما يقوم مستخدم عادي بإنشاء مفتاح API افتراضي، يقوم LiteLLM بتخزين حقل allowed_routes الذي يوفره المتصل دون التحقق منه مقابل دور المستخدم. من المفترض أن يحدد هذا الحقل صلاحيات المفتاح، ولكنه بدلاً من ذلك يُعامل كمنحة احتياطية. يمكن لمستخدم غير مسؤول صياغة مفتاح بـ allowed_routes: ["/*"]، وهي علامة شاملة تتيح الوصول إلى جميع المسارات، بما في ذلك تلك المخصصة للمسؤولين فقط. تظهر هذه الكتابة غير المتحقق منها في نقاط نهاية إدارة المفاتيح الأخرى، مما استدعى ثلاث طلبات سحب لإصلاحها.

• CVE-2026-47102: تصعيد امتيازات (Privilege Escalation)

  بمجرد تجاوز بوابة المسارات، تصبح المعالجات خلفها قابلة للوصول. تفترض العديد من هذه المعالجات أن البوابة قد قامت بالفحص المسبق. يسمح نقطة النهاية /user/update للمستخدم بتعديل سجله الخاص، ولكنها لا تقيد الحقول التي يمكنه كتابتها. تُقبل وتُحفظ عملية التحديث الذاتي التي تحتوي على user_role: "proxy_admin"، مما يُرقّي المتصل إلى مسؤول وكيل كامل. بينما يمكن لمسؤول التنظيم (org_admin) الوصول إلى هذه النقطة بشكل مشروع، يمكن للمستخدم العادي (internal_user) الوصول إليها بعد استغلال CVE-2026-47101. صنف VulnCheck هذه الثغرة بـ 8.7 تحت CVSS 4.0 و 8.8 تحت 3.1.

• CVE-2026-40217: تجاوز صندوق الحماية (Sandbox Escape) وتنفيذ التعليمات البرمجية عن بعد (RCE)

  توجد هذه الثغرة في Custom Code Guardrail، الذي يقوم بتجميع وتشغيل تعليمات Python البرمجية التي يوردها المسؤول. تعمل نقاط النهاية في بيئة الإنتاج على تشغيل التعليمات البرمجية عبر exec() دون تصفية على مستوى المصدر. عندما تتلقى exec() قاموساً عاماً (globals dict) بدون __builtins__، يقوم Python تلقائياً بإدخال وحدة builtins الكاملة، مما يمنح التعليمات البرمجية الوصول إلى __import__ و open و eval. كان مجرد حمولة بسيطة تستدعي os.system كافية للحصول على غلاف عكسي (reverse shell). مسار منفصل على نقطة النهاية /guardrails/test_custom_code، اكتشفه X41 D-Sec بشكل مستقل، قام بتجاوز قائمة رفض (deny-list) باستخدام التعبيرات النمطية عن طريق إعادة كتابة البايت كود في وقت التشغيل. كلاهما أدى إلى تنفيذ تعليمات برمجية من جانب الخادم.

السياق وتأثير السوق

يعتبر موقع LiteLLM كنقطة اختناق (chokepoint) في بنية الذكاء الاصطناعي، مما يمنح الاختراق نطاقًا واسعًا. يُمكّن الاختراق الكامل من الكشف عن المفتاح الرئيسي (master key)، ومفتاح التشفير (salt key) الذي يفك تشفير بيانات الاعتماد المخزنة، وعنوان URL لقاعدة البيانات. كما يكشف عن جميع مفاتيح المزودين المُعدة مسبقًا، لخدمات مثل OpenAI وAnthropic وGemini وBedrock وAzure وغيرها. يتم تخزين المفاتيح في ملفات التكوين أو متغيرات البيئة بصيغة نص عادي، بينما تكون المفاتيح في قاعدة البيانات مشفرة ولكن يمكن استعادتها باستخدام مفتاح التشفير.

تصبح جميع البيانات المرسلة عبر البوابة، من مطالبات واستجابات، قابلة للقراءة. في عمليات النشر الحقيقية، غالبًا ما ينتهي الأمر بمعلومات حساسة مثل PII والتعليمات البرمجية المصدر والتذاكر الداخلية والأسرار المُلصقة في هذه البيانات. إذا كانت البوابة تعمل أيضًا كبروتوكول سياق النموذج (Model Context Protocol - MCP) أو بوابة عملاء (agent gateway)، فإن رموز OAuth وبيانات اعتماد الأدوات تكون أيضًا ضمن نطاق الاختراق. علاوة على ذلك، يكمن الخطر الأكبر ليس فيما يمكن للمهاجم قراءته، بل فيما يمكنه إعادة كتابته. تجلس البوابة على سلك الاتصال بين عميل الذكاء الاصطناعي والنموذج، لذا فإن اختراقها يسمح بتعديل الاستجابات أثناء النقل.

أظهرت Obsidian قدرة المهاجم على تزوير ردود النماذج من خلال توجيه كود Claude عبر وكيل مُخترق. هذا ليس هجوم "حقن المطالبة" (prompt injection)، بل استخدام لآلية رد الاتصال (callback) المدمجة في LiteLLM، وهي نقطة توسع تُشغل مع كل طلب ولا تظهر أبدًا في واجهة المستخدم الإدارية. يقوم رد الاتصال باستبدال استجابة النموذج باستدعاء أداة مزور (forged tool call) وإعادة كتابة سياق التحقق الأمني بحيث يظهر الإجراء وكأنه تمت الموافقة عليه. في العرض التوضيحي، يكتب المطور كلمة واحدة "hello"، ويقوم المهاجم بتشغيل غلاف عكسي على جهاز المطور.

هذه ليست المرة الأولى التي تواجه فيها LiteLLM تحديات أمنية هذا العام. ففي مارس، تعرضت لإصدارات LiteLLM على PyPI لهجوم سلسلة توريد (supply-chain compromise) أدى إلى تزويدها ببرامج ضارة، وفي أبريل، تم استغلال ثغرة SQL injection حرجة (CVE-2026-42208) في غضون 36 ساعة من الكشف عنها. هذه الثغرات المتتالية تسلط الضوء على الأهمية الحيوية لتأمين مكونات البنية التحتية للذكاء الاصطناعي التي تعمل كنقاط مركزية.

رؤية Glitch4Techs

ترى Glitch4Techs أن سلسلة الثغرات في LiteLLM تمثل نموذجًا كلاسيكيًا لـ "الثقة في غير محلها" (misplaced trust) عبر طبقات متعددة من التطبيق. لقد وثقت بوابة المسارات في الحقل الذي قدمه المتصل، ووثقت المعالجات في بوابة المسارات، ولم يتم إجراء أي فحص حقيقي في نهاية المطاف. هذا النهج في تصميم الأمان، الذي يفترض أن طبقة سابقة قد قامت بعملها، هو وصفة لكوارث أمنية، خاصة في الأنظمة التي تتعامل مع بيانات حساسة وتتحكم في تدفقات المعلومات الحيوية كما هو الحال في بوابات الذكاء الاصطناعي.

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

للتخفيف من هذه المخاطر، يجب على المؤسسات التي تستخدم LiteLLM اتخاذ إجراءات فورية وحاسمة. الخطوة الأولى والأكثر أهمية هي الترقية الفورية إلى الإصدار v1.83.14-stable أو أحدث. بعد ذلك، يجب إجراء تدقيق أمني شامل: إعادة التحقق من كل حساب يحمل دور proxy_admin والتعامل مع هذا الدور على أنه وصول على مستوى المضيف (host-level access). يجب مراجعة كل Custom Code Guardrail على الوكيل بعناية. والأهم من ذلك، التحقق من عمليات رد الاتصال (callbacks) المُحملة من config.yaml تحت litellm_settings.callbacks، حيث أن هذه لا تظهر أبدًا في وحدة التحكم وهي المكان الأمثل للمهاجم لإخفاء نشاط ما بعد RCE. يجب التحقق من سلامة التعليمات البرمجية المنشورة، وليس فقط التكوينات.

في حالة الاشتباه بوجود اختراق، يجب على الفور تدوير (rotate) مفاتيح المزودين، وبيانات اعتماد قاعدة البيانات، وأي رموز MCP مخزنة. إن الدروس المستفادة من هذه السلسلة من الثغرات تؤكد على الحاجة الماسة إلى تبني مبدأ الثقة الصفرية (Zero Trust) والتحقق الدقيق من المدخلات والتصريحات في كل طبقة من طبقات التطبيق، خصوصاً في البنية التحتية الحيوية للذكاء الاصطناعي.