AI Safety Incidents

تضيف CISA تجاوز المصادقة في MCP الخاص بـ LiteLLM إلى KEV: أي رمز Bearer كان كافيًا

الكاتب

Rowan Sterling

تاريخ النشر

Oct 28, 2026

أحدث النماذج · 20عرض جميع النماذج →

المعايير: Artificial Analysis · يُحدَّث يوميًا

العودة إلى جميع المقالات

في 2 سبتمبر 2026، أضافت وكالة الأمن السيبراني وأمن البنية التحتية الأمريكية CVE-2026-59822 إلى كتالوج الثغرات المعروفة المستغلة لديها باسم "BerriAI LiteLLM Improper Authentication Vulnerability"، وهي واحدة من سبع ثغرات في دفعة ذلك اليوم. تكمن العلة في نقطة نهاية MCP Streamable HTTP الخاصة بـ LiteLLM: عندما فشل التحقق من مفتاح LiteLLM، استبدل مسار الرجوع الاحتياطي لتمرير OAuth2 كائن UserAPIKeyAuth() فارغًا بدلًا من رفض الطلب، لذا فتح أي ترويسة Authorization Bearer مُلفّقة جلسة MCP موثّقة. وكان بإمكان المهاجم الذي يصل إلى نقطة النهاية تلك أن يسرد ويستدعي كل أداة MCP كان البوابة مُهيأة بها، وأن يصل عبر تلك الأدوات إلى الخدمات التي تقف خلفها. تتأثر كل الإصدارات السابقة لـ 1.84.0، ومُنحت الوكالات المدنية الفيدرالية مهلة حتى 16 سبتمبر لمعالجة الأمر. هذا السجل — إدراج KEV لثغرة تجاوز المصادقة في MCP الخاصة بـ LiteLLM — هو أحد المدخلات في أرشيف OrcaRouter لحوادث الذكاء الاصطناعي، الذي يضم مجموعة السجلات الكاملة والمدخلات المجاورة لهذا الحادث.

سببُ كون خطأ برمجي في وكيل (proxy) أهم مما توحي به درجة CVSS الخاصة به هو ما يقف خلف الوكيل. يوضّح فريق أبحاث التهديدات في Wiz الأمر مباشرة: "يمكن لوكيل LiteLLM أن يحتفظ بمفاتيح لكل مزوّد نموذج يوجّه إليه، بما في ذلك OpenAI وAnthropic وAzure وGemini. وقد يعمل أيضًا بأذونات IAM السحابية ويتصل بخدمات داخلية عبر خوادم أدوات MCP. يمكن لاختراق واحد أن يمنح المهاجم وصولًا إلى بيانات الاعتماد والخدمات الواقعة خلف الوكيل، وليس الوكيل نفسه فقط." تقول Wiz Research إنها اكتشفت العيب، وسجّلت مصائد Wiz لاحقًا محاولات لاستغلاله.

الآلية: فحص فاشل أعاد جلسة صالحة

يصف التنبيه الأمني الخاص بـ BerriAI، GHSA-7488-6r32-c95q، العيب في جملتين: "كان معالج مصادقة MCP يدعم تمرير OAuth2 لخوادم MCP المنبع، لكن مسار الاحتياط كان يمكن أن يستبدل فشل التحقق من مفتاح LiteLLM بكائن UserAPIKeyAuth() فارغ. وقد سمح ذلك لطلبات تحمل ترويسة Authorization مُلفّقة بالوصول إلى أدوات MCP دون مفتاح LiteLLM صالح." الكلمة المهمة هي الاحتياطي. كان في الشيفرة فرعٌ للنشرات التي تمرّر رمز OAuth الخاص بخادم MCP المنبع مباشرةً، وعندما يفشل التحقق من مفتاح LiteLLM، كان ذلك الفرع يعيد كائن مصادقة فارغ بدلاً من خطأ.

Screenshot of the GitHub security advisory GHSA-7488-6r32-c95q, titled 'MCP Authentication Bypass via OAuth2 Passthrough Fallback' and marked High with a CVSS v4 score of 8.8 out of 10. The package table shows litellm on pip, affected versions below 1.84.0, patched versions at or above 1.84.0. The Impact section states that LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token, that the MCP auth handler's OAuth2 passthrough fallback could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object, and that an attacker could list and call configured MCP tools and access connected services exposed through MCP. A Patches section says the issue is fixed in 1.84.0. A Workarounds section says that if upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at the reverse proxy or API gateway. The severity panel lists Attack Vector Network, Complexity Low, Requirements None, Privileges Required None; the CVE ID field reads CVE-2026-59822.

