Wiz: ما يقرب من 1 من كل 10 بوابات LiteLLM مكشوفة تقبل مفتاح المسؤول النموذجي sk-1234

في 9 سبتمبر 2026، نشرت Wiz Research دراسة عن LiteLLM، بوابة الذكاء الاصطناعي مفتوحة المصدر التي تقع بين التطبيقات ومزوّدي النماذج الذين تدفع لهم، وأفادت بأن 294 من أصل 3,074 من عمليات نشر LiteLLM التي أمكنها الوصول إليها على الإنترنت العام — أي 9.6%، قرابة واحدة من كل عشر — كانت تقبل sk-1234، أي المفتاح الرئيسي المذكور كمثال في وثائق إعداد المشروع نفسه، أو لم تكن تتطلب أي بيانات اعتماد على الإطلاق. وليست تلك السلسلة مفتاح API عاديًا: فهي في LiteLLM تمثّل في آنٍ واحد بيانات اعتماد المسؤول والعنصر الذي يشغّل المصادقة، لذا فإن من يقدّمها يستطيع قراءة كل مفتاح مزوّد نماذج مخزّن على البوابة، ومراقبة كل موجّه وإكمال يمرّ عبرها، والوصول إلى كل خادم أدوات متصل عبر Model Context Protocol. وقد ربط مؤلفا دراسة Wiz المشاركان، أميتاي كوهين ويارا شريكي، ذلك الوصول بتنفيذ شيفرة على مستوى الجذر وبسرقة بيانات اعتماد IAM السحابية للخادم المضيف. ويستند هذا السرد إلى تقرير Wiz، والتنبيهات الأمنية الخاصة بـ LiteLLM، وقائمة CISA Known Exploited Vulnerabilities التي أعقبت ذلك، وأرشيف حوادث الذكاء الاصطناعي يحتفظ بهذا السجل إلى جانب نظرائه، ولكلٍّ منها مصادره ودرجة خطورته ودرجة ثقته.

تاريخ النشر هو التاريخ الوحيد الذي يحمله السجل، وهو تاريخ نشر. أُجري الفحص الذي يقف خلف العنوان الرئيسي في فبراير 2026؛ وكانت العلّتان البرمجيتان اللتان تصفهما Wiz قد صدرت لهما إصلاحات بحلول منتصف مايو على أبعد تقدير، في إصدارات تؤرّخها سجلات المشروع نفسه إلى مارس ومايو؛ وصدرت معرّفات CVE في يوليو؛ وجاء الإدراج في الفهرس في سبتمبر. كان كل شيء تقريبًا في التقرير قديمًا بالفعل بحلول وقت طباعته، وهو جزء كبير من حجة التقرير.

نسبة 9.6% ناتجة عن فحص واحد، وتقول Wiz إن متابعتها الخاصة في أغسطس لا يمكن مقارنتها به

القياس بسيط، وتذكر Wiz طريقتها بوضوح: 3,074 وكيلاً وسيطاً من LiteLLM مكشوفاً على الإنترنت عُثر عليها عبر Shodan في فبراير 2026، واختُبر كل منها لمعرفة ما إذا كان سيصادق باستخدام مفتاح المثال الموثّق. من بينها، نجح 294 في ذلك. وضمن تلك المجموعة، لم يكن لدى 191 أي مفتاح رئيسي مُهيأ على الإطلاق وكانت ستقبل أي سلسلة تُقدَّم لها؛ بينما أبقى الباقي العنصر النائب من دليل الإعداد في مكانه. لا يتطلب أي من نمطي الفشل وجود خطأ برمجي. كلاهما يحتاج فقط إلى عنوان البوابة والقيمة المطبوعة في README الخاص بالمشروع نفسه.

