العودة إلى المكتبة
الأمن والحوكمة

أول CVE لـ MCP في قائمة KEV بلغ موعدها الفيدرالي: LiteLLM وخزنة المفاتيح الافتراضية

آخر تحديث: 2026年9月15日

CVE-2026-59822 هي تجاوز مصادقة في وكيل LiteLLM من BerriAI — البوابة مفتوحة المصدر التي توجّه المرور بين التطبيقات وأكثر من 100 مزوّد نماذج — وقد بلغت موعدها الفيدرالي للإصلاح في 16 سبتمبر 2026. أضافت CISA الثغرة إلى قائمة الثغرات المستغلة المعروفة في 2 سبتمبر بموعد استحقاق اليوم بموجب BOD 26-04، لتصبح أول تنفيذ لـ Model Context Protocol يُدرج كمستغل بنشاط من قبل سلطة وطنية لإدارة الثغرات (NVD؛ The Hacker News). الاستغلال ليس نظرياً: راقبت بنية honeypot من Wiz استخدام CVE-2026-59822 في البرية في 7 يوليو — قبل 56 يوماً من الإدراج في قائمة KEV (Wiz). والثغرة ليست حتى الطريقة الأكثر شيوعاً للدخول إلى هذه البوابات. وجد مسح Wiz لفبراير 2026 عبر 3,074 مثيل LiteLLM مكشوفة على الإنترنت 294 — 9.6٪ — تقبل مفتاح الماستر الافتراضي sk-1234 المطبوع في توثيق LiteLLM نفسه، و191 دون أي مصادقة مكونة إطلاقاً (Wiz؛ The Hacker News).

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

النقاط الرئيسية

  • CVE-2026-59822 هي أول CVE خاصة بـ MCP على قائمة KEV من CISA — أُضيفت في 2 سبتمبر 2026 بموعد إصلاح فيدرالي في 16 سبتمبر 2026، بمؤشر CVSS 8.8، وتؤثر على جميع إصدارات LiteLLM قبل 1.84.0.
  • راقب honeypot من Wiz استغلالاً في 7 يوليو 2026 — قبل 56 يوماً من الإدراج في KEV — برمز Bearer من حرف واحد يؤسس جلسة MCP مصادَقة بالكامل.
  • 294 من أصل 3,074 بوابة LiteLLM مكشوفة على الإنترنت (9.6٪) تقبل مفتاح الماستر الافتراضي الموثق sk-1234 أو لا مصادقة — 191 منها لا تتطلب أي بيانات اعتماد، حسب مسح Shodan من Wiz في فبراير 2026.
  • المفتاح الماستر خزنة بيانات اعتماد سحابية: يمكن لمسؤول شرعي (أو مهاجم يحمل المفتاح) استخدام توجيه pass-through لقراءة بيانات وصفية لمثيلات AWS واسترجاع بيانات اعتماد IAM، وIMDSv2 لا يمنعه لأن الوكيل يعيد توجيه الرؤوس ذات البادئة x-pass-.
  • التجاوز نمط كود، لا مجرد عيب: اعتراض مصادقة فاشلة وإحلال كائن مصادقة فارغ. تُظهر أبحاث "Puppet" المنشورة في ACM أن هذا الصنف من الـ confused deputy يصل إلى نجاح 90.89٪ في اختطاف اختيار الأدوات بينما يبقى غير مرئي لـ MCP-Scan وMcpSafetyScanner.

ساعة الـ 24 ساعة، وكيف يعمل التجاوز في طلب واحد

الخط الزمني مهم لأنه يظهر أن الاستغلال سبق الاستجابة الفيدرالية في كل مرحلة. أبلغ Wiz الثغرة إلى مشرفي LiteLLM في 18 فبراير 2026؛ وصل الإصلاح في LiteLLM 1.84.0 في 25 أبريل؛ سجّل honeypot من Wiz استغلالاً حقيقياً في 7 يوليو؛ نُشرت الثغرة في 8 يوليو؛ أضافتها CISA إلى قائمة KEV في 2 سبتمبر — وحددت موعد الإصلاح بعد 14 يوماً (Wiz؛ NVD).