كائن مصادقة فارغ ليس مماثلًا لعدم وجود كائن مصادقة. فقد رأى الكود اللاحق كائن UserAPIKeyAuth بُني بنجاح ومضى قدمًا، دون أن يُرفق به مستأجر أو مستخدم أو نطاق. وتقرير Wiz أكثر صراحة بشأن النتيجة العملية: "عندما يفشل التحقق من الرمز، فبدلًا من رفض الطلب، يعيد الخادم كائن UserAPIKeyAuth() فارغًا بلا قيود. أي رمز Bearer (حتى حرف واحد فقط، مثل x) يمنح وصولًا كاملًا إلى MCP."

OrcaRouter card titled 'What the fallback path did', subtitled that the failure happened after validation rather than before it, in every version before LiteLLM 1.84.0. Four stages run left to right. Stage 1, Request arrives: the attacker holds no LiteLLM key, and a code block shows GET /mcp/ with the header Authorization: Bearer x. Stage 2, Key validation: the supplied token is checked and does not resolve to a key, marked FAIL, with a red tag reading NO REJECTION. Stage 3, OAuth2 passthrough fallback: intended for upstream OAuth tokens, it returned an object rather than an error, showing UserAPIKeyAuth(), with an amber tag reading EMPTY, NO SCOPE. Stage 4, MCP tooling: tools can be listed and called and connected services reached, showing tools/list followed by tools/call, with a green tag reading SESSION AUTHENTICATED. A lower band headed 'Why it held' explains that the branch returned a constructed authentication object rather than a boolean, so downstream code had a valid-looking UserAPIKeyAuth to read and no reason to ask whether the key behind it existed. A footer credits BerriAI advisory GHSA-7488-6r32-c95q and Wiz Research's 27 August 2026 write-up.

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

إصلاح في مايو، وCVE في يوليو، وموعد نهائي فيدرالي في سبتمبر

التواريخ لا تتوافق بالطريقة التي قد يفترضها القارئ، والفجوات هي الجزء المثير للاهتمام. رُفعت LiteLLM 1.84.0 — أول إصدار يسمّيه التنبيه الأمني بوصفه مُرقّعًا — إلى PyPI في 14 مايو 2026، وفقًا لبيانات الإصدار الخاصة بفهرس الحزم نفسه. حُجز معرّف CVE لدى برنامج CVE في 7 يوليو 2026، ونُشر السجل في اليوم التالي، 8 يوليو؛ ثم جاء إدخال OSV ‏PYSEC-2026-3479 في 23 يوليو. أما إدراج KEV فجاء في 2 سبتمبر، مع موعد نهائي للمعالجة في 16 سبتمبر.

OrcaRouter timeline card titled 'From patch to federal deadline', subtitled that the fixed build shipped sixteen weeks before the KEV listing and that the patch was never the bottleneck. Five dated rows, each with the source that records it: 14 May 2026, LiteLLM 1.84.0 published, per PyPI release metadata; 7 July 2026, CVE identifier reserved with the CVE Program, per the CVE.org record; 8 July 2026, CVE-2026-59822 published, assigned by GitHub as CNA, with the OSV record PYSEC-2026-3479 following on 23 July; 2 September 2026, added to CISA KEV as one of seven entries that day, added on evidence of active exploitation; 16 September 2026, federal remediation deadline, due date set for federal civilian agencies under BOD 26-04. A footer reads that dates are as recorded by each source named in the right-hand column.

ثمة أمران يترتبان على ذلك. أولًا، كان البناء المُرقّع متاحًا للعموم لأكثر من ثلاثة أشهر قبل أن تُدرج CISA العيب ضمن الثغرات المستغلة — لذا كانت المؤسسات التي ألزمها الموعد النهائي لديها ترقية عاملة متاحة طوال تلك الفترة، ولم تكن إضافة KEV هي اللحظة التي ظهر فيها إصلاح. ثانيًا، اتسعت الفجوة بين الإصدارات منذ ذلك الحين: الإصدار الحالي من LiteLLM على PyPI هو 1.106.5، وقد رُفع في 27 أكتوبر 2026. وأي نشر لا يزال على إصدار أدنى من 1.84.0 أصبح الآن متأخرًا بأكثر من عشرين إصدارًا فرعيًا، وليس مجرد ترقيع واحد ناقص.

ما الذي تُثبته القائمة، وما الذي لا تُثبته

يقول تنبيه CISA الخاص بالدفعة إن الإضافات تُجرى "استنادًا إلى أدلة على استغلال نشط"، ويحمل الإدخال القابل للقراءة آليًا في الكتالوج الخاص بـ CVE-2026-59822 تاريخ إضافة هو 2 سبتمبر 2026، وتاريخ استحقاق هو 16 سبتمبر 2026، وقيمة استخدام حملة فدية معروفة هي "Unknown"، ونقطتي ضعف: CWE-287 (مصادقة غير صحيحة) وCWE-306 (مصادقة مفقودة لوظيفة حرجة).