كما أنه مسح أجراه بائع واحد. وقد تكرر رقم Wiz في مبادرة السلامة في الذكاء الاصطناعي التابعة لتحالف أمن السحابة في 10 سبتمبر، وفي The Hacker News في اليوم نفسه، لكن كليهما يكرره مع نسبه إلى مصدره، ولم يُعثر على أي تكرار مستقل لرقم 3,074 لهذا المقال. أجرت Wiz مسحًا ثانيًا في أغسطس 2026 ووجدت أكثر من 85,000 حالة، أي نحو سبعة وعشرين ضعف عدد فبراير. وتقول الشركة إن معظمها يبدو أنه مصائد أو عمليات نشر اختبارية، وإن العددين لا يمكن مقارنتهما. لا يوجد رقم تعرض حالي، وأي مقال يستشهد برقم فإنه يستشهد برقم فبراير.

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

المفتاح الرئيسي هو في آنٍ واحد بيانات اعتماد المسؤول والمفتاح الذي يفعّل المصادقة.

يمنح تصميم LiteLLM سرًّا واحدًا وظيفتين. فالمفتاح الرئيسي يوثّق الطلبات الإدارية، ووجوده هو ما يمكّن التوثيق أصلًا: فمن دون مفتاح رئيسي ومن دون إعداد JWT أو OAuth2، يعمل الوكيل مفتوحًا ويقبل كل طلب. وقد تعامل Wiz مع قاعدة الشيفرة باستخدام Claude Code من Anthropic، باحثًا عن ميزات تأخذ مدخلات يتحكم بها المستخدم وتمرّرها إلى سياق تنفيذ، وكان معالج التوثيق واحدًا من ثلاثة أسطح رصدها.

قبل v1.82.0-stable، كانت عاقبة تلك المهمة الثانية أسوأ من بروكسي مفتوح. وجدت Wiz أنه عندما لم يكن هناك مفتاح رئيسي مضبوط، كان معالج المصادقة يسنِد دور PROXY_ADMIN إلى كل طلب وارد، لذا لم يكن المتصل غير الموثّق يُقبل فحسب، بل يُقبل كمسؤول. غيّر طلب السحب #22095، المذكور في التقرير، الدور الافتراضي إلى INTERNAL_USER وأضاف فحصًا للمسؤول إلى نقاط نهاية حواجز الحماية.

الوصول الإداري إلى بوابة ليس امتيازًا ضيقًا. فالنُسخة تحتفظ بمفتاح API لكل مزوّد توجّه إليه، وهذا ما يجعلها هدفًا لـ LLMjacking — تشغيل أحمال عمل النماذج على فاتورة الضحية. وهي ترى المطالبات والاستكمالات. وتتصل خارجيًا بخوادم أدوات MCP، التي من المرجح أن تشمل في أي نشر داخلي متتبعات القضايا والدردشة وقواعد البيانات وخطوط أنابيب النشر.

كما أظهرت Wiz أيضًا مسارًا من ذلك المقعد الإداري إلى هوية السحابة الخاصة بالمضيف. تتيح LiteLLM للمسؤول تسجيل مسار تمرير إلى أي عنوان URL هدف، ولا يتم التحقق من الهدف مقابل نطاقات العناوين الخاصة أو localhost أو عنوان البيانات الوصفية السحابية. ويؤدي توجيه مسار نحو خدمة البيانات الوصفية للمثيل إلى إرجاع بيانات اعتماد IAM التي يعمل بها عبء العمل. ولا يساعد تحويل خدمة البيانات الوصفية إلى IMDSv2، الذي عادةً ما يبطل هذه الفئة من تزوير الطلبات عبر طلب رمز جلسة يُحصل عليه بشكل منفصل: إذ تعيد LiteLLM توجيه أي ترويسة مسبوقة بـ x-pass- إلى الهدف مع إزالة البادئة، لذا يمكن تهريب ترويسة الرمز عبرها. وتقول Wiz إنه يمكن القول إن الميزة تعمل كما هو مقصود ضمن نموذج تهديد يثق بالمسؤولين، وإنها لذلك لا تحمل أي CVE ولا إصلاح.