الآلية هي رجوع fail-open في نقطة نهاية MCP في LiteLLM. تدعم النقطة نمطين من المصادقة: مفاتيح LiteLLم الأصلية ورموز OAuth2 الممررة إلى خادم MCP أعلى في السلسلة. عندما يفشل رمز Bearer في تحقق مفتاح LiteLLM برمز 401 أو 403، كان من المفترض أن يعيد المعالج تمرير الرمز إلى الأعلى. بدلاً من ذلك، يعترض الخطأ ويعيد كائن UserAPIKeyAuth() فارغاً — جلسة مصادَقة بلا هوية خلفها (Wiz؛ قاعدة بيانات الإعلانات الأمنية في GitLab). استخدم عرض Wiz Authorization: Bearer *** — حرفاً واحداً — وتلقى HTTP 200 مع mcp-session-id` صالح.

ما يمكن أن تصل إليه تلك الجلسة يعتمد كلياً على إعداد النشر. بوابة لها أداة استعلام قاعدة بيانات موصولة تمنح المهاجم وصولاً للاستعلام؛ تكامل GitHub يمنح قراءة مستودعات وإنشاء مشكلات؛ موصلات نظام الملفات تمنح وصولاً للقراءة والكتابة. علم allow_all_keys الموثق في LiteLLM — الموصى به من LiteLLM نفسها لـ "أدوات مساعدة منخفضة المخاطر" — يجعل كل خادم MCP مكون قابلاً للوصول بواسطة بيانات الاعتماد الفارغة التي يخلقها التجاوز (Hive Security). نصف قطر الانفجار ليس الوكيل. إنه كل نظام تلمسه خوادم MCP للوكيل.

ثلاثة إخفاقات، بوابة واحدة

كشفت أبحاث Wiz أربعة مشكلات مختلفة في LiteLLم بشروط مسبقة مختلفة — تسطيحها في "سلسلة سحرية" واحدة يحرف شدة الخطر والاستجابة معاً (Wiz):

  1. CVE-2026-59822 — تجاوز مصادقة MCP. دون مصادقة، طلب واحد، إصدارات قبل 1.84.0. أُصلح في 1.84.0.
  2. CVE-2026-59821 — تنفيذ كود بمستوى root عبر حواجز guardrail مخصصة. كانت نقطة تسجيل الحواجز تمرر بايثونًا يرسله المسؤول إلى exec() دون صندوق الحماية (إزالة المبنيّات، فحوصات الأنماط المحظورة) المطبق في مسار الاختبار الخاص بواجهة المستخدم. راقب Wiz كوداً يعمل كـ root داخل حاوية الوكيل. أُصلح في 1.82.0-stable. هذه تتطلب وصول مسؤول — لكن مقترنة بنمط الفشل 3 تصبح فعلياً قبل المصادقة.
  3. مصادقة افتراضية أو غائبة. نتيجة مسح 294 من 3,074. عندما لا يُكوَّن مفتاح ماستر، كان LiteLLM يمنح كل متصل وصول PROXY_ADMIN — سلوك تصميم بلا CVE أُصلح مع CVE-2026-59821.
  4. توجيه pass-through إلى البيانات الوصفية السحابية. يمكن لمسؤول مصادَق توجيه مسار pass-through إلى خدمة البيانات الوصفية لمثيلات AWS وإعادة توجيه رأس رمز جلسة IMDSv2 عبر سلوك إزالة البادئة x-pass- في الوكيل. يصنفها Wiz وLiteLLM كسلوك مقصود من المسؤول — لا CVE ولا إصلاح. لكن حين يمحو مفتاح ماستر افتراضي أو مسرّب فرضية أن المسؤولين الموثوقين فقط يحملون المفتاح، تصبح هذه القدرة "المقصودة" طريقاً من اختراق التطبيق إلى اختراق الحساب السحابي (CSA).

التكديس هو القصة. يحمل LiteLLM مفاتيح API لكل مزوّد نماذج مكون — OpenAI وAnthropic وAWS Bedrock وAzure وGoogle Vertex AI — ويعمل نشر في نحو ثلث البيئات السحابية المستقصاة (CSA). تسمي مذكرة أبحاث CSA تكوين مفتاح الماستر "خزنة بيانات اعتماد سحابية". خُليت الخزنة مرة واحدة فعلاً: في اختراق كُشف علناً في أغسطس 2026، قرأ مهاجم بتنفيذ كود على مضيف بوابة متغيرات بيئة الحاوية، واستعاد مفتاح الماستر وسلسلة اتصال قاعدة بيانات، ونسخ سجلات مباشرة من قاعدة PostgreSQL الداعمة للبوابة (CSA).

المثيل المرمّع ليس مثيلاً آمناً. بوابة مرمّعة إلى 1.84.0 وما زالت تجيب على sk-1234 مخترقة لأي شخص يعرف الافتراضي — وهم كل من قرأ README.

ما تطلبه إدراج KEV فعلياً

قائمة الثغرات المستغلة المعروفة ليست ترتيباً للشدة. إنها إثبات استغلال نشط بساعة ملزمة: بموجب BOD 26-04، يجب على الوكالات الفيدرالية المدنية تطبيق تخفيفات المورد قبل تاريخ الاستحقاق أو التوقف عن استخدام المنتج، ويجب على الوكالات فحص المثيلات المكشوفة على الإنترنت أولاً. الموعد الذي يلتحق اليوم ينطبق مباشرة على الوكالات الفيدرالية — لكن أثره يمتد أبعد، لأن عدداً متزايداً من وثائق التأمين السيبراني واستبيانات مخاطر الموردين يستشهد بقائمة KEV كخط أساس (Tech Insider). مثيل غير مرمّع لـ CVE-2026-59822 أصبح اليوم بند تدقيق لأي منظمة يرث نظام امتثالها قائمة KEV، سواء كانت وكالة فيدرالية أم لا.

المعيار له قيمة للبروتوكول، لا للمنتج فقط. CVE-2026-42271 — حقن أوامر في نقطة اختبار LiteLLM، أُضيفت إلى KEV في دفعة سابقة — كانت مجاورة لـ MCP. CVE-2026-59822 خاصة بـ MCP: السطح المستغل هو نقطة نهاية MCP Streamable HTTP ومعالج المصادقة نفسه. أول ثغرة MCP بتفويض إصلاح فيدرالي تشير إلى من أين ستأتي التالية. تعدّ إ advisory تهديدات من UltraViolet Cyber أكثر من 40 CVE كُشفت ضد تنفيذات MCP في 2026 وحده (UltraViolet Cyber)، ووجد مسح الإنترنت من Bitsight نحو 1,000 خادم MCP مكشوف يقدم جرد أدوات كاملاً دون تفويض (Bitsight)، وقاست Practical DevSecOps أن 30–82٪ من خوادم MCP العامة تحمل عيوباً قابلة للاستغلال (Practical DevSecOps). كومة التعرض خلف أول إدراج KEV ليست قيمة شاذة. إنها العينة.

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

أمن MCP · معيار KEV أول CVE لـ MCP على قائمة KEV CVE-2026-59822 · نقطة نهاية MCP في LiteLLM · الموعد الفيدرالي 16 سبتمبر 2026 اللوحة 1 · الساعة سبقت الاستجابة 18 فبراير أُبلغت Wiz → LiteLLM 25 أبريل إصلاح 1.84.0 ترميع التجاوز 7 يوليو استُغلّت honeypot من Wiz، في البرية 2 سبتمبر إدراج KEV أول CVE لـ MCP على KEV 16 سبتمبر الموعد BOD 26-04 رُصد الاستغلال قبل 56 يوماً من إدراج KEV — الساعة الفيدرالية بدأت أخيراً CVSS 8.8 · أُصلحت في 1.84.0 · طلب واحد: Authorization: Bearer *** → جلسة HTTP 200 اللوحة 2 · أربعة إخفاقات، بوابة واحدة تجاوز مصادقة MCP CVE-2026-59822 رجوع fail-open لـ OAuth2 دون مصادقة · طلب واحد أُصلحت في 1.84.0 مدرجة على KEV · الموعد 16 سبتمبر RCE عبر guardrail CVE-2026-59821 exec() دون صندوق حماية تعمل كـ root أُصلحت في 1.82.0-stable قبل المصادقة بلا مفتاح مضبوط مفاتيح افتراضية 9.6٪ مكشوفة 294 من 3,074 تقبل sk-1234 191 تقبل أي بيانات اعتماد لا ترقيع يصلح افتراضياً مسح Wiz، فبراير 2026 القفز للسحابة Pass-through مسار بيانات وصفية → بيانات IAM إعادة توجيه رؤوس x-pass- IMDSv2 لا يمنعها لا CVE، سلوك "مقصود" مثيل مرمّع ما زال يجيب على sk-1234 ما زال مخترقاً — الافتراضيات تعيش بعد الترقيع ≈1/3 من البيئات السحابية المستقصاة تعمل LiteLLM · المفتاح الماستر يقرأ كل مفاتيح المزودين + كل أدوات MCP اللوحة 3 · ستة بنود تحقق (كل منها في دقائق) 1 فشل مغلق، قابل للإثبات Bearer x → توقع 401/403، وليس 200 أبداً مع جلسة 2 جرد وترقية تثبيت النسخة المستقرة الحالية؛ حظر /mcp/ إذا كان الترقية مستحيلاً 3 تدوير مفتاح الماستر إلغاء sk-1234؛ تدوير بيانات اعتماد المزودين والموصولة بـ MCP 4 تحديد نطاق أدوات MCP لا allow_all_keys؛ فصل القراءة عن الكتابة؛ مصادقة لكل فريق 5 احتواء مستوى التحكم لا وصول للبيانات الوصفية؛ قائمة سماح للخارج؛ حاوية بلا root 6 اصطياد السجلات جلسات /mcp/ برموز عشوائية، إنشاء حواجز، pass-through أولوية يوم الموعد: البندان 1 و3 — أحدهما يثبت الثغرة، والآخر يغلق التعرض الذي ينجو من الترقيع الخلاصة بوابة عديمة الحالة ومتوافقة مع المواصفة ما زالت تقبل مفتاح ماسترها الافتراضي ما زالت مخترقة. Puppet (ACM): اختطاف أدوات بواسطة الـ confused deputy حتى 90.89٪ · غير مرئي للماسحات · LiteLLM أطلقت 3 إخفاقات مصادقة في 2026 المصادر: CISA KEV · NVD · Wiz Research · CSA AI Safety Initiative · Bitsight · UltraViolet Cyber · ideabosque.com/library

بنود التحقق الستة

تكتسب قائمة تدقيق تقصي أمان MCP التي تُقطّرها المقالة الأم إلى 12 تحكماً الآن إضافة خاصة بالبوابات. ستة بنود، كل منها قابل للتحقق في دقائق:

  1. فشل مغلق، قابل للإثبات. أرسل Authorization: Bearer *** إلى نقطة /mcp/` في البوابة. مثيل مضبوط صحيحاً يعيد 401 أو 403. مثيل ضعيف يعيد 200 مع معرّف جلسة. هذا اختبار CVE-2026-59822، وطلب واحد يكفي.
  2. جرد وترقية. ابحث عن كل مثيل LiteLLM — بما في ذلك النشر الظل في مكدسات المطورين — وسجّل نسخته وبصمة صورته، وثبّت إصداراً مستقراً حالياً. 1.84.0 أصلحت CVE-2026-59822 أولاً؛ و1.82.0-stable أصلحت CVE-2026-59821؛ وهناك إعلانات لاحقة، فلا تجمد على أي من الحدين (Hive Security). إذا كان الترقية الفورية مستحيلة، فالتخفيف الانتقالي في الإعلان هو حظر /mcp/ والمسارات ذات الصلة عند الحافة.
  3. دوّر مفتاح الماستر وكل ما خلفه. استبدل sk-1234 وأي مفتاح معاد استخدامه. إذا شُكّ في تعرض أو وصول مريب، دوّر بيانات اعتماد مزودي النماذج وقاعدة البيانات وOAuth والخدمات الموصولة عبر MCP وألغِ الجلسات المشتقة — سلسلة الاختراق الموثقة تُظهر اختراق بوابة يتكاسل مباشرة إلى تسريب مفاتيح مزودين وتفريغ قاعدة بيانات (CSA).
  4. حدد نطاق وصول أدوات MCP. أزل allow_all_keys من التكاملات الحساسة، وافصل أدوات القراءة عن الكتابة، واطلب تفويضاً لكل فريق. التجاوز يمنح كل ما تستطيع الجلسة الوصول إليه — إعداد الأدوات هو نصف قطر الانفجار.
  5. احتوِ مستوى التحكم. أزل الكشف العام إلا عند الطلب الصريح، وامنع أعباء العمل من الوصول إلى خدمات البيانات الوصفية السحابية، وضع قائمة سماح لمقاصد الخروج، وشغّل الحاوية بغير root دون تحميلات مميزة. IMDSv2 لا يدافع عن هذا المسار، لأن الوكيل يستطيع إجراء طلب الرمز وإعادة توجيه الرؤوس بنفسه (Wiz).
  6. اصطد السجلات قبل أن تنتهي صلاحيتها. راجع سجلات الوكيل العكسي وLiteLLM بحثاً عن جلسات /mcp/ مصادَقة برموز تبدو عشوائية، ونداءات أدوات غير متوقعة، وأحداث إنشاء حواجز، وتغييرات إعداد pass-through. اربطها بسجلات العمليات وDNS والتدقيق السحابي — واحفظ الأدلة قبل إعادة التشغيل، لأن إعادة التشغيل تمسح الحالة في الذاكرة ولا تلغي بيانات اعتماد مسروقة (Hive Security).