• المُثبَت:قيّمت CISA هذا العيب بأنه مُستغَل فعليًا وأدرجته في قائمة المعالجة الفيدرالية. ويسجّل سجل SSVC الخاص بـ NVD، المنسوب إلى منسّق CISA والمؤرّخ في 2 سبتمبر 2026، الاستغلال بأنه "نشط"، وإمكانية الأتمتة بأنها "نعم"، والأثر التقني بأنه "جزئي".

• مؤكد:لوحظ استغلال في بيئة خاضعة للتحكم. نشرت Wiz حركة مرور من مصائد العسل تُظهر طلبات برموز مميزة من حرف واحد تتحرى نقطة نهاية تعداد النماذج: طلب GET إلى /v1/models يحمل "Authorization: Bearer x". وصفت The Hacker News، أثناء إبلاغها عن دفعة KEV في 3 سبتمبر، النشاط نفسه بأنه قيام Wiz بملاحظة "محاولات استغلال تتعلق بـ CVE-2026-59822 ضد مصائد العسل الخاصة بها لتحري نقاط نهاية تعداد النماذج."

• مؤكد: كلتا درجتي الخطورة موجودتان وتختلفان باختلاف الإطار. تُقيّم نشرة BerriAI الثغرة وفق CVSS 4.0 عند 8.8، مرتفعة، مع سرية مرتفعة وسلامة منخفضة وتوافر معدوم؛ في حين يضع تقييم NIST الخاص بـ CVSS 3.1، وهو التقييم الرئيسي في NVD، عند 8.2. يصف الرقمان العيب نفسه في إطار نظامي تقييم مختلفين، ولا ينبغي مقارنتهما وكأن أحدهما حل محل الآخر.

• غير مُثبت:أي ضحية مُسمّاة. لا يُحدِّد تنبيه CISA، ولا استشارة BerriAI، ولا تقرير Wiz، ولا تغطية The Hacker News، أي مؤسسة تم الوصول إلى أدوات MCP الخاصة بها عبر هذا الخلل، أو يُفيد ببيانات اعتماد أو بيانات أُخِذت من إحداها. السجل العام للاستغلال هو بيانات قياس عن بُعد من مصائد العسل وقرار فيدرالي، وليس خرقًا تم الإفصاح عنه.

• لم يثبت: أن أي مجموعة برامج فدية تستخدمه. يظهر حقل KEV القيمة "Unknown"، وهي قيمة تُسنِدها CISA، وليست دليلًا على انتفاء الاستخدام في أي من الاتجاهين.

سابقة يونيو، وسلسلة تنفيذ التعليمات البرمجية عن بُعد التي ليست هذه.

هذه هي ثغرة LiteLLM الثانية التي تصل إلى كتالوج KEV في عام 2026، ويسهل الخلط بينها وبين الثغرة السابقة. ثغرة CVE-2026-42271، التي أُضيفت في 8 يونيو 2026 بموعد نهائي هو 22 يونيو، هي ثغرة حقن أوامر في نقاط نهاية اختبار خادم MCP في LiteLLM: تصف Wiz نقاط نهاية تتيح للمستخدم اختبار إعدادات خادم MCP قبل حفظها، حيث يُمرَّر حقل الأمر إلى تنفيذ العمليات الفرعية دون التحقق منه. وقد قدّم المهاجمون إعدادات خادم stdio مزيفة كان الأمر فيها يقوم بتنزيل برنامج لتعدين العملات الرقمية وتشغيله، وأعادوا مصافحة MCP تبدو صالحة بحيث بدا الاختبار ناجحًا. ويُدرج إدخال CISA الخاص بها CWE-78 وCWE-77 — حقن الأوامر والوسائط، وليس المصادقة.

هذا العيب هو الذي يتسلسل. تقول Wiz إن CVE-2026-42271 «يمكن تسلسله مع تجاوز التحقق من ترويسة المضيف في Starlette (CVE-2026-48710) لتحقيق تنفيذ تعليمات برمجية عن بُعد دون مصادقة بالكامل»، وإن باحثين خارجيين ربطوا مجموعة برامج الفدية Qilin بالاستغلال النشط لتلك السلسلة. أُضيف CVE-2026-48710 إلى كتالوج KEV في الدفعة نفسها بتاريخ 2 سبتمبر التي ضمّت تجاوز LiteLLM، وبالموعد النهائي نفسه المحدد في 16 سبتمبر، وتقول ملاحظة كتالوج CISA الخاصة بثغرة Starlette إنه يمكن تسلسله مع CVE-2026-42271. وصلة Qilin تخص هذا الاقتران. وهي ليست نتيجةً بشأن CVE-2026-59822، ولا شيء في المصادر التي جرى مراجعتها يربط مجموعة برامج الفدية بتجاوز المصادقة.

