كشفت شركة “Obsidian Security” عن سلسلة من الثغرات الأمنية الحرجة في خدمة LiteLLM، وهي بوابة مفتوحة المصدر تُستخدم على نطاق واسع للتفاعل مع نماذج الذكاء الاصطناعي، والتي يمكن أن تسمح للمهاجم بالوصول الكامل إلى خادم الخدمة وتنفيذ تعليمات برمجية عليه. تمثل هذه الثغرات خطرًا كبيرًا على أمن البيانات وأنظمة الذكاء الاصطناعي.
تُعد LiteLLM حلاً لتسهيل الاتصال بأكثر من 100 مزود لخدمات نماذج الذكاء الاصطناعي تحت واجهة واحدة متوافقة مع OpenAI، مما يجعلها مكوناً أساسياً في العديد من التطبيقات القائمة على الذكاء الاصطناعي. تسمح هذه الثغرات للمهاجم بالسيطرة الكاملة على الخادم، مما يعرض جميع مفاتيح مزودي الخدمة، وبيانات الاعتماد المخزنة، وأيضًا جميع الأوامر والاستجابات التي تمر عبر الخدمة.
ثغرات LITELLM الأمنية المتسلسلة
تمكنت “Obsidian Security” من تحديد ثلاث ثغرات مترابطة، حصلت على تقييم 9.9 على مقياس CVSS (النظام العالمي لتقييم الثغرات الأمنية)، مما يصنفها ضمن فئة “الحرجة”. قامت “BerriAI”، الجهة المسؤولة عن تطوير LiteLLM، بإصدار مجموعة كاملة من الإصلاحات في الإصدار v1.83.14-stable، والذي تم إطلاقه في 2 مايو. ينصح المطورون بالترقية إلى هذا الإصدار أو أي إصدار أحدث لسد هذه الثغرات.
التصعيد عبر الثغرة الأولى (CVE-2026-47101)
تتمثل الثغرة الأولى في تجاوز صلاحيات غير مصرح به. عند إنشاء مفتاح واجهة برمجة تطبيقات افتراضي بواسطة مستخدم عادي، تقوم LiteLLM بتخزين حقل “allowed_routes” الذي يوفره المتصل دون التحقق منه مقابل دور المستخدم. هذا الحقل مصمم لتقييد قدرات المفتاح، ولكنه بدلاً من ذلك يُعامل كموافقة تساهلية.
ونتيجة لذلك، يمكن لمستخدم غير مسؤول تنصيب مفتاح يحتوي على “allowed_routes: [“/*”]”، وهو حرف بدل يتيح الوصول إلى جميع المسارات، بما في ذلك المسارات المخصصة للمسؤولين فقط. يتكرر هذا الخلل في نقاط نهاية إدارة المفاتيح الأخرى، مما استدعى ثلاث طلبات سحب (pull requests) لمعالجة المشكلة بالكامل.
التصعيد وكسر العزل (CVE-2026-47102 و CVE-2026-40217)
بمجرد تجاوز بوابة المسارات، تصبح نقاط النهاية خلفها متاحة. تفترض العديد من هذه النقاط أن البوابة قد قامت بالفعل بعملية الفحص، مما يفتح مسارين للهجوم. أحد هذه المسارات هو CVE-2026-47102، وهو تصعيد صلاحيات. يتيح نقطة النهاية /user/update للمستخدم تعديل سجله الخاص، ولكنها لا تقيد الحقول التي يمكن للكتابة فيها.
يمكن للمستخدم إجراء تحديث ذاتي بحقل “user_role: “proxy_admin””، ويتم قبول هذا التغيير وحفظه، مما يمنح المتصل صلاحيات مسؤول كاملة على الوكيل. يمكن لمسؤول المؤسسة الوصول إلى نقطة النهاية هذه عبر مسار طبيعي وغير مقيد، بينما يصل المستخدم العادي إليها بعد استغلال CVE-2026-47101. ويُصنف هذا التصعيد بدرجات مرتفعة وفقاً لنظام CVSS.
المسار الآخر هو CVE-2026-40217، وهو تجاوز للعزل في ميزة “Custom Code Guardrail” التي تقوم بتجميع وتشغيل تعليمات Python البرمجية المقدمة من المسؤول. في بيئات الإنتاج، تقوم الخدمة بتشغيل الكود عبر الدالة exec() دون فلترة على مستوى المصدر. يمكن للمهاجم إدخال تعليمات برمجية قابلة للتنفيذ، بما في ذلك الحصول على shell عكسي، وذلك عند استغلال طريقة معالجة الدوال المدمجة (builtins) في Python.
تم اكتشاف مسار منفصل في نقطة النهاية التجريبية /guardrails/test_custom_code، بواسطة X41 D-Sec، يتجاوز قائمة منع التعبيرات النمطية (regex deny-list) من خلال إعادة كتابة رمز البايت (bytecode rewriting) وقت التشغيل، مما يؤدي أيضاً إلى تنفيذ تعليمات برمجية على جانب الخادم.
تداعيات الاختراق
تكمن خطورة هذه الثغرات في موقع LiteLLM كـ “عنصر حرج” في تدفق البيانات، مما يوفر للمهاجم نطاق رؤية واسع. يكشف الاختراق الكامل عن المفتاح الرئيسي، ومفتاح الملح الذي يفك تشفير بيانات الاعتماد المخزنة، بالإضافة إلى عنوان URL الخاص بقاعدة البيانات. كما يكشف عن مفاتيح كل مزود خدمة تم تكوينه، بما في ذلك OpenAI، و Anthropic، و Gemini، و Bedrock، و Azure، وغيرها.
تكون المفاتيح المخزنة في التكوين أو متغيرات البيئة واضحة، بينما المفاتيح في قاعدة البيانات مشفرة ولكن يمكن استعادتها باستخدام مفتاح الملح. علاوة على ذلك، تصبح جميع البيانات المرسلة عبر البوابة، من أوامر إلى استجابات، قابلة للقراءة، والتي قد تشمل معلومات التعريف الشخصية (PII)، وأكواد المصدر، وتذاكر الدعم الداخلية، والأسرار الملصقة.
بالإضافة إلى قراءة البيانات، فإن الخطر الأكبر يكمن في قدرة المهاجم على تعديل الاستجابات أثناء انتقالها. يمكن للمهاجم، بعد السيطرة على LiteLLM، تعديل استجابات النماذج بطريقة لا يمكن اكتشافها بسهولة، مما قد يؤدي إلى تنفيذ إجراءات خبيثة بناءً على معلومات مضللة.
أثبتت “Obsidian” هذا الأمر عبر Claude Code الذي تم توجيهه من خلال وكيل مخترق. لا يتعلق هذا بحقن طلبات، بل باستخدام آلية الاستدعاءات المدمجة (callback mechanism) في LiteLLM، وهي نقطة توسع يتم تفعيلها مع كل طلب ولا تظهر في واجهة المسؤول. تقوم هذه الآلية بتبديل استجابة النموذج بمكالمة أداة مزيفة، وتعديل سياق التحقق من السلامة لتبدو الإجراءات معتمدة.
في العرض التوضيحي، قام المهاجم بتشغيل shell عكسي على جهاز المطور بمجرد قيام المطور بكتابة كلمة واحدة. هذا يوضح مدى خطورة إمكانية التلاعب بالسلوكيات التي تعتمد على نماذج الذكاء الاصطناعي.
الإجراءات الوقائية
يُنصح بشدة بالترقية إلى الإصدار v1.83.14-stable أو أحدث، وهو الإصدار الأول الذي يتضمن مجموعة الإصلاحات الكاملة. بعد ذلك، يجب إجراء تدقيق شامل لكل حساب يحمل صلاحيات “proxy_admin”، واعتبار هذا الدور بمثابة وصول على مستوى النظام. كما يجب مراجعة جميع ميزات “Custom Code Guardrail” على الوكيل.
من الضروري التحقق من استدعاءات (callbacks) المحملة من ملف config.yaml ضمن litellm_settings.callbacks، حيث إنها لا تظهر في سجلات النظام ويمكن أن تستخدم للتخفي بعد تنفيذ التعليمات البرمجية. يجب التحقق من سلامة الكود المنشور، وليس فقط التكوين. في حال الاشتباه بتعرض الخدمة للاختراق، يجب على الفور تدوير مفاتيح مزودي الخدمة، وبيانات اعتماد قاعدة البيانات، وأي رموز MCP مخزنة.
إن الوكيل المخترق لا يقتصر دوره على تسريب البيانات فقط، بل يمكنه أيضاً تعديل الاستجابات التي يتلقاها الوكيل، والتي يقوم الوكيل بالإجراء بناءً عليها. تكمن المشكلة الأصلية في هذه السلسلة من الثغرات في الثقة المفرطة في كل طبقة: بوابة المسارات وثقت في الحقل المقدم من المستخدم، ونقاط النهاية وثقت ببوابة المسارات، ولم يتم إجراء تحقق فعلي في أي مرحلة.