البندان 1 و3 هما أولوية يوم الموعد: الأول يثبت الثغرة، والثاني يغلق التعرض الدائم الذي ينجو من أي ترقيع.

ماذا يعني هذا خارج LiteLLM

نمطان يتعممان، وكلاهما ينتمي إلى كل مراجعة مصادقة MCP من الآن فصاعداً.

أولاً: رجوعات fail-open هي رائحة كود، لا عيب في LiteLLM. التجاوز ثلاثة أسطر — اعتراض 401، إحلال كائن مصادقة فارغ، المتابعة. كل وكيل MCP يفوض المصادقة إلى مزود أعلى عبر رجوع passthrough يحمل الصنف نفسه. الإصلاح معيار مراجعة، لا رفع إصدار: عند فشل التحقق الأعلى، ينتفي الطلب. لا يتقدم أبداً بهوية غير مصادَقة.

ثانياً: البوابات هي مستويات تحكم، وأبحاث الـ confused deputy تقول إنها تفشل عند طبقة البيانات الوصفية. قيّمت أبحاث "Puppet" المنشورة في ACM هجمات الـ confused deputy عبر 14 نموذجاً على مضيفي MCP اثنين وقاست معدلات اختطاف اختيار الأدوات حتى 90.89٪ وتنفيذ حمولة من طرف لطرف حتى 86.46٪ — بينما تبقى غير قابلة للكشف بواسطة MCP-Scan وMcpSafetyScanner، اللذين يعجزان معمارياً عن رصد التلاعب على مستوى البيانات الوصفية (ACM). بوابة تركّز بيانات اعتماد النماذج ورؤية الموجهات والوصول للأدوات خلف حدود مصادقة واحدة هي التركيز نفسه الذي تضع علامة عليه مصفوفة AI Controls من CSA لتحكمات الهوية وإدارة الأسرار (CSA). الترجمة التشغيلية: صادق البوابة كمستوى تحكم واحتوها كحد اختراق — IAM بأقل امتياز، لا بيانات اعتماد افتراضية، بيانات وصفية بعيدة المنال، خروج بقائمة سماح.