تلك الفقرة الأخيرة عرض توضيحي، وليست هجومًا مرصودًا. وتذكر Hacker News، وهي تنقل البحث في 10 سبتمبر، أنه لا يوجد مصدر يفيد بأن أحدًا نفّذ ذلك ضد نشر حقيقي، وأنه يتطلب أولًا صلاحية وصول إداري. وصياغة Wiz هي نفسها: فالتمرير المباشر خاصية تصميم لا تصبح ثغرة إلا عندما تكون بيانات اعتماد المسؤول سلسلة نصية مأخوذة من الوثائق.

8.8 و2.1 يقيّمان السلسلة نفسها من نقطتي انطلاق مختلفتين.

تحمل ثغرتان أمنيتان من نوع CVE النتائج التقنية، ويكاد يكون الفارق بين درجاتهما المنشورة أقصى ما يمكن.

CVE-2026-59822 هو تجاوز مصادقة MCP، ويصنّفه استشاري LiteLLM بدرجة High، 8.8 وفق CVSS 4.0، دون الحاجة إلى امتيازات، ودون تفاعل من المستخدم، ودون متطلبات هجوم. نقطة نهاية MCP لديها معالج مصادقة خاص بها، مصمم لقبول إما مفتاح LiteLLM أو رمز OAuth2 موجه إلى خادم أدوات upstream. عندما فشل رمز في اجتياز تحقق LiteLLM، التقط المعالج استجابة 401 واستبدل بها كائن مصادقة فارغ بدلاً من رفض الطلب. وبالتالي أنتج أي رمز Bearer جلسة MCP صالحة، بما في ذلك حرف واحد: إذ يرسل إثبات المفهوم من Wiz رمز bearer من حرف واحد ويستقبل معرّف جلسة. تم إصلاح الثغرة في الإصدار 1.84.0.

CVE-2026-59821 هو خلل في حاجز الحماية، وتصنّفه الاستشارة الأمنية الخاصة بالمشروع نفسه على أنه منخفض، 2.1، مع اشتراط امتيازات عالية ووجود متطلبات هجوم. تتيح ميزة حاجز الحماية بالشفرة المخصصة للمسؤول إرسال شفرة Python يقوم الخادم بتجميعها وتنفيذها. كانت نقطة نهاية الاختبار في واجهة الويب تتحقق من الشفرة مقابل قائمة أنماط محظورة وتزيل الدوال المدمجة قبل تشغيلها؛ أما نقطتا نهاية الإنشاء والتحديث في الإنتاج فلم تفعلا أياً من ذلك. تعيد Python ملء الدوال المدمجة عند غيابها، لذا وصلت الشفرة المرسلة إلى المكتبة القياسية. يسجّل إثبات المفهوم الخاص بـ Wiz حاجز حماية ينفّذ أمر shell وقت التسجيل — قبل أي طلب نموذج — ويعيد مخرجات الأمر كسبب للحظر، والذي عاد في اختباره بصفة root. تم إصلاح الخلل في v1.82.0-stable.

الوصفان متوافقان، والجملة التي تحقّق التوافق موجودة في الإشعار الاستشاري نفسه: تشير LiteLLM إلى أنه في عمليات النشر التي لا يوجد فيها مفتاح رئيسي مُهيّأ، يمكن معاملة المستدعين كمسؤولي بروكسي، وهو ما جعل نقاط نهاية الضوابط الأمنية في متناول اليد. تفترض A 2.1 مستخدمًا ذا امتيازات. وسلسلة Wiz هي ما يحدث عندما يجعل المفتاح الافتراضي كل مستدعٍ ذا امتيازات. لا يوجد أي من التقييمين على خطأ بشأن نقطة بدايته؛ لكنهما يختلفان حول مدى تكرار أن يكون ذلك الوضع متاحًا دون قيود.

