CVE-2026-42208: ثغرة حقن SQL خطيرة في LiteLLM، مُدرجة بالفعل في كتالوج CISA KEV

CVE-2026-42208: ثغرة حقن SQL خطيرة في LiteLLM، مُدرجة بالفعل في كتالوج CISA KEV

باختصار

تم تأكيد وجود ثغرة خطيرة من نوع حقن SQL (CVE-2026-42208، بدرجة CVSS 9.3) في LiteLLM، وهو وسيط (proxy) واسع الاستخدام من قبل الشركات لتوحيد وإدارة الوصول إلى نماذج الذكاء الاصطناعي المختلفة (OpenAI وما يتوافق معها) [1]. الثغرة مُدرجة في كتالوج CISA KEV، مما يؤكد أنه يجري استغلالها بالفعل بشكل نشط على الإنترنت [2]. إذا كانت شركتك تستخدم LiteLLM كبوابة دخول لخدمات الذكاء الاصطناعي، فإن الأولوية اليوم هي التحقق من الإصدار المُثبَّت والتحديث في أقرب وقت ممكن.

ما هي وما أهميتها

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

وفقًا للوصف الرسمي للثغرة، ففي الإصدارات من 1.81.16 وحتى ما قبل 1.83.7، كان استعلام قاعدة البيانات المستخدم للتحقق من مفاتيح API الخاصة بالوسيط يدمج القيمة المُرسَلة من المستدعي مباشرة داخل نص الاستعلام، بدلًا من التعامل معها كمعامل منفصل [1]. وهذا يفتح الباب أمام حقن SQL كلاسيكي: يستطيع مهاجم غير مصادَق عليه إرسال ترويسة تفويض (authorization) مُعدّلة خصيصًا إلى أي مسار من مسارات API (على سبيل المثال، المسار المستخدم لطلبات المحادثة) والوصول إلى ذلك الاستعلام الثغري عبر آلية معالجة الأخطاء في الوسيط [1]. النتيجة المحتملة هي قراءة، وربما تعديل، بيانات قاعدة بيانات الوسيط، وهو ما قد يؤدي إلى وصول غير مصرح به إلى النظام نفسه وإلى بيانات الاعتماد التي يديرها [1].

هذه ثغرة خطيرة (بدرجة خطورة "critical" وفق NVD، وCVSS 9.3) [1]، تم نشرها في 8 مايو 2026 [1]، وهي مُدرجة بالفعل في كتالوج الثغرات المُستغلة المعروفة (KEV) الخاص بـ CISA، مما يشير إلى استغلال نشط مؤكد، وليس مجرد خطر نظري [2].

من المتأثر

تؤثر الثغرة على المؤسسات التي تنشر LiteLLM كوسيط أو بوابة (AI Gateway) للذكاء الاصطناعي في الإصدارات الواقعة بين 1.81.16 وما قبل 1.83.7 [1]. المزوّد المحدد هو LiteLLM [1]. إذا كانت شركتك قد تبنّت أدوات الذكاء الاصطناعي التوليدي عبر طبقة وسيط خاصة بها تديرها فرق داخلية أو مزوّدون خارجيون، فمن المستحسن التحقق مما إذا كان LiteLLM جزءًا من تلك البنية، سواء بشكل مباشر أو كمكوّن مدمج ضمن حل آخر.

كيف تعرف ما إذا كنت متأثرًا

• تحقق مما إذا كان LiteLLM منشورًا ضمن بنيتك التحتية (داخليًا، على السحابة، أو كجزء من منتج تابع لجهة خارجية)، وما هو الإصدار الدقيق الذي يعمل به.
• تحقق مما إذا كان ذلك الإصدار ضمن النطاق المتأثر (من 1.81.16 وحتى ما قبل 1.83.7) [1].
• تحقق من مدى تعرّض هذا الوسيط للإنترنت أو من كونه في متناول شبكات ضعيفة التحكم: فكلما كان مسار API أكثر تعرّضًا، زاد خطر وصول محاولة استغلال كتلك الموصوفة إليه. نوصي من OCIRIA بمراجعة دورية للخدمات والمنافذ المرتبطة ببنيتكم التحتية الخاصة بالذكاء الاصطناعي والمرئية من الخارج، وهو أمر غالبًا ما يمر دون ملاحظة عندما يتم نشر هذه الأدوات بسرعة لتسريع المشاريع الداخلية.
• راجع سجلات الوسيط بحثًا عن ترويسات تفويض غير معتادة أو أنماط غير اعتيادية من الأخطاء في مسارات API، والتي قد تشير إلى محاولات استغلال.

كيف تحمي نفسك

1. حدّث LiteLLM إلى الإصدار 1.83.7 أو أحدث، حيث تم إصلاح الخلل [1].

2. إذا تعذّر التحديث فورًا، قصر الوصول إلى API الوسيط على الشبكات والعملاء الموثوقين فقط إلى حين تطبيق التصحيح.

3. قم بتدوير بيانات الاعتماد والمفاتيح التي يديرها الوسيط بعد التحديث، خاصة إذا كان هناك تعرّض للإنترنت خلال فترة الخطر.

4. عزّز عملية التسجيل والمراقبة لمسارات API الخاصة بالوسيط لرصد محاولات الاستغلال السابقة أو المستقبلية.

5. وثّق جرد أدوات الذكاء الاصطناعي وإصداراتها كجزء من الإدارة الاعتيادية للثغرات، للتفاعل بسرعة أكبر مع التنبيه المماثل التالي.

أسئلة شائعة

هل هي ثغرة خطيرة؟ نعم، درجة خطورتها حرجة (critical) بـ CVSS 9.3 وفق NVD، وهي مُدرجة بالفعل كثغرة مُستغلة بشكل نشط في كتالوج CISA KEV [1][2].

هل أحتاج إلى أن أكون مصادَقًا عليّ لأتأثر؟ لا، وفقًا للوصف الرسمي يمكن لمهاجم غير مصادَق عليه محاولة الاستغلال عبر ترويسة مُعدّلة [1].

هل يكفي تحديث LiteLLM؟ إنها الخطوة الأساسية التي لا غنى عنها، حيث يصحح الإصدار 1.83.7 هذا الخلل [1]؛ اجمع بينها وبين تدوير بيانات الاعتماد ومراجعة التعرّض لتقليل الخطر المتبقي.

كيف أعرف أن شركتي تستخدم LiteLLM دون علمي؟ من المعتاد أن تُدمج مثل هذه المكوّنات ضمن حلول ذكاء اصطناعي أخرى. تُعد مراجعة الجرد التقني ومساحة التعرّض الطريقة الأكثر موثوقية للتأكد من ذلك.

المصادر

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-42208
• [2] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json