السياق الأوسع بروتوكول ينضج من "تفويض اختياري" إلى إنفاذ فيدرالي. وجد مسح ديسمبر 2025 من Bitsight نحو 1,000 خادم MCP مكشوف دون تفويض (Bitsight)؛ ووثق تحليل honeypot في أغسطس 2026 من Wiz حملات نشطة تستهدف LiteLLM وخوادم MCP وأطر الذكاء الاصطناعي عبر RCE وحقن موجهات أعمى وسرقة بيانات اعتماد من الذاكرة (Wiz)؛ وأكمل تجاوز مصادقة ثالث لـ LiteLLM — CVE-2026-49468، حقن رأس Host كُشف في 28 مايو 2026 — نمط 2026 حيث أطلق المنتج نفسه ثلاثة إخفاقات مصادقة مختلفة في سنة واحدة (إعلان GitHub). الإدراج في قائمة KEV هو النقطة التي يتوقف فيها ذلك النمط عن كونه موضوع بحثاً ويصبح بند امتثال.

نقلت مواصفة MCP بتاريخ 2026-07-28 البروتوكول إلى نواة عديمة الحالة، ويتجه عمل التفويض في المنظومة نحو OAuth 2.1 برموز مرتبطة بالجمهور. تُغلق المعمارية أصنافاً كاملة من الثغرات. لكن حادث LiteLLM يثبت أن الطبقة التشغيلية تحسم النتائج: نشر عديم الحالة ومتوافق مع المواصفة ما زال يقبل مفتاح ماستر الافتراضي ما زال مخترقاً. رقّع CVE ثم دقّق الافتراضيات — بهذا الترتيب، قبل الموعد التالي.