ثمة تفصيل إداري واحد يفصل بين مدخلَي LiteLLM: فالإجراء المطلوب في إدراج يونيو يستشهد بـ BOD 22-01، وهو التوجيه التشغيلي الملزم الأقدم، في حين يستشهد إدراج سبتمبر بـ BOD 26-04، «إعطاء الأولوية للتحديثات الأمنية استنادًا إلى المخاطر». ولا يفسّر تنبيه CISA هذا التغيير، ولا يضمّ الكتالوج أي تعليق عليه.

ما الذي تغيّر بعد

مسار المعالجة قصير. توصي استشارة BerriAI بالترقية إلى 1.84.0 أو إصدار أحدث، وتقدم حلًا بديلًا للفرق التي لا تستطيع الانتقال فورًا: «تعطيل مسارات MCP أو حظر الوصول إلى /mcp/ ونقاط نهاية MCP ذات الصلة على الوكيل العكسي أو بوابة API لديك». هذا الحل البديل أداة فجّة — فهو يزيل القدرة بدلًا من تقييدها — لكنه التخفيف الوحيد الذي تسميه الجهة المصنّعة لعمليات النشر غير المصحّحة.

يضع نص الإجراء المطلوب من CISA بشأن نقاط الدخول الوكالات الفيدرالية أمام المقايضة نفسها: تطبيق التخفيفات وفق تعليمات البائع وتماشياً مع BOD 26-04، «أو التوقف عن استخدام المنتج إذا لم تكن التخفيفات متاحة»، مع إلقاء مسؤولية تقييم تعرض الأصل للإنترنت على عاتق كل وكالة. والتوجيه ملزم فقط للوكالات المدنية الفيدرالية في الفرع التنفيذي؛ وتشجع CISA المنظمات الأخرى على تبني الأولوية نفسها القائمة على المخاطر دون إلزامها بذلك.

ما إذا كان أي طرف خارج مصيدة عسل قد تحرّك بشأن الموعد النهائي فليس معلومًا للعامة. ولم تنشر CISA ولا BerriAI أرقامًا عن عدد عمليات نشر LiteLLM التي تعرّضت للانكشاف، أو كم منها جرى تثبيت التصحيحات عليه قبل 16 سبتمبر، أو كم منها تم الوصول إليه عبر التجاوز.

ما الذي لا يزال مفتوحًا

ثلاث فجوات جديرة بالذكر بدلاً من التستر عليها. لا يوجد تقرير حادثة علني يربط CVE-2026-59822 باختراق محدد، لذا فإن إدراجه في KEV يستند إلى أدلة الاستغلال لدى CISA وملاحظات Wiz من المصائد العسلية، لا إلى ضحية موثّقة. ولا يوجد بيان من المورّد حول كيف كُتب مسار الاحتياط بهذه الطريقة، أو كم مضى على وجوده قبل 1.84.0 — إذ تصف الاستشارة العيب وإصلاحه، لا تاريخه. ولم تكن مواعيد الدفعة موحّدة: فقد حملت خمسة من المدخلات السبعة المضافة في 2 سبتمبر موعداً نهائياً هو 5 سبتمبر، بينما حملت مدخلتا LiteLLM وStarlette موعد 16 سبتمبر. ولا توضح CISA السبب.

ما تم حسمه أضيق وأكثر فائدة من النتيجة. حرف واحد في ترويسة Authorization كان، في الإصدارات المتأثرة، غير قابل للتمييز عن مفتاح صالح لنقطة نهاية MCP — والإصدارات التي تصرفت بهذه الطريقة توقفت عن كونها حالية في مايو 2026.

تضيف CISA تجاوز المصادقة في MCP الخاص بـ LiteLLM إلى KEV: أي رمز Bearer كان كافيًا

الآلية: فحص فاشل أعاد جلسة صالحة

إصلاح في مايو، وCVE في يوليو، وموعد نهائي فيدرالي في سبتمبر

ما الذي تُثبته القائمة، وما الذي لا تُثبته

سابقة يونيو، وسلسلة تنفيذ التعليمات البرمجية عن بُعد التي ليست هذه.

ما الذي تغيّر بعد

ما الذي لا يزال مفتوحًا

المنتج

الموارد

لمقدمي الخدمات

انضم إلى مجتمعنا

من المدونة

مزودو النماذج