ثمة تحفظ واحد يكتنف ادعاء Wiz بأنه بعد 1.82.0 لن يتمكن المهاجم الذي يملك المفتاح الافتراضي من تنفيذ شيفرة إلا داخل صندوق عزل. وتشير The Hacker News إلى استشارة منفصلة صادرة في مايو 2026، هي CVE-2026-40217، تصف الهروب من صندوق العزل هذا عبر تقنيات الشيفرة البايتية في الإصدارات من 1.81.8 وحتى ما قبل 1.83.10، داخل عملية وسيط تقول الاستشارة إنها تعمل بصلاحيات الجذر في صورة الحاوية الافتراضية. والوصول إلى تلك النقطة الطرفية يتطلب بيانات اعتماد مسؤول الوسيط، وهي تحديدًا المفتاح الرئيسي.

كما أن درجة 8.8 ليست عالمية هي الأخرى. وتلاحظ المذكرة البحثية الصادرة عن تحالف أمن السحابة أن النشرة الاستشارية الخاصة بـ GitLab تُدرج درجة أساس قدرها 8.2 للثغرة نفسها، وتمتنع عن الحكم بين المنهجيتين، مكتفية بالإشارة إلى أن كلتيهما تقعان في النطاق المرتفع. ولا يتوقف تصنيف خطورة السجل على أنه "مرتفع" على الرقم المستخدم.

تم استغلال ثغرة CVE واحدة في البرية؛ ولا توجد ضحية محددة بالاسم لحالة تعرّض المفتاح الافتراضي.

أضافت CISA الثغرة CVE-2026-59822 إلى كتالوج الثغرات المعروفة المستغلة في 2 سبتمبر 2026، وحددت موعدًا نهائيًا للإصلاح هو 16 سبتمبر 2026 للوكالات المدنية الفيدرالية؛ ويتضمن مُدخل الكتالوج CWE-287 وCWE-306، أي المصادقة غير الصحيحة والمصادقة المفقودة. وتفيد مذكرة Cloud Security Alliance بأن متتبعي الصناعة وصفوها بأنها أول ثغرة خاصة بـ MCP على تلك القائمة. وقد نشرت Wiz عملية الاستغلال التي رصدتها: فمنذ 7 يوليو 2026 سجّلت أنظمة المصائد التابعة لها طلبات تحمل رموز حامل من حرف واحد تختبر نقاط نهاية سرد النماذج، ولا تصف Wiz أي استخدام آخر للثغرة.

لا يوجد نظير لذلك بالنسبة للمفتاح الافتراضي. فلا ضحية يُسمّى بالاسم، ولا بوابة تُحدَّد بأنها قد جرى الاستيلاء عليها عبر sk-1234، ولا تُظهر أي بيانات تتبّع أن الـ294 مضيفًا قيد الاستخدام. ولا يسجّل مدخل الأرشيف أي ضرر فعلي، وهذا كلام عن الأدلة لا عن الآلية: فقد جرى قياس التعرّض، لا مشاهدة استغلاله.

غالبًا ما يُدرَج بندان آخران إلى جانب هذه، وهما ليسا الشيء نفسه. CVE-2026-42271، وهو تنفيذ أوامر عبر نقطتي اختبار MCP، هو ثغرة LiteLLM التي استخدمها المهاجمون فعليًا لتشغيل الشيفرة؛ فقد سجّلت مصائد Wiz قيامه بتثبيت برنامج تعدين للعملات المشفرة. أما الحالة التي نشرتها Microsoft في أغسطس 2026، والتي قرأ فيها متسلل متغيرات البيئة لحاوية بوابة، واستعاد المفتاح الرئيسي ومفاتيح المزوّد وسلسلة اتصال قاعدة بيانات، ثم نسخ سجلات من جدولي النماذج والمفاتيح الافتراضية في LiteLLM، فتوضح قيمة ما تساويه بوابة مخترقة بدلًا من أنها تمثل طريقة دخول جديدة؛ وتفيد The Hacker News بأن Microsoft تقيّم نقطة الدخول على أنها سلسلة CVE-2026-42271.

يرى القائمون على الصيانة أن غياب المفتاح الرئيسي خطأ في الإعداد وليس ثغرة أمنية.

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

