تتجه الأنظار الأمنية نحو البنية التحتية المتنامية للذكاء الاصطناعي إثر تقرير حديث كشف عن ثغرات وتكوينات خاطئة تهدد بوابات الربط الأساسية. فقد أوضحت شركة Wiz المتخصصة في أمن السحابة أن نحو 10% من بوابات LiteLLM المكشوفة على الإنترنت اعتمدت مفتاح الإدارة الافتراضي «sk-1234»، وهو المفتاح المرفق في دليل الإعداد الرسمي للمشروع.
يمنح هذا المفتاح صلاحيات إدارية مطلقة، تشمل قراءة مفاتيح واجهة برمجة التطبيقات (API) الخاصة بمزودي النماذج، والوصول إلى بيانات اعتماد الوصول والهوية (IAM) السحابية للخادم المستضيف.
مخاطر التكوين الافتراضي وغياب المفاتيح الرئيسية
أظهر فحص شامل أجرته Wiz في فبراير 2026 عبر محرك Shodan وجود 3,074 بوابة LiteLLM مكشوفة، تبين أن 294 منها (بنسبة 9.6%) تقبل المفتاح الافتراضي «sk-1234». وتعمقت المشكلة في 191 حالة من تلك البوابات، حيث لم يُضبط أي مفتاح رئيسي من الأساس، ما جعلها تقبل أي قيمة مصادقة تُرسل إليها، بينما احتفظت الحالات المتبقية بالقيمة الافتراضية الموثقة.
يلعب المفتاح الرئيسي في LiteLLM دوراً مزدوجاً، إذ يمثل بيانات اعتماد المسؤول ويفعل آلية المصادقة في آن واحد. وفي الإصدارات السابقة للنسخة 1.82.0-stable، كانت البوابة التي تُشغل دون مفتاح رئيسي تمنح كافة الطلبات الواردة صلاحيات إدارية كاملة. وتتيح هذه الصلاحيات للمسؤول قراءة مفاتيح API للمزودين، والاطلاع على الاستفسارات المارة عبر البوابة، والاتصال بالأدوات الداخلية باستخدام بروتوكول سياق النموذج (MCP).
ورغم عدم رصد هجمات فعلية استغلت هذا المفتاح الافتراضي حتى الآن، فإن الاختبار التقني يثبت فداحة الخطر. وتجدر الإشارة إلى أن ميزة نقطة النهاية العابرة، التي تتيح الوصول إلى بيانات الاعتماد السحابية، تُعد وظيفة تعمل وفق التصميم المقصود بناء على اعتبار المسؤولين جهات موثوقة، ولذا لم يخصص لها معرف ثغرة أو إصلاح برمجي.
تجاوز المصادقة والاستغلال النشط لبروتوكول MCP
على صعيد مواز، أضافت وكالة CISA في 2 سبتمبر 2026 ثغرة المصادقة (CVE-2026-59822 بتقييم CVSS عند 8.8) إلى قائمة الاستغلال النشط. تكمن المشكلة في نقطة نهاية MCP Streamable HTTP ضمن LiteLLM، حيث تمكن مهاجمين غير مصادقين من إنشاء جلسات MCP صالحة باستخدام رمز Bearer يتألف من حرف واحد فقط. ونتج هذا الخلل عن مسار احتياطي لتمرير OAuth2؛ فعند فشل التحقق من مفتاح LiteLLM، استبدل النظام البيانات المرفوضة بكائن UserAPIKeyAuth() فارغ بدلاً من حظر الطلب، ما جعل النظام يتعامل مع الكائن الفارغ كجلسة صالحة تتيح الوصول إلى أدوات MCP.
وقد عالج الإصدار 1.84.0 هذه الثغرة، بينما أُلزمت الوكالات المدنية الفيدرالية الأميركية بتصحيحها أو عزل الأنظمة المتأثرة بحلول 16 سبتمبر 2026. وكانت Wiz قد رصدت محاولات استغلال استهدفت أنظمة الفخاخ الخاصة بها منذ 7 يوليو 2026 باستخدام رموز أحادية الحرف، مقتصرة على استكشاف نقاط نهاية عرض النماذج دون الوصول إلى مسارات تنفيذ التعليمات البرمجية أو سرقة البيانات.
سلاسل ثغرات تؤدي إلى تنفيذ الأوامر وسرقة البيانات
يختلف المشهد مع ثغرة سابقة جرى استغلالها فعلياً لتنفيذ تعليمات برمجية خبيثة. فقد أتاحت الثغرة (CVE-2026-42271 بتقييم CVSS عند 8.7) لأي مستخدم مصادق تنفيذ أوامر على الجهاز المضيف عبر نقاط اختبار في MCP-bridge. وفي يونيو 2026، تمكنت شركة Horizon3.ai من ربطها بثغرة أخرى في إطار Starlette تحمل المعرف (CVE-2026-48710)، سمح ذلك بتجاوز المصادقة وتحقيق تنفيذ أوامر عن بُعد دون الحاجة لبيانات اعتماد.
وأفادت Microsoft أن المهاجمين استغلوا هذه السلسلة لاختراق بوابات LiteLLM، حيث بادروا بفحص الجهاز المضيف وإنهاء أي عمليات تعدين منافسة، قبل نشر مُعدّن العملات الرقمية XMRig كملف ثنائي بصيغة ELF. وتطور الهجوم ليشمل استخدام بيانات قواعد البيانات المجمعة لاختراق طبقة PostgreSQL المرتبطة بالبوابة، مستهدفين جداول حيوية مثل LiteLLM_ProxyModelTable وLiteLLM_VerificationToken لسرقة إعدادات النماذج ومفاتيح المزودين.
تباين التقييمات حول ثغرة حراس التعليمات البرمجية
برز خلاف واضح حول تصنيف خطورة الثغرة الوحيدة لتنفيذ التعليمات البرمجية المذكورة في تقرير Wiz، والتي تحمل المُعرّف (CVE-2026-59821). ففي حين صنفتها Wiz كثغرة تتيح تنفيذ تعليمات برمجية بصلاحيات الجذر داخل حاوية البوابة بعد المصادقة، اعتبرها فريق LiteLLM منخفضة الخطورة بدرجة 2.1 لتطلبها حساباً عالي الامتيازات. ويتفق الطرفان على الآلية التقنية؛ فقبل الإصدار 1.82.0-stable، تجاوزت نقاط النهاية المخصصة لحراس التعليمات البرمجية فحوصات صندوق الحماية، ما سمح بتمرير كود Python ليعمل داخل الحاوية. كما أدت عملية النشر دون مفتاح رئيسي إلى جعل هذه النقاط متاحة لجميع المتصلين كمسؤولين.
يرتبط هذا الخطر باستشارة أمنية سابقة صدرت في مايو 2026 تحت المعرف (CVE-2026-40217)، والتي كشفت إمكانية الهروب من الحماية باستخدام تقنيات Bytecode. يحدث ذلك عبر تشغيل الكود في عملية الوكيل التي تعمل بصلاحيات الجذر ضمن صورة Docker الافتراضية، وهي ثغرة أثرت على الإصدارات من 1.81.8 وحتى ما قبل 1.83.10، وتمت معالجتها في الإصدار 1.83.10.
مسارات المعالجة والمشهد التهديدي العام
تحسم الترقية إلى الإصدار 1.84.0 أو ما يليه من LiteLLM كافة الثغرات المرصودة في التقرير. كما يمثل التغيير الفوري للمفتاح الرئيسي الافتراضي خطوة حاسمة لا تتطلب ترقية النظام بحد ذاتها، وتغلق مسارات الاختراق المعتمدة عليه.
ورغم تضمين دليل الإعداد تعليقاً يطالب بتغيير المفتاح «sk-1234» بقيمة عشوائية، إلا أنه ظل مستخدماً في الدليل حتى 9 سبتمبر 2026. وتؤكد هذه المعطيات تحليلات Microsoft وWiz حول تحول البنية التحتية للذكاء الاصطناعي وأنظمتها مثل LiteLLM وFlowise وLangChain وOllama وخوادم MCP، إلى أهداف استراتيجية لسرقة بيانات الاعتماد ونشر برمجيات التعدين، مما يجعل تأمين هذه الأنظمة أولوية قصوى.
