Wiz: قرابة واحد من كل عشرة خوادم LiteLLM مكشوفة يقبل المفتاح المنشور في التوثيق
الخطر لم يأتِ من إهمال فردي، بل من مفتاح تجريبي في الدليل الرسمي انتقل مع التجربة إلى production، والـ gateway هو المكان الذي تجتمع فيه كل مفاتيح المزودين.
نشرت شركة Wiz بحثًا عن LiteLLM، مسحت فيه 3,074 خادمًا من خوادمه المكشوفة على الإنترنت في فبراير 2026. ووجدت أن 294 منها تقبل الـ master key الافتراضي، وهو المفتاح المكتوب مثالًا في التوثيق الرسمي للمشروع، في دليل البدء السريع وفي مثال Docker Compose. ووجدت كذلك 191 خادمًا بلا master key على الإطلاق.
أي أن قرابة واحد من كل عشرة خوادم مكشوفة كان مفتوحًا بمفتاح منشور للجميع. وصدر البحث مع مجموعة ثغرات مسجلة، منها CVE-2026-59821 لتنفيذ الكود وCVE-2026-59822 لتجاوز مصادقة MCP.
ولفهم حجم المشكلة، يلزم فهم دور LiteLLM. فهو gateway يوضع أمام مزودي النماذج، فبدل أن يرسل التطبيق طلباته إلى OpenAI وAnthropic وGoogle كلًا على حدة، يرسلها إليه بصيغة واحدة. وهذا يجعله المكان الذي تُحفظ فيه كل مفاتيح المزودين.
ومن يملك الـ master key يصل بحسب Wiz إلى:
- مفاتيح المزودين كلها
- الـ prompts والردود، أي بيانات العملاء التي مرت عبر النظام
- أدوات MCP الموصولة
- وعبر الـ pass-through endpoints، إلى metadata service الخاصة بالسحابة، ومنها إلى IAM credentials
والفاتورة المرتفعة ليست أخطر ما في القائمة، لكنها غالبًا أول ما يُلاحظ.
والأهم أن هذا الوضع الافتراضي لم ينشأ من إهمال. فالدليل نفسه يمنح المطور مفتاحًا يعمل أثناء التجربة على جهازه، ثم تنتقل التجربة إلى production دون أن يتوقف أحد عند أن المفتاح لم يتغير. والنمط نفسه قائم في أدوات كثيرة غير LiteLLM: كل مثال إعدادات يحتوي على قيمة سرية جاهزة يصبح احتمالًا لبقائها. ولهذا يصبح عمر المفتاح المستخدم في أي gateway من هذا النوع سؤالًا أمنيًا بحد ذاته، لا تفصيلًا في الإعدادات.