لقد جُرّب ذلك الموقف علنًا. في 15 أغسطس 2026، فتح باحث مشكلة على GitHub رقم #37054، يفيد فيها بأن وكيلًا يكون فيه LITELLM_MASTER_KEY غير مضبوط يوثّق أي قيمة مفتاح، وأن ملف docker-compose المضمّن لا يعيّن واحدًا. أُغلقت المشكلة بعد 30 دقيقة، والتعليق الوحيد عليها من الحساب نفسه: يشير إلى تعليمات سياسة الأمان بأن تُقدَّم البلاغات عبر تقارير ثغرات خاصة بدلًا من المشكلات العامة، ويعتذر عن تقديم البلاغ علنًا، ويقول إن التقرير الكامل كان يُقدَّم عبر مسار الاستشارات الأمنية بدلًا من ذلك. لا يظهر أي رد من أحد المشرفين في السلسلة، لذا يُظهر السجل أن المُبلّغ سحب البلاغ العام، لا أن المشروع استجاب له. ولا يسجّل أي شيء علني ما آلت إليه المشاركة الخاصة.

لم يُعثر على أي بيان عام صادر عن BerriAI يدافع عن ذلك الموقف أو يعدّله بشأن تقرير سبتمبر لهذه المقالة. وتتجلى استجابة الشركة المرئية في ملاحظات الإصدار وملفات التهيئة الخاصة بها، لا في نص مكتوب.

وصل التنفيذ في الثالث من أكتوبر، بعد أربعة وعشرين يومًا من التقرير.

تم إصلاح العيبين البرمجيين في الشيفرة قبل التقرير بوقت طويل. ويسجّل الجدول الزمني للإفصاح لدى Wiz تنفيذ شيفرة الحماية المبلّغ عنه في 18 فبراير 2026 والمُصلح في 25 فبراير في v1.82.0، وتجاوز MCP المُصلح في 25 أبريل في v1.84.0، والاستغلال المرصود في 7 يوليو، ومعرّفات CVE المنشورة في 8 يوليو، والإدراج في الكتالوج في 2 سبتمبر. وتحمل مخرجات الإصدار تواريخ لاحقة لتواريخ الإصلاحات: يُظهر فهرس الحزم v1.82.0 في 1 مارس 2026 وv1.84.0 في 14 مايو، وهما يؤرخان متى أصبح كل إصلاح قابلاً للتثبيت لا متى دخل إلى الشيفرة. ويسجّل سجلّا إصدار تابعان للجهة الأولى الإصلاحات نفسها بتواريخ لاحقة لتلك الواردة في الجدول الزمني. فإصدار v1.82.0-stable على GitHub يحمل تاريخ 11 مارس 2026، وحزمة 1.82.0 على PyPI تاريخ 1 مارس؛ ويؤرخ v1.84.0 بـ14 مايو 2026 في كليهما. ولا شيء منشور يفسّر الفجوة، وهذا لا يهم الحجة، لأن كلًا من تلك التواريخ يسبق تقرير سبتمبر بأشهر. وتضيف الاستشارتان على GitHub تاريخًا ثالثًا كذلك: فقد نُشرتا في 30 يونيو 2026، أي قبل ثلاثة أسابيع من معرّفات CVE التي تقول Wiz إنها صدرت في 8 يوليو.

ما لم تعالجه أي من تلك الإصدارات كان الإعداد الافتراضي. أبلغت Wiz أنه اعتبارًا من 9 سبتمبر كان المفتاح الرئيسي لا يزال مضبوطًا على sk-1234 عند تثبيت LiteLLM عبر Docker Compose أو pip install، وأكدت The Hacker News أن دليل الإعداد كان لا يزال يستخدم تلك القيمة في ذلك اليوم. جاء التغيير مع v1.104.0، المرفوع إلى Python Package Index في 3 أكتوبر 2026، وتدرج ملاحظات إصداره ذلك كتغيير كاسر: حيث يرفض الوكيل الآن البدء بمفتاح رئيسي غير مضبوط أو فارغ أو معروف علنًا، مع تسمية مصدر القيمة السيئة في خطأ بدء التشغيل وطباعة أمر يولّد مفتاحًا آمنًا. ويسجل إدخال مرافق تغييرًا لوقف الإعلان عن قيمة مفتاح رئيسي ضعيفة معروفة علنًا في الإعدادات والأمثلة المضمنة، ولم يعد ملف docker-compose في الفرع الرئيسي للمشروع يضبط أي مفتاح على الإطلاق.