قراءة ذات صلة


يشغّل موزّع متوسط الحجم وكيل مشتريات يقدّم عروضاً مقابل NetSuite وBigCommerce وثلاثة كتالوجات موردين، مع بوابة LiteLLM توجّه مرور النماذج وتكشف أدوات MCP للوكيل. يثبت تحقق بطلب واحد مقابل /mcp/ أن البوابة تفشل مغلقة؛ يأتي مفتاح الماستر من مدير الأسرار، لا من README؛ ولا يمكن لدور IAM للبوابة الوصول إلى البيانات الوصفية للمثيل؛ وأدوات MCP التي يمكن للوكيل استدعاءها محدودة النطاق بقراءة الأسعار وكتابة العروض — لا شيء آخر. عندما تهبط إدراج KEV التالي، يكون الإصلاح رفع إصدار، لا تحقيق اختراق.

اطلب بناءً محدود النطاق. اكتشاف لأسبوع واحد. تحصل على جرد نظام، وخريطة سير عمل، ونطاق ثابت — سواء بنيت معنا أم لا.

هل تريد هذا مبنياً لأنظمتك؟

كل وثيقة هنا من عمل إنتاجي حقيقي. إذا كان لديك نظام مُستهدَف وسير عمل في الذهن، نستطيع تحديد نطاق بناء في أسبوع واحد.

اطلب بناءً محدد النطاق

اكتشاف مدته أسبوع واحد. تحصل على جرد للأنظمة وخريطة لسير العمل ونطاق ثابت — سواء بنيت معنا أم لا.