تلك هي المتتابعة الجديرة بالحفظ. تم ترقيع الشيفرة في الربيع. القيمة التي جعلت تلك الترقيعات غير كافية ظلت في تعليمات التثبيت حتى أكتوبر، وعندها فقط بدأ البرنامج في رفضها. لم يتطلب أي من الإصلاحين أن ينتظر الآخر.

ما لم يتغيّر هو مسار المرور المباشر إلى خدمة البيانات الوصفية للنسخة. فهو لا يزال بلا ثغرة CVE ولا إصلاح، لأن المشروع يعتبر المسؤولين موثوقين. لذلك فإن قائمة المعالجة التي أعدّتها Wiz تتألف في معظمها من مهام يضطلع بها المشغّل: مفتاح رئيسي قوي وفريد، ومراجعة للحواجز المسجّلة يتبعها إعادة تشغيل العملية لمسح الشيفرة المحتجزة في الذاكرة، وتدقيق لنقاط النهاية الخاصة بالمرور المباشر مع تقييد حركة الخروج من الحاويات، وأدوار IAM بأقل قدر من الامتيازات. ولا يأتي أيٌّ من هذه الأربعة بمجرد الترقية.

ما لا يثبته السجل

• لم يُعثر على أي تكرار مستقل لفحص 3,074 مضيفًا. نسبة 9.6% هي قياس خاص بـ Wiz، وكل رواية أخرى عنها تكرر هذا الرقم بالإسناد.

• لا يوجد رقم حالي للتعرّض. وجدت متابعة أغسطس أكثر من 85,000 حالة، وتقول Wiz إن معظمها فخاخ عسل أو عمليات نشر تجريبية ولا يمكن مقارنتها بعدد فبراير.

• لا توجد ضحية. لا شيء في السجل يسمّي بوابة أو مشغّلًا أو حسابًا سحابيًا مخترقًا عبر المفتاح الافتراضي، والاستغلال الذي توثّقه Wiz هو استغلال لتجاوز MCP وليس لـ sk-1234.

• لا يوجد دليل على أن المضيفات الـ294 قد استُخدمت. اختبر المسح ما إذا كانت ستُصادِق، وهو ادعاء أضعف من إثبات أن أحدًا قد فعل ذلك.

• لا يوجد تصنيف خطورة مستقر لخلل حاجز الحماية. يصف Wiz والمشرفون السلوك نفسه ويقيّمونه بشكل مختلف جدًا، والاختلاف يتعلق بالامتيازات التي يفترض كل منهما أن المهاجم يمتلكها بالفعل.

Wiz هي أيضًا مورّد لأمن السحابة يبيع قدرات كشف عن هذه الفئة من التعرّض، ويُختتم التقرير بقسم عن كيفية تحديد منتجاتها هي لعمليات نشر LiteLLM والإصدارات المعرّضة للخطر والنُسخ الظلّية. ذلك سياق لقراءة قسم المعالجة، وليس سببًا لعدم الاعتداد بقياسٍ تُصادق على تفاصيله التقنية الإرشادات الأمنية الصادرة عن المشرفين أنفسهم.

الجزء من السجل الذي ينتقل إلى ما هو أبعد من LiteLLM هو الفجوة بين تاريخين. أُغلقت الثغرة في الربيع. كان الإعداد الافتراضي الذي جعل الثغرة تهم شخصًا غريبًا لا يزال يُطبع في تعليمات التثبيت في سبتمبر، ولم يبدأ البرنامج في رفضه إلا في أكتوبر. لم يضطر المشغلون الذين غيّروا السلسلة إلى الانتظار لأي من ذلك.